How it works
A domain's NS records name the servers that answer authoritatively for its zone. They exist twice: in the parent zone at the registry, set through the registrar, and in the zone itself. If the name servers sit below the domain they serve, the parent zone also needs glue records with their IP addresses.
RFC 1034 calls for at least two name servers, ideally on different networks. A resolver asks one of them and moves on to the next if it gets no reply. Every zone has an SOA record with a serial number that goes up with each change. Secondary servers compare it with the primary and pull the zone via zone transfer (AXFR or IXFR), triggered by NOTIFY.
Lame delegation means a server is listed in the NS set but is not (or no longer) authoritative for the zone, answering with REFUSED or without authority. A serial mismatch suggests a secondary is no longer receiving the zone. Large anycast providers count the serial per server, though, so a mismatch with identical data is normal there.
Why it matters
Redundancy hides failures. If one of two name servers dies or goes lame, resolvers fall back to the other and some lookups take a few seconds longer. Faults like that often go unnoticed for months, until the second server fails too and the website and mail vanish completely.
If a secondary serves stale data, some visitors get old IP addresses or MX records, sometimes weeks after a migration. And a delegation pointing to a DNS service where the zone was deleted long ago can, in the worst case, be taken over by strangers who simply create the zone there again.
How to prevent it
- Use at least two name servers on different networks, ideally with an anycast provider.
- After a DNS migration, compare the NS set at the registrar with the one in the zone and remove old servers instead of leaving them in place.
- If you run your own primary and secondaries, monitor zone transfers and NOTIFY, and bump the SOA serial with every change.
- When moving a zone to another provider, switch the delegation first and delete the old zone only afterwards.
- Protect the registrar account with two-factor authentication and a registrar lock against unauthorized name server changes.
How DomainWarn detects it
The Name servers check reads the zone's NS records and queries each server directly for the SOA record. Servers without an address, that don't respond or aren't authoritative (lame) open a “Name servers broken” incident after two runs; if none answers, it is critical. When serials differ, the check compares SOA values, NS, MX, TXT, CAA, A and AAAA: different data is an error, identical data only a notice.
The check also raises notices for a single name server, all servers in the same /24 network, and zones spread across several providers. A name server switch appears through the DNS check as the warning “Name servers changed”, a changed name server address as a change event, and the Domain check additionally shows the name servers on record at the registry.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.