Guide
Who answers for a domain: name servers, delegation and resilience
Every DNS zone needs servers that hold the authoritative copy of its records. The NS records point to them. When a site disappears after a change of provider, when only some visitors see an old version, or when a registrar warns about “lame delegation”, the answer is almost always in the name server records. The page lists them for a domain and resolves each one so you can see its addresses.
Two sets of NS records
NS records exist in two places. Inside the zone, the zone’s own file lists its name servers. At the parent, the registry for the top-level domain (for example.com, the .com registry) holds a delegation: the list your registrar publishes when you set name servers in its control panel. Resolvers follow the delegation to find the servers, then use the answers from those servers, including their own NS records. The two lists should match. When they do not, which happens after a half-finished migration, some resolvers use one set and some the other, causing the classic symptom of a site that works for one person and not for another.
What the table shows
The columns are the name server, its IPv4 addresses, its IPv6 addresses and the TTL, followed by a count such as “2 name servers are listed”. The page then runs lookups for each server name, which is how it can say that a server has no address at all. A name server without an address is a dead end for resolvers. The page also warns when there are fewer than two servers or when all of them are in the same network, since a single failure then takes the whole domain offline.
What a healthy set looks like
Two to four servers, each with an IPv4 address, preferably also an IPv6 address, spread over different networks and ideally different providers or anycast clouds. Names that identify the provider are normal: ns1.cloudflare.com-style names, awsdns- names for Route 53, or Google Cloud DNS names. The TTL of NS records is usually long, a day or more, because they rarely change; that is also why a change of name servers takes time to be noticed everywhere.
A worked example
Press Sample to look up example.com. The page lists two name servers at Cloudflare, hera.ns.cloudflare.com and elliott.ns.cloudflare.com, each with three IPv4 and three IPv6 addresses, and a TTL of about a day. It prints “2 name servers are listed” and the resolver status. When this guide was reviewed the NS TTL was 86,339 seconds, almost exactly a day, counting down from 86,400. The page raises no warning because both servers have addresses and are spread over different networks.
Limits
The lookup shows what the resolver you chose sees, which may be cached. It cannot show the registry’s delegation separately, so a mismatch between registry and zone shows only indirectly, as different answers over time. It does not query each name server to check that it serves the zone. For that, use dig against each server; for the zone’s start-of-authority data see the SOA Lookup.
Related tools
- SOA Lookup shows the zone’s serial number and timers.
- DNSSEC Analyzer checks the chain of trust from the parent.
- DNS Propagation Checker compares answers from two resolvers after a change.
- DNS Lookup shows all common records of the domain.
Checked against the current version of the NS Lookup on .