Nameservers agree on the NS set

This asks each authoritative nameserver, separately, for the zone's own NS record set and compares the answers. It is a different question from the one the delegation section asks: that one compares the registry against the zone, this one compares the zone against itself.

Disagreement means the servers are not serving the same zone. A resolver learns the nameserver set from whichever server it happened to ask, caches it, and sends its next queries to those — so which servers a visitor ends up using depends on which server answered them first. Two visitors, two views, no pattern to it.

It nearly always travels with a serial mismatch, and it is the same underlying fault seen from another angle: replication has stopped, or an edit was applied at one provider and not the other. Where it appears on its own, the usual cause is a zone hand-edited on one server.

Compare the SOA serials first — the serial-agreement check in this report shows them per server. The server reporting the lower serial is the one that has not received the update, which turns a disagreement into a replication problem with a direction.

For a primary and secondaries, two things account for most of it: NOTIFY not being sent by the primary, and transfers refused by the secondary's ACL. The secondary's log will name the reason, which beats inferring it from outside.

Where two independent providers each hold a copy, the sync pipeline is the suspect rather than either provider. This is the failure mode that makes managing both zones from one source of truth worth the setup.