Nameserver mismatch

The registry's list is the delegation: it is what the parent zone answers when asked who is authoritative for your domain.

The zone's own NS records are the authoritative statement made by the servers themselves.

Under normal operation the two are identical, and the duplication is a consistency check rather than a decision.

Resolvers generally follow the delegation, and some cache the zone's own list once they have seen it, which is where the divergence becomes observable.

So a mismatch does not produce a clean failure — it produces different answers to different people, which is much harder to diagnose.

A migration to a new DNS provider where the registry delegation is updated and the old zone is left running with its own NS records.

The reverse: a new zone created at a new provider with correct NS records, and a registry delegation nobody changed.

A provider adding or renaming its nameservers, which updates the zone automatically and leaves the registry entry stale.

A domain transferred between registrars where the delegation was re-entered by hand and one server was mistyped.

In each case both sets of servers may answer correctly for most records, which is why the problem hides.

A DNS change takes effect for some people and not others, for far longer than any record lifetime would explain.

A propagation checker shows inconsistent answers that never converge.

Mail delivery becomes intermittent if the two zones disagree about MX records, which is the most expensive version of this.

A certificate renewal using DNS validation fails unpredictably, because the authority may query either set.

Anything diagnosed as a propagation problem that outlives the record lifetime by days is worth checking here first.

Decide which set of servers is authoritative in reality — usually the one holding the zone you actually edit.

Confirm that zone is complete and correct, including records you may have only ever created on the other side.

Update the registry delegation to that set, through the registrar's interface.

Leave the old servers answering with the same zone content until the delegation change has propagated, rather than switching them off immediately.

Only then decommission the old zone, and re-check both lists agree afterwards.

When a domain's nameservers are named inside the domain itself, the registry must also publish their addresses — a glue record — or the lookup cannot start.

Those addresses are a third place the same information lives, and they go stale the same way.

A glue record pointing at an address that no longer runs a nameserver produces intermittent resolution failures that look like nothing else.

Using nameservers named outside the domain avoids the question entirely, which is why most managed DNS providers do.

If your nameservers are inside your own domain, the glue addresses are worth checking whenever the delegation is.

`dig +short NS example.com` returns the zone's own list, answered by whichever server the resolver reached.

`dig +trace example.com` shows the delegation path, including what the parent zone answers — that is the registry's list.

Compare the two sets exactly, including order-independent membership: a set that differs by one server is still a mismatch.

Query each nameserver directly for a record you know, and confirm they all give the same answer.

Check the registrar's interface last rather than first, since it shows intent rather than what is served.

`dns.nameserver_consistency` compares the nameservers listed at the registry with the ones the zone publishes, which is this problem directly.

`dns.nameservers` reports the set itself, and `dns.resolution` whether the domain resolves at all.

`dns.propagation` queries several independent resolvers and reports disagreement, which is the symptom a mismatch produces.

`dns.conflicts` covers the neighbouring case where records at one name contradict each other rather than the servers disagreeing.

A mismatch is reported as a configuration fault rather than as a propagation state, because it does not resolve with time.