DNS trace & propagation checker.
The three terminals in one page: a dig +trace from the root servers down to the authoritative answer, the same question put to every authoritative nameserver with its zone serial, and what the public resolvers are caching right now. When one resolver sees the new record and another is clinging to the old one, this shows which, why, and how long until it lets go.
About this tool
This server does what a recursive resolver does when its cache is empty, and shows you every step. It asks a root server for the name with recursion switched off, gets a referral to the top-level domain's servers plus their addresses (glue), asks one of those, gets a referral to your zone's servers, and asks one of those for the record. That last answer, with the authoritative flag set, is the truth every resolver in the world eventually converges on. It is exactly what dig +trace +additional prints, laid out so the referral, the glue and the answer are distinguishable without knowing the format.
Then it does two things dig does not. It asks every nameserver in the delegation for the record and for the zone's SOA serial, so a secondary that has not picked up the latest change shows up as a different serial and a different answer. And it asks the four large public resolvers with recursion on, compares what they are serving against the authoritative answer, and turns the TTL each one returns into "cached this long ago, expires in this long". A resolver marked stale is not broken; it is doing what TTLs tell it to. The number next to it is how long you have to wait.
What the trace reports
| Section | What to look for |
|---|---|
| Delegation path | One hop per zone: root, TLD, your zone (and any zone in between). Each shows which server answered, how fast, the NS set it referred you to and the glue it handed out. The final hop carries the authoritative answer, or the SOA that accompanies a negative one. |
| Authoritative servers | Each nameserver in the delegation asked directly, with its SOA serial and its answer. They should be identical. A lower serial on one server is a secondary that has not transferred the zone; an answer without the authoritative flag is a lame server. |
| Public resolvers | Cloudflare, Google, Quad9 and OpenDNS with recursion on. Match means the same answer as the authoritative servers; the cache column says how long ago it was fetched and when it will be refreshed. Stale means the previous answer is still being served, and for how much longer. |
| Findings | Delegation (parent NS set versus the zone's own), glue (parent's addresses versus the zone's records), servers answering, serials in agreement, lame delegation, resolver consistency. |
Check DNS propagation
"Propagation" is cache expiry. When you change a record, nothing is pushed anywhere; every resolver that had the old value keeps serving it until the TTL it cached runs out, then asks again. So the question "has it propagated" has a precise answer: which resolvers still hold the old value, and how many seconds are left on each. That is the Public resolvers table. A resolver showing the new value with the full TTL has refreshed. One showing the old value with 4,000 seconds left will keep doing so for a bit over an hour, and there is nothing to be done about it from your side, which is why you lower the TTL a day before a change rather than after. The longer explanation is how long DNS propagation takes.
Two things this catches that a single-resolver lookup does not. First, a change that has propagated to resolvers but not to all of your own nameservers: the authoritative table shows one server on the old serial, and any resolver that happens to ask that one will get the old answer again after it refreshes. Second, a negative cache: a name you looked up before creating it is remembered as not existing for the SOA's negative TTL, and the resolver will say so until that runs out.
Stale glue and delegation mismatches
When your nameservers are inside the zone they serve (ns1.example.com serving example.com), a resolver cannot look up their addresses without already knowing them. The parent zone breaks the loop by handing out their addresses alongside the referral: glue. Glue is set at the registrar as "host records" or "child nameservers", and it is the thing people forget when they move a nameserver. The zone says ns1 is at the new address; the parent still says the old one. Resolvers that trust the parent's glue reach a dead server or, worse, whoever has that address now. The Glue finding compares every address the parent hands out with what the zone itself publishes, and names the one that moved.
The Delegation finding compares the NS set at the parent (what the registrar published) with the NS set in the zone (what your DNS provider serves). They should be identical. When they differ, resolvers are free to use either, which produces the maddening pattern where a name works from one network and not another. The usual cause is a nameserver change made in one place and not the other.
The dig incantations this replaces
| Command | What it shows |
|---|---|
dig +trace +additional example.com A | The delegation path from the root, with glue. What the Delegation path section shows. |
dig @ns1.example.com example.com SOA +norecurse | The zone serial on one authoritative server. Run once per nameserver and compare: the Authoritative servers table. |
dig @1.1.1.1 example.com A, then @8.8.8.8, @9.9.9.9 | What each public resolver is caching, with remaining TTL. The Public resolvers table. |
dig +norecurse @a.gtld-servers.net example.com NS | The delegation and glue as the parent sees it. Compare with dig @ns1.example.com example.com NS for the child's view: the Delegation and Glue findings. |
dig example.com NS +nssearch | SOA serial from every nameserver in one go. Rarely remembered, and it uses the system resolver to find them. |
Common problems this finds
- One resolver stale: it cached the old answer last; the cache column says when it lets go. Not a fault.
- Negative cache: the name was queried before the record existed and the resolver remembers "no such record" for the SOA minimum TTL. Same remedy: wait, or use a resolver that has not seen it.
- Secondary behind: one authoritative server has a lower serial. NOTIFY did not reach it or the transfer failed; fix the primary's notify list or the secondary's ACL, then wait for the refresh interval.
- Stale glue: the parent hands out an old address for an in-zone nameserver. Update the host record at the registrar.
- NS mismatch: registrar and DNS provider disagree about the nameserver set. Make them identical.
- Lame delegation: a listed server does not host the zone and answers without the authoritative flag. Remove it from the NS set or configure the zone on it.
- SERVFAIL from one resolver only: nearly always DNSSEC. A validating resolver rejects a zone whose DS record does not match its DNSKEY, or whose signatures expired; a non-validating one serves it happily.
Examples
- example.com: a clean three-hop trace, everything in agreement
- bbc.co.uk NS: eight nameservers, in-zone glue checked against the zone
- _dmarc.google.com TXT: a record under a zone with glue, four authoritative servers compared
- nothing-here.example.com: a negative answer and how resolvers cache it
From the command line
curl "kirkdiamond.com/tools/dns-trace?name=example.com&type=MX" prints the trace in dig's layout followed by the server and resolver tables; add &format=json for the structured version. Queries go straight to the root servers, the delegated nameservers and the four public resolvers, with recursion off for the walk and on for the resolvers. Nothing about the query is stored.