DNS Checker.eu

DNS Delegation Trace

Trace the DNS delegation path from a live root server down to your zone, read the NS referral at every level, and confirm every authoritative server serves the same SOA serial.

About DNS Delegation Trace

The DNS Delegation Trace answers a question a single lookup cannot: where does the answer for your domain actually come from? Instead of asking a resolver, it starts at a real root server and walks down the delegation chain one level at a time, reading the nameservers each level hands off to, until it reaches your zone. You get the same picture as dig +trace, with the latency of every hop, so a broken or half-finished delegation shows up as the exact level where the chain stops rather than as a vague resolution failure.

Delegation works through zone cuts, described in RFC 1034 and defined precisely in RFC 8499. A parent zone does not hold your records; it holds a referral, returning the child's NS set in the AUTHORITY section instead of an answer. When that referral points at a nameserver which no longer serves the zone, or lacks glue, resolution fails intermittently and only for resolvers with a cold cache. The second failure mode is a serial mismatch: the RFC 1035 SOA serial should be identical on every authoritative server, and RFC 1996 NOTIFY plus the refresh timer is what keeps secondaries in step.

The trace picks one of eight IANA root servers at random, including k.root-servers.net operated by RIPE NCC in Europe, then follows the referrals itself rather than handing the work to a resolver. Labels that are not zone cuts are skipped instead of being treated as errors, so co.uk, which Nominet serves from the same nameservers as uk, does not derail the walk. It finishes by querying one of the zone's own nameservers, which is what proves the delegation resolves end to end, then asks every authoritative server for its SOA serial and flags any disagreement.

How to use it

  1. 1Enter the domain you want to trace, for example example.eu, using the registrable domain rather than a subdomain.
  2. 2Select Trace delegation to start the walk from a root server.
  3. 3Read the delegation path from top to bottom: each row shows the zone level, the server that was asked, its IP address, how many NS records came back and the hop latency.
  4. 4Look for the authoritative badge on the final row, which confirms one of the zone's own nameservers answered for the domain.
  5. 5Check the Zone consistency card: serials agree means every authoritative server holds the same copy of the zone, serials differ means a secondary is behind.
  6. 6Note any row carrying an error, because that level is where the delegation chain breaks.

Common use cases

  • -Confirming a new delegation works end to end immediately after changing nameservers at the registrar.
  • -Troubleshooting a domain that resolves for most people but fails for resolvers with a cold cache.
  • -Detecting a secondary nameserver whose zone transfer has fallen behind, shown by a lower SOA serial.
  • -Auditing a two-provider DNS setup to verify both providers appear in the parent's referral and serve the same serial.
  • -Explaining how recursive resolution works, level by level, using real referrals from the root.

Frequently asked questions

What is a DNS zone cut?
A zone cut is the boundary where a parent zone stops holding data for a name and delegates it to a child zone's nameservers. RFC 8499 gives the formal definition. At a cut, the parent answers with a referral, meaning the child's NS records in the AUTHORITY section rather than the record you asked for, and the resolver then repeats its question to those nameservers.
How is a delegation trace different from dig +trace?
It performs the same iterative walk from a root server, following referrals instead of trusting a recursive resolver, but it runs from our European infrastructure with no local dig needed and adds two things: it skips labels that are not real zone cuts instead of stopping there, and it queries every authoritative server for the SOA serial so a lagging secondary is flagged for you.
Why must all nameservers have the same SOA serial?
The SOA serial is the zone's version number, and every authoritative server should be serving the same one. A secondary with a lower serial is handing out an older copy of the zone, so some users receive stale records while others receive the new ones. That happens when a NOTIFY (RFC 1996) is missed or a zone transfer fails, and it normally clears at the next refresh interval.
Why does a delegation trace skip some labels?
Because not every label is a zone cut. co.uk has no delegation of its own: Nominet serves it from the same nameservers as uk, so asking for its NS set returns nothing to follow. Rather than report that as a failure, the trace keeps the current server and asks it for the next label down, which is how a real resolver behaves.