DNS Delegation Check

Check DNS delegation from the authoritative side. Compare the registry's nameservers against the zone's own, and query each nameserver directly for its SOA serial to catch out-of-sync servers.

What this checks that a normal lookup can't

Every propagation checker — including the one on this site's home page — asks recursive resolvers what they currently believe. That's the right tool for "has my change reached the world yet", but it can only ever show you the resolver-side view. A whole class of outages lives one level above that, and a recursive lookup is blind to all of it.

This check works from the authoritative side instead. It compares the nameservers the registry has on file against the nameservers the zone itself publishes, then opens a direct connection to each nameserver and asks it for the zone's SOA serial.

What it catches

• Delegation mismatch — the registry and the zone disagree about which nameservers are authoritative. Resolvers follow the registry, so a nameserver missing there gets no traffic no matter what the zone says.
• Out-of-sync nameservers — two authoritative servers reporting different SOA serials means zone transfers are lagging or failing, and the answer a visitor gets depends on which server they happen to reach.
• Lame delegation — a nameserver listed as authoritative that doesn't resolve, or doesn't answer. Queries sent there are wasted until they time out.
• Single points of failure — only one nameserver delegated, or every address sitting in the same /24.

Why the SOA serial matters

The serial is the zone's version number. A primary nameserver increments it on every edit, and secondaries copy the zone and adopt that serial. When every authoritative server reports the same serial, they're serving identical data. When they don't, replication is broken — and this is the failure mode that produces the maddening "it works for me but not for them" bug report, because which answer you get depends on which nameserver your resolver happened to pick.

This is also why the check queries each nameserver directly rather than going through a resolver. A recursive resolver returns whichever server answered it first, and caches that; it will never show you the disagreement.

FAQ

What's the difference between the registry's nameservers and the zone's?

They're two separate records maintained by two different parties. The registry's list lives at your registrar and is what the TLD's servers hand out during resolution. The zone's list is the NS record set inside your own DNS. They're supposed to match, and nothing enforces it — which is why they drift, usually after a DNS provider migration where the registrar half of the change never happened.

Why does it say a nameserver "did not answer over TCP"?

DNS normally runs over UDP and falls back to TCP for large responses. Some operators firewall TCP anyway. That's a configuration smell — RFC 7766 expects authoritative servers to support TCP — but on its own it isn't proof of a fault, so it's reported as information rather than a failure.

Why can't it probe Cloudflare-hosted nameservers?

WhereIsDNS runs on Cloudflare Workers, and a Worker cannot open connections to Cloudflare's own network. So if your DNS is on Cloudflare, the SOA comparison can't run from here and the report says so explicitly rather than reporting a false failure. The registry-vs-zone comparison still works normally.

How many nameservers should I have?

At least two, on separate networks. One nameserver means one outage takes the whole domain down, including email. Whether you need a second DNS provider depends on how costly downtime is — it's the standard upgrade for domains that must never go dark.

Is a delegation mismatch always a problem?

It's always worth fixing. Resolution follows the registry's list, so extra nameservers in the zone are simply ignored, and nameservers at the registry that the zone doesn't know about can produce inconsistent answers or timeouts. Neither is a state you want to leave in place.

Background reading

See the zone and resolver glossary entries, the DNS Records Explained guide, and the NS record lookup for the resolver-side view.