Check name servers

Why a domain has several name servers

The NS records name the servers that answer for a zone. They exist twice: in the parent zone (for example.com at the .com registry, entered through the registrar) and in the zone itself. A resolver picks one of the servers; if it does not answer, it tries the next. RFC 1034 therefore requires at least two name servers, and RFC 2182 recommends running them in different networks and locations so a single failure does not take the domain offline.

That very redundancy makes failures invisible: if one of two servers dies, resolvers fall back, some lookups take a few seconds longer, nothing else happens. Such faults often go unnoticed for months, until the second server fails too.

NS records and the SOA serial

Every zone has exactly one SOA record (start of authority). It names the primary (MNAME), the responsible mailbox (RNAME, with the first @ written as a dot) and a serial number that increases with every change to the zone. Secondary servers compare their serial with the primary's and fetch the zone again by zone transfer (AXFR or IXFR) once it is higher. So they do not have to wait for the next refresh, the primary sends a NOTIFY after every change.

• ns1.host.com.: the primary (MNAME) where the zone is maintained.
• 2026093001: the serial, here in the common scheme of date plus a two-digit counter. It only has to increase; many providers set it automatically, some as a Unix timestamp.
• 7200 and 3600: refresh and retry, that is how often a secondary checks in and how soon it retries after a failure.
• 1209600: expire. If a secondary cannot reach the primary for that long (here two weeks), it stops serving the zone.

example.com.  IN NS   ns1.host.com.
example.com.  IN NS   ns2.host.net.
example.com.  IN SOA  ns1.host.com. hostmaster.example.com. 2026093001 7200 3600 1209600 3600

What the check tests

The check resolves every name server of the zone and asks it directly, without a resolver in between:

• Address: every NS name must resolve to at least one IP address. A name without an address is a dead entry.
• Reachability: the server answers an SOA query. If none of its addresses answers, it is unreachable.
• Authority: the answer carries the AA flag. A server that answers, but not authoritatively (REFUSED, SERVFAIL, empty answer), is "lame": it is in the delegation but does not know the zone.
• Serial and data: if a server of the same primary (SOA MNAME) serves a different serial, the check asks every server for the SOA values, NS, MX, TXT, CAA, A and AAAA of the zone. A server that returns different data has missed the latest changes.
• Distribution: a single name server or all addresses in the same /24 network are hints. A power cut, a routing error or a DDoS on that network would take the domain offline completely.

Lame delegation after a provider switch

The classic case: the zone moves to a new DNS provider, but one of the old name servers stays registered at the registrar, or the old NS records remain in the zone. The old provider has deleted the zone and answers with REFUSED. Resolvers that hit this server get no answer and have to try the next one; depending on the resolver, lookups take noticeably longer or occasionally fail altogether.

When moving, change the NS records at the registrar and in the zone together, delete the old zone only after the TTL of the NS records has expired, and then use this check to confirm that only the new servers answer.

A secondary no longer receives the zone

In primary/secondary setups, for example self-hosted DNS with a secondary service, every change reaches the secondary by NOTIFY and zone transfer. If the transfer breaks, because of a firewall, a changed IP address of the primary or an expired TSIG key, the secondary stays on the old state. Its serial lags behind and part of the queries get outdated records: the old mail server, the old IP of the website. Once the expire time from the SOA has passed, it stops answering altogether and becomes lame.

Multiple providers and anycast

If you run DNS with two providers, for example Cloudflare and Route 53 with a tool that keeps both zones in sync, you have two primaries with their own serials. The check therefore only compares serials between servers with the same SOA MNAME and reports the multi-provider setup as a hint.

Some large providers with anycast networks deliberately serve different serials per server or location, because changes do not arrive everywhere at once or the serial is derived from a timestamp. Google, for example, permanently serves different serials on ns1 to ns4 with identical data. The check therefore compares the data itself: if it matches, the different serial is only a hint; A and AAAA records only count as different when a server shares not a single address with the others, because large providers rotate addresses per answer. If the comparison cannot be completed (no answer, time budget), there is neither a warning nor an all-clear; it follows in the next run.

Subdomains and IPv6-only name servers

A subdomain usually has no name servers of its own. If you enter shop.example.com, the check tests the zone it belongs to, here example.com; if the subdomain has its own NS records (a delegated subzone), it tests those servers. Name servers with only IPv6 addresses are only queried when the checking location has IPv6. Otherwise they are listed as not checkable, without a finding.

How to read the result

• All servers reachable, authoritative, same serial: all good.
• Unreachable, lame or without an address: warning for the affected server. The domain usually still works, but with one server less in reserve.
• Different serial and different data for the same primary: warning listing the affected record types. A server serves an outdated state of the zone. Different serial with the same data: hint.
• No server answers authoritatively: critical. The zone is down, website and mail are unreachable.
• Only one name server, all in the same /24 network or zones at several providers: hints. They cost no points in the domain check.

Monitor name servers continuously

A dead secondary does not hurt until the primary fails too, and a forgotten old name server only shows up as an occasional delay. DomainWarn checks the name servers of every customer domain every 6 to 24 hours depending on the plan, confirms a finding in the next run and reports dead, lame and lagging servers while the others still carry the domain.

Frequently asked questions

How is this different from the name servers in the Domain Checker?

The Domain Checker shows which name servers are registered at the registry. The name server check queries the servers of the zone one by one and verifies that they actually answer, are authoritative and serve the same state.

How many name servers should a domain have?

At least two, better three or four, in different networks. Most DNS providers deliver that out of the box; a single server or two servers in the same data centre mostly occur with self-hosted DNS.

Is a different serial always a fault?

No. Some anycast providers count the serial per server, and right after a change it differs for seconds to minutes. The check therefore only warns when a server also returns different data. Monitoring additionally opens an incident only after two runs in a row, so a short propagation phase does not raise an alarm.

Why is a server lame even though it answers?

Lame does not mean silent but without authority: the server answers but does not know the zone (REFUSED) or cannot serve it (SERVFAIL). Usually it is a server of the former DNS provider that is still in the delegation.