Skip to content
Latchkey

dig +trace: Follow DNS Delegation From the Root

dig +trace walks the DNS delegation from the root nameservers to the authoritative server, printing each step.

When a name resolves from one resolver but not another, +trace shows the full delegation chain so you can see which level (TLD, zone, or authoritative server) is misbehaving, independent of any cache.

What it does

dig +trace ignores the local resolver and queries the root servers, then follows each NS referral down to the authoritative server for the name, printing the answer at every level. It bypasses caching, so it reflects the live state of the delegation.

Common usage

Terminal
dig +trace api.example.com
# trace a specific record type
dig +trace api.example.com AAAA
# quieter: drop the comments
dig +trace +nocomments api.example.com

Reading the output

StageWhat it shows
Root (.) NS recordsThe root servers dig starts from
TLD NS referralThe .com (or other TLD) nameservers
Zone NS referralThe authoritative servers for your domain
Final answerThe A/AAAA record from the authoritative server

In CI

Use +trace when a record was recently changed and some runners see the old value: a cache somewhere is stale, and +trace shows the authoritative truth. If +trace succeeds but a plain dig fails, the problem is the runner resolver or its cache, not the record.

Common errors in CI

If +trace stops at the TLD level with no zone referral, the domain has no delegated nameservers (a registration or NS-record problem). "couldn't get address for '<ns>'" mid-trace means an authoritative nameserver name does not itself resolve, a broken glue or NS setup. A +trace that hangs usually means outbound port 53 to the root servers is blocked.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →