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.

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.

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.

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).

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.

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.

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