Guides · DNS
Reading A Full dig +trace Response
dig +trace walks DNS delegation from the root servers down to your authoritative nameservers. This guide reads a full trace block by block, and shows how it exposes delegation and lame-nameserver problems a normal lookup hides.
By Cody · 7 min read · Published
The short version
A plain dig example.com asks your resolver one question and prints one answer. dig +trace example.com does something more useful when something is broken: it performs the recursion itself, starting at the root servers and following each referral down to your authoritative nameservers, printing every hop along the way.
That makes +trace the tool for delegation problems — a domain that resolves inconsistently, a nameserver that half-answers, a registrar change that did not fully take. The answer is not one record; it is the whole path, and the level where the path breaks is your bug.
What +trace actually does
DNS is a tree, and no single server knows all of it. Each level only knows who is responsible for the level beneath it. Normal resolution hides this: your recursive resolver walks the tree for you and returns just the result (often from cache).
+trace turns that walk inside out. It ignores your resolver's recursion and cache, queries a root server directly, then follows each referral — a set of NS records pointing one level deeper — until it reaches the servers that hold the real record. Every block you see is one level of the delegation, answered by a different server.
Reading the trace top to bottom
A trace for example.com has four stages, in order:
| Stage | Who answers | What you see |
|---|---|---|
| 1. Root | A root server (from the root hints) | The NS set for . and a referral to the .com servers. |
| 2. TLD | A .com gTLD server | A referral: the NS records for example.com. |
| 3. Authoritative | example.com's own nameserver | The actual answer — the A / AAAA / MX record you asked for. |
| 4. Receipt line | dig itself | ;; Received N bytes from IP#53(server) closes each block. |
The final block is the only authoritative one — it carries your record. Everything above it is signposting: NS records that say “keep going, ask these next.”
What +trace reveals that a normal lookup hides
| Finding in the trace | What it means |
|---|---|
| A nameserver in a referral returns SERVFAIL or times out | Lame delegation — the parent points to a server that does not serve the zone. |
| Parent NS names differ from the child's own NS records | Parent/child mismatch — the registrar delegation is out of date. |
| Authoritative answer differs from a cached normal dig | Propagation in progress; the cached copy has not expired yet. |
| The walk stops at the TLD with no child NS | The domain is not delegated — often an unregistered or expired name. |
| Only some of the listed nameservers respond | Partial outage — resolution works but is fragile and slow. |
Reading it in the tools
The dig tool returns the full structured response — question, answer, authority, and additional sections with flags and TTLs — so you can read exactly what each server sent. For a fast summary of a single name, nslookup is quicker; see nslookup vs dig for when to reach for each.
If the trace shows the authoritative answer differs from what you expected, the resolver comparison tool shows the same record across several public resolvers at once — the quickest way to confirm a change is still propagating. For how long that takes, see DNS TTL explained.
A dig +trace, root to authoritative
- Example input
dig +trace example.com- Example result
. 518400 IN NS a.root-servers.net. ;; Received 811 bytes from 192.168.1.1#53(192.168.1.1) in 4 ms com. 172800 IN NS a.gtld-servers.net. ;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 20 ms <- root referred us to .com example.com. 172800 IN NS a.iana-servers.net. ;; Received 576 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms <- .com referred us to example.com's NS example.com. 86400 IN A 93.184.216.34 ;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 30 ms <- authoritative answer
Each block is one level of delegation. Only the last block is authoritative — it carries the A record. Read down until a level times out, returns SERVFAIL, or lists nameservers that do not match: that level is the fault.
Related tools
FAQ
What does dig +trace do differently from a normal dig?
A normal dig hands your question to a recursive resolver and prints the single answer that comes back. dig +trace does the recursion itself: it starts at the root, follows each referral down through the TLD servers to your authoritative nameservers, and prints every step. So instead of one answer you get the whole delegation path — which is exactly what you need when the problem is in the path, not the final record.
Why does +trace start at the root servers?
Because that is how real iterative resolution works. No server knows the whole tree; each level only knows who is responsible for the level below it. The root servers know the TLD servers, the TLD servers know your domain's nameservers, and your nameservers know the actual records. +trace reproduces that walk from the top so you can see the delegation being followed link by link.
What is a referral in a +trace output?
A referral is a server saying 'not me — ask these servers instead,' returned as a set of NS records rather than an answer. When you query a root server for example.com it does not know the answer; it refers you to the .com nameservers. Query one of those and it refers you to example.com's nameservers. Each NS block in a trace is one referral, and the final block that contains your actual record (an A, for instance) is the authoritative answer.
What is lame delegation and how does +trace reveal it?
Lame delegation is when the parent zone points to a nameserver that does not actually serve the zone authoritatively — a stale, misconfigured, or unreachable server. In a normal lookup a resolver quietly retries another nameserver and you never notice. In +trace you see it directly: the referral lists a nameserver, and querying it returns SERVFAIL, a timeout, or a non-authoritative reply instead of the expected data. That mismatch is the lame server.
Why does +trace sometimes give a different answer than a normal dig?
Because they take different paths. A normal dig may return a cached answer from your recursive resolver, while +trace ignores caches and asks the authoritative servers fresh. If a record changed recently, +trace shows the new value while the cached lookup still shows the old one until the TTL expires. A disagreement between the two is often just propagation in progress — compare the TTLs to confirm.
What does the ';; Received ... from' line mean?
It is dig telling you which server answered each step and how long it took, for example ';; Received 512 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms.' It closes out each block of the trace, so you can see the exact IP and nameserver that produced each referral. When a step is slow or times out, that line is where the delay or failure shows up.
How do I read a +trace when a lookup is failing?
Read top to bottom and find the level where the walk breaks. If the root and TLD referrals are fine but the query to your authoritative nameservers returns SERVFAIL or times out, the fault is at your nameservers or their delegation. If the NS names in the parent referral do not match the NS records your own servers publish, you have a parent/child mismatch. The first level that misbehaves is the one to fix.
Last reviewed: 2026-07-08.