How to Troubleshoot DNS Like a Pro Using dig and nslookup

What dig Actually Does (and What It Doesn't)

dig (Domain Information Groper) is a DNS lookup utility that sends queries directly to resolvers or authoritative nameservers and prints the full DNS response — not just the answer. Unlike nslookup, which was deprecated by ISC for years before being revived, dig has always been the recommended tool for DNS diagnostics. It ships with BIND and is available on virtually every Linux distribution out of the box.

The anatomy of a dig response:

$ dig example.com A

;; ANSWER SECTION:
example.com.        3600    IN      A       93.184.216.34

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Jun 08 12:00:00 UTC 2026
;; MSG SIZE  rcvd: 56

Critical detail: The TTL (3600 seconds above) is what the resolver reports — it counts down. If you query an authoritative nameserver with +noauthoritative flag removed, you see the original TTL. The difference between these two values tells you how long the resolver has held the cached entry. This is your first clue when troubleshooting propagation issues.

dig vs nslookup: When to Use Which

Rule of thumb: Use dig for scripting, debugging, and any automated workflow. Use nslookup only when you're on a Windows machine with no dig available, or when you need a quick interactive lookup and don't care about parseable output.

Three Troubleshooting Workflows That Solve Real Problems

Workflow 1: "I changed the A record but it still resolves to the old IP"

This is the most common DNS support ticket. Here is the systematic approach:

1. Check what the authoritative server actually serves:

   $ dig @ns1.yourprovider.com example.com A +short

   If this returns the new IP, the change propagated to the authoritative server. If it returns the old IP, the change was never saved or the provider hasn't pushed it yet.
2. Check what Google/Cloudflare resolvers see:

   $ dig @8.8.8.8 example.com A +short
   $ dig @1.1.1.1 example.com A +short

   If these return the old IP while the authoritative server shows the new one, you are waiting for cache expiry. Look at the TTL in the authoritative response — that is how long you must wait.
3. Check your local cache:

   # Linux (systemd-resolved)
   $ resolvectl flush-caches
   
   # macOS
   $ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   
   # Windows
   > ipconfig /flushdns

   Gotcha: Chrome has its own internal DNS cache. Navigate to chrome://net-internals/#dns and click "Clear host cache" to bypass it.

Workflow 2: "Email stopped working after moving to a new host"

1. Verify MX records exist and point to hostnames, not IPs:

   $ dig example.com MX +short
   10 mail.example.com.

   The trailing dot is critical — it means the hostname is fully qualified. Without it, some DNS software appends the zone origin, producing mail.example.com.example.com.
2. Verify the MX hostname resolves:

   $ dig mail.example.com A +short

   An MX record pointing to a hostname with no A record silently fails. No bounce, no error — mail just sits in the sender's queue until it expires.
3. Check SPF, DKIM, and DMARC with the Email Authentication Checker. Broken or missing records do not always cause hard failures, but they can trigger spam classification and soft-bouncing that is difficult to trace.

Workflow 3: "The domain resolves from some locations but not others"

1. Trace the full delegation path:

   $ dig +trace example.com

   This shows every step: root servers → TLD servers → authoritative nameservers. If the trace stops at any hop, you have a delegation problem.
2. Check the NS records at the registrar level:

   $ dig example.com NS
   $ dig example.com NS @gtld-servers.net  # TLD-level delegation

   A mismatch between these means the registrar delegation and zone file are out of sync.
3. Use the DNS Propagation Checker to compare results across dozens of resolvers worldwide.
4. Check for DNSSEC breakage:

   $ dig +dnssec example.com SOA

   If DNSSEC validation fails, validating resolvers (Google DNS, Cloudflare, Quad9) return SERVFAIL. Non-validating resolvers see the domain fine. This asymmetry is confusing during outages because some users report the site as down while others see it up.

Advanced dig Flags Every Sysadmin Should Know

Quick reference: dig one-liners for common tasks

# Bulk A record check for multiple subdomains
$ for sub in www mail api staging; do dig +short $sub.example.com A; done

# Find all nameservers for a domain and their IPs (glue check)
$ dig example.com NS +short | xargs -I{} dig +short {} A

# Check SOA serial across all authoritative nameservers
$ dig example.com SOA +short | awk '{print $3}'

# Verify a specific TXT record (SPF, DKIM selector)
$ dig example.com TXT +short | grep 'v=spf1'
$ dig default._domainkey.example.com TXT +short

Six DNS Troubleshooting Gotchas That Waste Hours

1. dig returns NOERROR with zero answers — that is not an error. NOERROR status means the query was processed successfully; zero answers means the record type you requested does not exist at that name. NXDOMAIN means the entire name does not exist. Confusing the two leads you to chase phantom problems.
2. CNAME at the apex/root breaks everything silently. RFC 1034 prohibits CNAME records coexisting with SOA and NS records at the zone apex. If your DNS provider lets you create one, resolvers may behave unpredictably — some return the CNAME target, others SERVFAIL, others ignore the CNAME. Use the DNS Lookup tool to audit your zone.
3. Negative caching (NXDOMAIN TTL) prevents newly created records from resolving. If a resolver queried for a record before it existed, it cached the negative response (NXDOMAIN or NODATA). The SOA minimum field (last value) controls how long this negative cache lives. Creating a record with TTL 300 does not help if the negative TTL is 86400.
4. Some ISPs override your TTL. Large ISPs and mobile carriers run their own caching resolvers that enforce minimum TTL values — they may ignore your 60-second TTL and cache records for 3600 seconds regardless. This is why "TTL 60" propagation can still take hours on certain networks.
5. nslookup on Windows behaves differently from dig on Linux. Windows nslookup automatically appends DNS suffixes from your network configuration. Querying server1 may silently become server1.corp.local. Always use FQDNs with trailing dots in nslookup to prevent suffix appending.
6. Network firewalls block DNS over TCP. DNS primarily uses UDP port 53, but falls back to TCP for responses larger than 512 bytes (or 1232 bytes with EDNS0). If your firewall allows UDP:53 but blocks TCP:53, large DNS responses (long TXT records, zone transfers, DNSSEC chains) silently fail. Always test with dig +tcp to rule this out.

Next Steps: Correlate DNS With Other Checks

DNS troubleshooting rarely happens in isolation. Once you have used dig to verify records, correlate with these tools to confirm the full picture:

• DNS Record Lookup — Query any DNS record type from a browser — A, AAAA, MX, TXT, NS, CNAME, SOA, PTR. Export results as CSV, BIND zone, JSON, or YAML for documentation and zone audits.
• Reverse DNS Lookup — Check PTR records for IP addresses. Reverse DNS is critical for email deliverability — many mail servers reject messages from IPs without matching forward and reverse DNS.
• DNS Propagation Checker — Compare results across resolvers globally to verify propagation status.
• WHOIS Lookup — Verify registrar delegation and domain ownership.
• Email Authentication Checker — Validate SPF, DKIM, and DMARC records.

Frequently Asked Questions