Most people use dig in its terse mode — dig +short github.com — to grab the answer and move on. When something is broken, you want the loud mode: dig +trace. It walks the delegation chain from the root downwards, printing what each layer returns. Done right, you can pinpoint exactly which nameserver is lying.
The command
dig +trace github.comWhat dig actually does:
- Queries one of the configured root servers (from
/etc/resolv.confor the built-in hints) for the apex name. - Takes the NS referral the root returns and queries one of those TLD servers directly.
- Takes the TLD's referral and queries the authoritative nameservers for the zone.
- Receives and prints the answer from the authoritative layer.
It does not use your configured recursive resolver for any of this. That is the entire point — you are bypassing the cache and watching the delegation walk live.
A worked example
; <<>> DiG 9.18.x <<>> +trace github.com
;; global options: +cmd
. 174826 IN NS a.root-servers.net.
. 174826 IN NS b.root-servers.net.
. 174826 IN NS c.root-servers.net.
; (8 more roots)
;; Received 525 bytes from 192.168.1.1#53(192.168.1.1) in 3 ms
Section 1: the root referral. Your resolver gave you the NS list for the root zone. The 174826 is the remaining TTL (about 2 days). The query went to your local resolver in this case — the IP is your gateway, not a root server. dig caches this list and now picks one root to ask about com..
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
; (11 more)
com. 86400 IN DS 30909 8 2 E2D3...
com. 86400 IN RRSIG DS 8 1 86400 ...
;; Received 1183 bytes from 198.41.0.4#53(a.root-servers.net) in 18 ms
Section 2: the TLD referral, returned by a root server. You now know which 13 servers are authoritative for the com. zone. The DS and RRSIG records are the DNSSEC delegation signer and the signature over the NS set — they let a validating resolver prove the chain of trust. You can ignore those for non-DNSSEC debugging.
github.com. 172800 IN NS dns1.p08.nsone.net.
github.com. 172800 IN NS dns2.p08.nsone.net.
github.com. 172800 IN NS dns3.p08.nsone.net.
github.com. 172800 IN NS dns4.p08.nsone.net.
;; Received 837 bytes from 192.5.6.30#53(a.gtld-servers.net) in 28 ms
Section 3: the zone referral, returned by a .com TLD server. Now you have the authoritative nameservers for github.com. dig picks one and queries it for the A record.
github.com. 60 IN A 140.82.112.4
github.com. 60 IN RRSIG A 13 2 60 ...
;; Received 100 bytes from 198.51.45.8#53(dns1.p08.nsone.net) in 12 ms
Section 4: the authoritative answer. TTL is 60 seconds, the IP is GitHub's load balancer, and there is an RRSIG (this zone is signed). That is the same value that any recursive resolver would put into its cache and serve back to clients.
How to use it
Three failure modes you can spot from +trace:
- Stale delegation at the TLD. The TLD returns NS for your zone that point at the wrong nameservers (e.g. your old registrar). The chain breaks here and the rest of the trace never happens. Fix: log into the registrar and update the NS records on the domain.
- Glue mismatch. The TLD includes glue (A records for the NS hostnames) that disagree with the A records served by the zone itself. Clients hit the glue first, then can flip when caches refresh, producing intermittent failures.
- Authoritative server returns SERVFAIL. Usually a misconfigured DNSSEC chain or a misconfigured zone file. The trace will print the SERVFAIL and you know exactly which NS is unhealthy.
Companion checks
Once you have a clean trace, sanity-check what the public recursive layer is serving by running the same name through dnscheck — for example cloudflare.com. The trace shows you the truth at the authority. The multi-resolver matrix shows you what consumers are actually getting.
Reference: RFC 1035 (DNS specification), RFC 4035 (DNSSEC), BIND dig manpage.