Another referral, one label further down

The resolver does not jump to an answer; it follows a chain of handoffs, each one narrowing by exactly one label.

A whiteboard with a delegation tree drawn on it in marker — Each step of a lookup is answered by a machine that knows one thing: who to ask next.Photograph

The structure of a referral

Every DNS query names a full domain — say, mail.example.com — but no single server is expected to know the whole thing. The root knows only who is responsible for .com. The .com registry knows only who is responsible for example.com. The authoritative servers for example.com know what mail.example.com resolves to. Each server in that chain holds authority over exactly its slice, and its answer to anything outside that slice is a referral: here is the next set of nameservers, one label further in.

The referral itself arrives as a DNS response with the ANSWER section empty and the AUTHORITY section populated with NS records pointing one level down. Often the ADDITIONAL section carries the addresses of those nameservers as A or AAAA records — the glue that saves a second lookup when the nameserver's own name falls inside the delegated zone. When glue is absent and still needed, the resolver must chase that address separately before it can proceed, adding a round trip for each missing record.

A patch panel with numbered ports and neatly combed fibre looms — Numbered ports are a name’s last hop. Everything above them is a chain of referrals that exists only as records in other people’s zones.Photograph

One label at a time

The hierarchy is strict. A referral from the root servers hands off to a TLD operator; a referral from the TLD hands off to the zone operator. Nothing skips a level. This matters because each handoff is also a trust boundary: the parent zone signs the DS record that vouches for the child zone's keys, and DNSSEC validation checks that signature before following the referral. A response that tried to jump two levels would have no parent signature to verify, and a validating resolver would reject it.

In practice this means the depth of the delegation chain is exactly the number of labels in the name, minus the implied root. A three-label hostname passes through root, TLD, and second-level zone — two referrals before the third server, the authoritative one, gives an actual answer. Longer names, such as those in ccTLD hierarchies with a registry/registrar split at the third level, add another step. Each additional label is another server that must be reachable, another TTL to respect, another place the chain can break.

Where chains break

A delegation is only as sound as the weakest link. The parent must carry NS records that name servers that actually exist and are actually configured to answer for the zone. When that condition is not met — when the parent points at a server that has no knowledge of the zone — the referral arrives, the server returns SERVFAIL or REFUSED, and the resolver has nowhere left to go. The query fails not because the record is missing, but because the handoff arrived somewhere that cannot complete it.

SOA serial mismatches introduce a subtler failure. If secondary nameservers listed in the parent's NS records have not yet transferred the zone, they may answer authoritatively with stale or absent data. IANA's delegation records ↗ are public; checking what the parent actually publishes against what the operator believes it publishes is often the first diagnostic step when a delegation behaves unexpectedly.

The chain also depends on cached referrals being current. NS records at the TLD have their own TTL, and a resolver that cached them before a nameserver change will keep sending queries to the old servers until that TTL expires. The IETF's guidance on DNS operational practices ↗ has long recommended that NS TTLs be set with this propagation window in mind — long enough to avoid excess queries, short enough that a necessary change reaches resolvers within a predictable horizon.

Each server in that chain holds authority over exactly its slice, and its answer to anything outside that slice is a referral: here is the next set of nameservers, one label further in.

The referral mechanism is simple to describe and unforgiving in operation. Every label in a name is a dependency, and every dependency is a thing that can be misconfigured, expired, or simply absent.

A machine room seen down a cold aisle, one adult operator standing mid-row with an open laptop — A cold aisle holds the machines that answer. The walk described here crosses several rooms like this one, none of which knows what the others hold.Photograph

If secondary nameservers listed in the parent's NS records have not yet transferred the zone, they may answer authoritatively with stale or absent data.