dig and nslookup: DNS Troubleshooting Commands Explained

When a domain "does not resolve", the failure can live in a browser cache, a stub resolver, a recursive server, a delegation, or the authoritative server itself - and the fastest way to find out which is dig. This guide explains how to read dig output (status codes, flags, sections), how to run targeted queries against specific resolvers, how to trace the full resolution chain, and what common failures mean in practice.

Reading dig Output

$ dig example.com A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14823
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.           IN  A

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

Four things to read:

• status - NOERROR (ok, though possibly an empty answer), NXDOMAIN (name does not exist), SERVFAIL (resolver failed - common with DNSSEC validation errors or broken delegations), REFUSED (server will not answer you).
• flags - aa = authoritative answer (only when you query the zone's own nameserver); rd/ra = recursion desired/available; ad = DNSSEC validation succeeded.
• ANSWER/AUTHORITY/ADDITIONAL sections - the records, the zone's NS set, and extra records such as glue.
• TTL - seconds the answer may be cached; watch it count down on repeated queries to confirm you are seeing a cache.

The header is where most debugging actually happens. A NOERROR with an empty ANSWER section is not a failure at all — it means the name exists but has no record of the type you asked for, which is the classic symptom of querying for A on a host that only publishes AAAA, or of a typo in the record type. An NXDOMAIN from a recursive resolver but NOERROR from the authoritative server means someone is serving an old, incomplete copy of the zone or the delegation points at the wrong servers. Reading these two fields before anything else will resolve a large fraction of "DNS is broken" tickets in under a minute.

Targeted Queries

dig example.com A                    # A record (default)
dig example.com MX                   # mail servers
dig example.com NS +short            # authoritative nameservers
dig @8.8.8.8 example.com             # query a specific resolver
dig @ns1.example.com example.com     # query the authoritative server directly
dig -x 93.184.216.34                 # reverse (PTR) lookup
dig +short example.com               # answer values only (scripting)
dig +dnssec example.com              # include RRSIG records
dig +tcp example.com                 # force TCP (large responses)

Comparing answers across resolvers is the fundamental debugging move: if the authoritative server returns the right IP but 8.8.8.8 returns a stale one, the problem is caching at Google (wait for TTL expiry); if authoritative servers disagree with each other, check zone transfers.

Two habits make the comparison trustworthy. Always capture the TTL alongside the answer, because a short TTL means the stale-cache explanation is unlikely. And always query the authoritative servers by name, not by IP, so that if the delegation itself has changed you will see it in the response rather than silently hitting a host that used to be authoritative. When a name resolves differently from two networks, run the same query from both and diff the output — the delta is the answer.

Tracing Resolution with dig +trace

dig +trace example.com

+trace replays the whole chain - root servers, TLD, then authoritative - showing exactly where resolution breaks. A slow or failing hop identifies the culprit: root/TLD trouble is usually your network or the resolver, while an authoritative server that does not answer points at the domain operator. The +norecurse flag (dig example.com +norecurse) asks for iterative-only answers and is useful against authoritative servers directly.

Note that +trace does not use your configured resolver at all; it starts from a built-in root hint list and walks down. That makes it an excellent way to prove that a problem lies above your resolver rather than in it. If +trace completes in a second and your normal query does not, the fault is local — your stub resolver, your local caching daemon, or the search domain your operating system is appending to the query.

nslookup: The Cross-Platform Fallback

nslookup example.com                 # basic lookup via system resolver
nslookup example.com 8.8.8.8         # query a specific server
nslookup -type=MX example.com        # record type
nslookup -type=NS example.com

nslookup is available on Windows, macOS and Linux and is fine for quick checks; its "Non-authoritative answer" line is the equivalent of a missing aa flag. For serious debugging prefer dig - it shows more and lets you disable the search domain (+nosearch), set timeouts (+time=2 +tries=1) and request specific sections (+noall +answer).

On Windows, nslookup and Resolve-DnsName are both available and Resolve-DnsName is the more useful of the two because it returns structured objects you can filter:

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly
Get-DnsClientServerAddress -AddressFamily IPv4   # what resolvers am I actually using
ipconfig /displaydns | Select-String "example"   # inspect the local cache
ipconfig /flushdns                               # clear it

On a modern Linux desktop the stub resolver is usually a local daemon rather than /etc/resolv.conf itself, so the file can be misleading; our systemd-resolved and resolvectl troubleshooting guide walks through querying the per-link resolver state. On the server side, when the answer is simply wrong because the zone is wrong, the fix lives in the zone file itself — see the BIND9 authoritative zone configuration guide.

Record Types You Will Actually Query

Most DNS incidents narrow to a handful of record types, and knowing which one to ask for shortens the diagnosis considerably.

• A / AAAA — IPv4 and IPv6 addresses. A missing AAAA on a dual-stack host makes clients that prefer IPv6 wait for a timeout before falling back, which looks like intermittent slowness rather than an outage.
• CNAME — aliases. Chasing a CNAME chain (dig +noall +answer example.com) shows whether a helper record points at a name that no longer exists, producing NXDOMAIN for the original query.
• MX — mail routing, including the priority value. Two MX records with the same priority and different reachability is a common cause of "mail is slow sometimes".
• TXT — SPF, DKIM, DMARC, domain verification. Long TXT records are the usual reason a response needs TCP, which is why +tcp exists.
• SOA — the zone's serial number. Fetching the SOA from every authoritative server and comparing serials instantly reveals which of them is lagging.
• NS — the delegation. Mismatched NS sets between the parent zone and the child zone is a classic cause of intermittent resolution failures.

dig +short example.com CNAME
dig +short example.com MX
dig +short example.com TXT
dig @ns1.example.com example.com SOA +short
dig example.com DS +short        # delegation signer, from the parent

Timeouts, Retries and the Search Domain

A resolver that never answers is not the same as a resolver that answers "no". dig distinguishes them: a timeout prints ;; connection timed out; no servers could be reached and exits non-zero, while an NXDOMAIN exits zero with a status line. For scripting, both behaviour and timing matter, so pin them explicitly:

dig +time=2 +tries=1 +short example.com     # 2 second timeout, one attempt, values only
dig +search example.com                     # allow search domain expansion
dig +nosearch example.com                   # never expand; always query the FQDN literally
echo $?                                     # 0 = answered, 9 = timeout

The search domain is an underrated source of confusing results on corporate laptops: a query for intranet can silently become intranet.corp.example.com, and a failure to resolve the short form may have nothing to do with the name you typed. Always test with the fully-qualified name and a trailing dot when you want to be certain: dig example.com. tells the resolver you mean exactly that name and nothing else.

Validating DNSSEC End to End

DNSSEC failures almost always surface as SERVFAIL rather than a specific error, which makes them frustrating if you do not know to look for them. The trick is to re-run the query with validation disabled and then work out which link in the chain is broken.

dig +dnssec example.com                  # look for RRSIG records and the ad flag
dig +cd example.com                      # +cd = checking disabled; does it work now?
dig example.com DS +short                # is there a DS record at the parent?
dig example.com DNSKEY +short            # does the child publish keys matching the DS?
delv example.com                         # full validation with an explanation

If +cd succeeds where the validated query failed, the data is present and the signatures are the problem: usually an expired RRSIG, a key rollover where the parent DS was not updated, or a clock that is wrong on the validating resolver. An expired signature on a forgotten record is surprisingly common, and it breaks the whole zone, including names that are perfectly fine — which is why "everything under our domain fails from one resolver but works from another" is such a characteristic DNSSEC symptom.

Reading a Delegation

Delegation problems are the ones that look like DNS is broken in a way nobody can explain, because two servers both answer correctly for different versions of reality. The check is mechanical:

dig @a.root-servers.net example.com NS +norecurse
dig example.com NS +norecurse            # ask the TLD servers, not a recursive
dig @ns1.example.com example.com NS      # what does the zone itself publish?
dig @ns1.example.com example.com SOA +short

Walk the chain from the root downward with +norecurse, and at each level record the NS set and any glue. If the parent lists two nameservers and the child zone lists three, the extra one will be ignored for queries arriving from outside — a very common cause of "we added the new nameserver but some queries still fail". If the glue address in the parent does not match the server's real address, external clients will time out while internal clients (who resolve nameserver names via a different path) succeed.

Common Failure Playbooks

• NXDOMAIN - the name truly does not exist: check spelling, registration and delegation.
• SERVFAIL - typically DNSSEC validation failure or an unreachable/broken authoritative server. Test with dig +cd (validation disabled); if that works, you have found a DNSSEC problem.
• Wrong answer - stale cache or wrong zone data: query the authoritative server directly and compare.
• Slow resolution - dig +trace shows per-level query times; a slow authoritative hop points at the domain's nameservers.
• Works internally, fails externally - split-horizon DNS or a missing external delegation. Query from outside the network, or against a public resolver from inside, to see the difference.
• Intermittent failures - more than one authoritative server and only some of them are healthy. Query each by name and compare answers and latencies; a single dead nameserver in a set of two produces exactly this pattern because clients do not retry quickly.
• One host, all names, no resolution - the local resolver configuration, not DNS itself. Check /etc/resolv.conf, resolvectl status, or Get-DnsClientServerAddress before you look at any zone.

Automating the Comparison

When you suspect a stale or inconsistent answer, a short loop over several resolvers turns a guess into evidence. Run it from the affected network so that local configuration is included in the result:

for s in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  printf "%-16s " "$s"
  dig @"$s" +time=2 +tries=1 +short example.com || echo "FAILED"
done

Feed the same list through with and without +dnssec, and against the authoritative servers directly, and you will usually have a defensible answer about where the record diverges within a couple of minutes. Save the outputs alongside the ticket; DNS evidence has a short shelf life because caches move on.

DNS is only the first hop of a connection - once the name resolves, confirm the network path itself is healthy using the packet/interface tooling covered in our Wireshark filter guide and ethtool guide, and remember that DNS over VPNs/tunnels can rewrite answers - see SSH tunneling basics when split-tunnel DNS is involved. If resolution works but only some names inside a cluster fail, the cause may be policy rather than DNS at all, as covered in Kubernetes NetworkPolicy and DNS.

原文链接：https://sudoflare.com/networking/dig-tool/