Name server problems: not answering, lame delegation, and mismatches

What it means when a name server doesn’t answer, answers without authority, or disagrees with the others, and how to fix a half-done move.

Name servers hold a domain’s DNS records and answer for them. The registry for the domain’s ending lists which name servers those are, set through your registrar, and every resolver starts there. RFC 1034 asks for at least two, and each should give the same answers.

If one name server is down, or doesn’t have the zone, lookups slow down while resolvers try another. If none of them work, the domain stops working once resolvers’ saved answers run out.

What SignalDNS checks

The report and the DNS lookup ask the zone’s own name servers directly, without recursion, so we see their current answers rather than a saved copy.

  1. We find the zone: the nearest name with NS records, walking up from the name you entered, at most four names, stopping short of the domain ending. For www.example.com, that’s usually example.com.
  2. We take up to six name servers from the first resolver’s NS answer and look up each one’s IPv4 address. We only contact public addresses.
  3. We ask each for the zone’s SOA record, which shows whether it answers with authority for the zone, and which version of the zone it has.
  4. We ask each one that does for the name’s records of every type in the check, except DS, which lives on the registry’s side.

Then we check that every name server answers, and that they agree. For a registered domain, we also compare the registry’s list with the zone’s NS records.

A name server isn’t answering

Asked directly, a name server timed out, refused to answer, returned SERVFAIL, or sent something we couldn’t use. The report says which, and marks it as needing attention. If it says a server “doesn’t answer for” the zone, see lame delegation. If a server has no IPv4 address, or one that isn’t public, see A name server has no public IPv4 address.

Resolvers that pick that server have to wait and try another, which slows lookups. If the others fail too, the name stops working. A refusal can mean the server doesn’t hold the zone at all.

How to fix it:

  1. Check with your DNS provider that the zone is active, and whether it reports an outage.
  2. If you run the server yourself, check that it’s running and that its firewall allows DNS on port 53, over UDP and TCP.
  3. If the server is no longer in use, remove it from the name servers at your registrar and from the zone’s NS records.

A name server doesn’t answer for the zone (lame delegation)

The server answered, but not with authority for the zone: it sent a referral, said the zone doesn’t exist, or had no SOA record for it. It’s listed as one of the zone’s name servers, but it doesn’t serve the zone. That’s called lame delegation.

It happens when:

  • The zone was deleted from a DNS provider, or never added, but the provider’s name servers are still listed.
  • A move between DNS providers left an old name server in the list.
  • A name server’s name has a typo, so it points at a different server.

How to fix it: if you meant to use that provider, add the zone in its dashboard, and use the exact name servers it shows for this domain; they can differ from one account or zone to the next. If you didn’t, remove the server from the name servers at your registrar and from the zone’s NS records.

A name server has no public IPv4 address

We couldn’t contact a name server because its name has no IPv4 address, or its address is private, such as 192.168.1.10, which resolvers on the internet can’t reach. We only ask over IPv4, so a name server with only an IPv6 address shows here as having none, and resolvers limited to IPv4 can’t reach it either.

Common causes:

  • Missing glue. A name server under the domain itself, such as ns1.example.com for example.com, needs its addresses registered at the registry. These are called glue records. The registration answer shows any glue the registry holds beside each name server.
  • A typo or a deleted record. The name server’s name doesn’t exist, or its A record was removed.

How to fix it: check the name server’s A record. For a name server under your own domain, add or correct its glue records at your registrar. If it has a private address, give it a public one, or remove it from the list.

None of the name servers answer

Not one of the zone’s name servers answered with authority when we asked directly. Resolvers may still have answers saved, so the name can keep working for a while, which is why this needs attention rather than counting as a problem. When those copies run out, the name stops working.

Look for an outage at the DNS provider, a zone deleted or never set up there, or name servers left pointing at an old provider after a move.

How to fix it:

  1. Check that the zone exists and is active at your DNS provider.
  2. Compare the name servers set at your registrar with the ones your provider says to use. They must match exactly.
  3. If the old provider has deleted the zone after a move, update the name servers at the registrar to the new provider now.

Name servers give different records

Two or more name servers returned different records for the same type, such as MX or TXT. Each resolver gets the answer from whichever server it asked, so some visitors see one version and some another. SignalDNS marks this as needing attention.

It can last a few seconds after a change. Longer means one server isn’t getting updates, such as when two DNS providers serve the zone and a change was made at only one, or a secondary server has stopped copying from its primary.

We don’t flag differences in A, AAAA, or HTTPS records, which some DNS services vary on purpose, by location or at random. We don’t compare SOA records either, since each provider serving the zone writes its own.

How to fix it: if you use more than one DNS provider, make every change at all of them, or set one up to copy from the other with zone transfers. If you run your own servers, check that the secondaries are transferring from the primary.

The registry and DNS list different name servers

The name servers listed at the registry, which your registrar sets, don’t match the zone’s own NS records. Resolvers start from the registry’s list and may then use the zone’s NS records, so different resolvers can end up at different servers. That often means a move between DNS providers is half done: the registrar was updated but not the zone, or the other way round.

This is a cross-check of the registration answer against DNS, so it appears under “Who is it registered with?” once both checks have finished. We run it only when the name you checked is the registered domain itself, since only that name has NS records at the registry.

How to fix it: decide which provider should serve the domain, then make both lists match it.

  1. At your registrar, set the name servers to that provider’s.
  2. At that provider, check that the zone’s NS records list the same servers.
  3. Keep the zone at the old provider for at least two days. Amazon’s Route 53 guide says registrars typically use a TTL of 24 to 48 hours for name servers.

Name servers have different zone versions (SOA serials)

Each name server’s SOA record carries a serial number, a version for the zone. We show each server’s serial, but don’t compare them. When two DNS providers serve the same zone, each numbers its copy in its own way, so the serials needn’t match even when the records do. We compare the records instead, and if they match, the serials don’t matter.

Serials do matter with classic primary and secondary servers: a secondary copies the zone only when the primary’s serial goes up. If you run your own servers and a secondary’s serial stays behind, it has stopped updating, and its records can start to disagree.

Your provider’s guides

What we can’t tell from outside

We ask from one server, over IPv4, and at most six name servers. A server that answers us can still fail for others, such as over IPv6, and one that shares its address across locations can fail at only some of them. We don’t try zone transfers. A server that doesn’t answer once may have had a brief network problem, so check again before changing anything.

Sources

Last reviewed .