Test DNS › DNS guides

Common DNS delegation errors and how to diagnose them

A domain that resolves intermittently, a subdomain that cannot be found, a zone changed with no effect: almost always the same handful of delegation errors. Recognising them requires a method that starts at the parent and works down, rather than querying at random.

Hand-annotated cabling plan sheet in a comms room — The diagnosis follows delegation from the parent to the child, the way you follow a cabling plan.

The method: start at the parent, work down

The reflex is to query the local resolver, which often answers from its cache and masks the real state. The right sequence goes back to the root and follows the delegation: ask the root, then the top-level domain server, then the authority. Each step must return either a delegation to named servers or an authoritative answer.

Resolution tools let you follow that path step by step, and above all query a specific server with recursion disabled. That last option is the most useful part of the diagnosis: it shows what the server actually knows, without a cache distorting the reading.

A third check completes the method: query each server listed in the NS records, separately. An NS set in which one member does not respond, or responds without authority, produces exactly the symptom of intermittent resolution, with no error appearing on the child zone side.

Lame delegation

A delegation is said to be lame when a server is listed in the delegation but is not authoritative for the zone: it does not load it, or loads it under another name. When queried, it returns a reference to another server, or an error. A resolver that lands on it must then retry elsewhere, which adds latency and failures depending on how queries are distributed.

The typical symptom is a domain that works most of the time and sometimes fails, with temporary resolution errors. The diagnosis is direct: querying the suspect server without recursion for the zone name must return an authoritative answer. Any other answer points to the server to be fixed, or to be removed from the delegation.

Missing or stale glue

When the target of an NS record belongs to the delegated domain, the parent zone must supply its address. Without that glue record, the resolver cannot reach the server without resolving the very name it is looking for, and resolution comes to a dead end. This is an error in the parent zone, and therefore often on the registrar's side, not the server's.

The most frequent case is not missing glue but stale glue: a server changes address, the child zone is updated, the parent zone keeps the old address. The domain then appears broken although everything is correct on the hosting side. After any address migration, the check must cover the records published by the parent.

Diverging NS sets

The child zone publishes its own NS at the apex, and the parent publishes the delegation. The two sets should agree. When they differ, behaviour depends on the server queried: some resolvers follow the parent, others the child zone, and users do not see the same thing depending on where they sit in the network.

This case arises during an incomplete hosting change: the new servers are declared at the registrar, but the old provider keeps publishing its own NS in the zone. It also arises when a server is removed on one side only. Checking both sets is part of the end-of-migration checks, on a par with the zone contents.

Content errors that break resolution

Some errors, described in RFC 1912, make a zone invalid or a name unusable. A CNAME at the zone apex prevents coexistence with the NS and SOA records: the domain name itself becomes impossible to serve correctly. A CNAME at the same name as a mail or address record produces a contradiction that resolvers handle in varying ways.

Two other traps come up often: the target of an MX or NS pointing to a name that is itself a CNAME, and the missing trailing dot on an absolute target, which turns an external name into a name internal to the zone. The latter case frequently produces records that look correct on reading and do not work.

A syntax check of the zone file catches some of these errors, but not inconsistencies between zones. Hence the value of verification by querying, which measures what resolvers will actually see.

Serial and time-to-live errors

A change published without the serial number being increased will never be transferred to the secondaries: the child zone looks up to date on the primary, and the other servers serve the old version. The discrepancy only shows when comparing serials, server by server, which makes it a lasting and silent error.

Conversely, a very low TTL applied everywhere to avoid caching problems multiplies queries to the authority and reduces the service's resilience in the event of an incident. An SOA minimum that is too high freezes negative answers and makes unfindable names persist. These settings are decided by usage, not by blanket precaution.

The final check sequence comes down to five questions: does the parent delegate to the right servers, is the glue up to date, does every listed server answer authoritatively, are the serials identical, and are the time-to-live values consistent with usage. A domain that passes these five checks resolves, barring a network failure.

References

To check a domain name live — root, TLD, name servers — use the DNS test tool. Demarcq.net runs DNS servers: managed DNS operations.

← Logging and monitoring a DNS server end of the series →