Delegation and Zone Cuts: Where Authority Changes Hands

The DNS namespace is a single tree, but it is not served by a single database. It is partitioned into zones, and a zone is defined by a file that some server is authoritative for. The boundary between one zone and the next is a delegation: a point in the tree where the parent stops answering and instead tells the client which servers to ask next. Almost every surprising DNS behaviour, whether missing records that exist, answers with the wrong authority bit, or referrals that never resolve, comes from misunderstanding what a delegation does and does not transfer.

A zone is a set of names, not a set of labels

A zone contains a name and every name beneath it except those beneath a delegation. That exception is the whole mechanism. When the parent zone contains an NS RRset at a name that is not its own apex, that name is a cut: the parent holds the NS records (and possibly DS and glue) for the child, and holds nothing else below it.

Consider a parent zone example. that delegates sub.example. to two servers. The parent’s zone file contains:

sub.example.        86400 IN NS ns1.sub.example.
sub.example.        86400 IN NS ns2.elsewhere.net.
ns1.sub.example.    86400 IN A  192.0.2.53

Everything else about sub.example., including its apex SOA, its mail exchangers, and any name under it, lives in the child zone and is invisible to the parent. If the parent also carried an A record for www.sub.example., that record would be unreachable: queries for the name go to the child’s servers, and the parent answers a query for anything below the cut with a referral rather than from its own copy. Data below a cut that the parent is not supposed to hold is either glue or a configuration error.

The apex of a zone is the only place where the zone’s own NS RRset is authoritative data rather than a delegation. At the apex, the NS RRset and the SOA are the two records that define the zone’s existence, and both are answered with the AA bit set. One level down, the same NS RRset is a referral and is answered with AA clear. This is why the same record type carries opposite meaning depending on its position, and why a resolver cannot decide whether a response is authoritative from the record type alone.

What the parent returns when the child has the answer

A query for www.sub.example. arriving at the parent produces a response with an empty answer section, an authority section holding the child’s NS RRset, and an additional section holding the addresses of those name servers. The response code is NOERROR, not NXDOMAIN. This is the referral, and its shape is the reason a resolver must look at the authority section even when the answer section is empty.

The absence of NXDOMAIN in a referral is a deliberate distinction. The parent is not claiming the name does not exist; it is claiming it has no authority to say. A resolver that treats an empty answer as a negative answer would break every name below every delegation, which is the failure mode of resolvers that inspect only the answer section.

Glue exists to break a circular dependency. To ask ns1.sub.example. about www.sub.example., a resolver needs ns1.sub.example.’s address. That address lives in the child zone, which cannot be queried until the address is known. The parent therefore includes the address records for in-bailiwick name servers in the referral’s additional section, even though those records belong to the child zone and the parent is not authoritative for them. Glue is not authoritative data: it is not signed, it is not cached as an answer to the address query, and a resolver that caches it must treat it as an optimisation that may be stale.

RFC 9471 tightened the rules here. Glue is mandatory for name servers at or below the delegated name, and a server that cannot fit all of it must set TC rather than send an incomplete referral. For a name server in a sibling domain the parent should supply the glue it already holds and may set TC when that glue does not fit; for a server outside its bailiwick it has none to give, and the resolver looks that name up for itself.

The bailiwick concept generalises: a server’s bailiwick is the set of names for which it is authoritative or for which it holds legitimate glue. A response whose additional section carries addresses outside the responder’s bailiwick is a candidate for cache poisoning, and resolvers are expected to discard such records rather than cache them. That rule is the reason an authoritative server cannot simply stuff useful-looking addresses into every response.

The four ways a delegation fails

The first failure is a lame delegation: the parent lists a name server that is not authoritative for the child zone. Queries arrive, the server responds with a referral back to the parent or with a refusal, and the resolver has to try the next name server in the set. A delegation where every listed server is lame resolves to nothing, and the parent has no way to detect this from its own data. Detecting it requires querying the child, which the parent is not required to do.

The second is a missing delegation. A name exists in the child zone but no NS RRset in the parent points at the child, so the name is unreachable even though a server somewhere holds it. This is a common form of “the record is definitely there” confusion: the record exists in a zone file that no delegation reaches.

The third is a delegation to an unreachable address. Glue can be stale, or the address can be filtered by a network the resolver sits behind. Since the address is the only bootstrap path, a wrong glue record makes the child invisible to resolvers that have no cached copy of the real address.

The fourth is a delegation whose NS RRset at the parent and at the child disagree. The parent’s copy is what resolvers see when following a referral; the child’s apex copy is what they see when they reach the child directly. Mismatched sets mean different resolvers use different server lists depending on cache state, which produces intermittent resolution that is hard to reproduce.

Each of these is a consistency property between two independently maintained databases, which is the structural cost of delegation. The alternative, a single central database, would eliminate the class entirely and would not scale to the number of names in use or the number of organisations that need to edit them without coordination.

Zone cuts and the wildcard boundary

A wildcard in the parent does not cross a cut. The wildcard *.example. matches names in example. that do not exist and are not below a delegation. A name below sub.example. is out of the parent’s scope, so the wildcard does not synthesise an answer for it, and the query is referred instead. RFC 4592 spells out this interaction because early implementations disagreed, and the disagreement produced answers that appeared to come from the parent for names the parent had no authority over.

The same boundary logic governs the SOA. A negative answer from the parent for a name below a cut would need the parent’s SOA to supply the negative TTL, and the parent has no business supplying one. Negative answers therefore always come from the zone that owns the name, which is why the SOA in the authority section of a negative response identifies the zone that made the claim. Negative Caching and the NXDOMAIN Distinction follows this through to the cache lifetime rules.

Reading a delegation from the parent’s side

The practical way to inspect a delegation is to query the parent’s servers directly for the child’s NS RRset and for the child’s DS RRset, with recursion disabled. The NS answer comes back as a referral with AA clear, glue in the additional section. The DS answer, if present, comes back as authoritative data with AA set, because the DS record is signed by the parent and belongs to the parent zone. That asymmetry is the clearest evidence of where the cut falls: DS is parent-side data, NS at the cut is parent-side data about the child, and everything else is child-side.

This is also why DNSSEC’s chain of trust runs parent to child through DS rather than through NS. A signature on the child’s DNSKEY can only be trusted if the parent vouches for the key’s hash, and the DS record is the parent’s signed statement about the child. The delegation carries authority; the DS record carries the cryptographic form of that authority. DNSSEC Validation and the Chain of Trust covers what a resolver does when the two disagree.

A resolver following a referral has one more decision to make: whether to accept the referral at all. A server that is authoritative for example. should only refer to zones beneath example.. A referral to an unrelated name is either a configuration error or an attempt to redirect the resolver’s query, and the standard defence is to check that the referred name is a proper suffix of the name being queried. Without that check, a compromised or misconfigured server can point a resolver at an attacker-controlled zone for any name, which is a delegation hijack performed one response at a time.