DNS trace & propagation checker.

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

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

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.

Every parameter, the JSON field names, rate limits and ready-made CI checks are in the API and curl reference.