DNS Trace

Follow a name from the root servers down to the nameservers that answer for it, one referral at a time, with recursion switched off. Every hop shows who was asked, what they said and how long it took. Then every nameserver of the answering zone gets asked whether it serves the zone.

Try an example: google.com · cloudflare.com (NS, signed) · www.github.com (CNAME)

Frequently Asked Questions

Reading a trace, and what each warning means.

A normal lookup asks a resolver, and the resolver hands back its final answer, often from cache. You never see which servers it asked on the way.

A trace does the resolver's job in the open. It asks a root server, gets referred to the TLD, gets referred again to your domain's nameservers, and shows each step. When a delegation is broken, you see the exact hop where it breaks.

Our take: use a lookup to see what the world gets back. Use a trace when that answer looks wrong and you need to know where it comes from.

Yes, but we don't use that word in results. RFC 9499, the DNS terminology RFC, calls "lame delegation" historic: people use it for several different faults, so it no longer says which one you have.

Instead, each nameserver is asked for the zone's SOA with recursion off, and the result names what it did:

Serves the zone       →  answered with authority (AA set) and the SOA
Refused               →  REFUSED: declined to answer "for policy reasons" (RFC 1035)
SERVFAIL              →  "unable to process this query" (RFC 1035)
Not authoritative     →  answered without AA, or referred somewhere else
No answer from here   →  timed out from our server; could be down, could be filtering

What to do: every one of these is a server named in your delegation that isn't serving your zone right now. Either remove it from the NS list at your registrar, or get the zone set up on it.

Because we can't tell a dead server from one that doesn't answer our network. The trace runs from one place, our server. A nameserver that rate-limits, filters by region or is briefly down looks the same from here.

When a server times out during the walk, the trace tries another server for the same zone and carries on. The failed attempt stays in the path so you can see it.

What to do: if one server times out on every run, query it directly from your own network:

dig +norec @ns1.example.net example.com SOA

The parent's list is the delegation in the zone above yours. For most domains that's what your registrar publishes in the TLD. The child's list is the NS records inside your own zone. RFC 1034 §4.2.2 says the two should match and stay that way.

It matters because resolvers don't all use the same list. RFC 2181 §5.4.1 ranks the zone's own NS records above the parent's referral, so a resolver that follows it switches to yours once it has seen them. A server that appears on only one list gets traffic from some resolvers and not others.

What to do: decide which set is correct, then make the registrar's list and the zone's NS records identical.

A referral names the next nameservers. If a nameserver's name sits inside the zone it serves (ns1.example.com for example.com), the parent has to hand over its IP address too. That address is called glue (RFC 1034 §4.2.1).

When the nameservers live somewhere else (ns1.dns-host.net for example.com), there's no glue, so the trace resolves the nameserver's address in a separate walk before it can continue. That's normal and costs a few extra queries.

Yes. dig follows the referrals from the root and prints the answer from each server it used:

dig +trace example.com A

This page adds two things on top: it checks every nameserver of the zone that answered, not only the one used, and it compares the parent's NS list with the zone's own.

🔐 Want to know whether the DNSSEC chain validates? DNSSEC Checker →

How this DNS trace works

The trace starts at a randomly picked root server and asks it for your name with recursion switched off. The root doesn't know the answer, so it refers the query to the TLD's nameservers. The TLD refers it to your domain's nameservers, and those answer. That's the walk RFC 1034 §4.3.2 describes, and it's what every resolver does behind the scenes.

Each hop shows the server asked, its address, the response code, whether the answer carried the authoritative (AA) flag, the round-trip time, and what came back. Queries go over UDP and retry over TCP when the answer comes back truncated.

What gets checked after the walk

Once a zone answers, the trace goes back to every nameserver named for it, by the parent or by the zone itself (up to eight): 

Each nameserver   →  asked for the zone's SOA; must answer with authority
Parent vs child   →  the parent's NS list compared with the zone's own NS records
DS                →  whether the parent's referral carried a DS record

A DS in the referral means the parent expects the zone to be signed. Whether the signatures validate is a separate question, and the DNSSEC checker answers it.

One vantage point, IPv4 only

Your browser can't do this. It can't send raw DNS queries on port 53, so the trace runs on our server and the page shows the result. That means one network location. Anycast root and TLD servers answer from whichever instance our network is routed to, and a nameserver that only drops our traffic shows up as "no answer from here", not as broken.

Queries go to IPv4 addresses only. For the name's final answer as the public resolvers see it, run a DNS lookup.