What does a DNS referral response contain, and how does a recursive resolver use it to choose the next server to query?

## What a referral is RFC 9499 defines a **referral** as a response in which a server, "signaling that it is not (completely) authoritative for an answer, provides the querying resolver with an alternative place to send its query". It arises when a server is not recursing and the name lies below a **zone cut**: the point where the parent zone stops and a delegated child zone begins. The ordinary kind is a **downward referral**, pointing to servers for a zone closer to the name. RFC 9499 also describes an **upward referral** (usually pointing back at the root), which no server is required to send and which some regard as a sign of misconfiguration. ## Anatomy of a referral Suppose a recursive resolver asks a `com` server for `www.example.com`, type `A`. The `com` zone holds a delegation for `example.com`, so RFC 1034 section 4.3.2 step 3(b) applies: copy the child's NS records into the authority section and put whatever addresses are available into the additional section. ```dns ;; reply from a com server; rcode NOERROR, AA clear ;; ANSWER SECTION: (empty) ;; AUTHORITY SECTION: example.com. 172800 IN NS ns1.example.com. example.com. 172800 IN NS ns2.example.net. ;; ADDITIONAL SECTION: ns1.example.com. 172800 IN A 192.0.2.53 ``` | Section | Contents in a referral | |---|---| | Header | Response code NOERROR; **AA clear** | | Answer | Empty, or a CNAME the server already followed within its own data | | Authority | The **NS RRset** for the delegated child zone | | Additional | Addresses for those name servers that the server has; for a name inside the child zone this is **glue** | The AA bit is clear for a reason: RFC 2181 section 6.1 says the NS records at a zone cut are "the property of the child zone", and a server "should not return authoritative answers for queries related to names in another zone". ## What the recursive resolver does with it RFC 1034 section 5.3.3 describes the resolver's handling as part of its loop: 1. **Check progress.** The delegation must be "closer" to the name than the servers in its current list, measured by how many labels the delegated zone shares with the name. "If not, the reply is bogus and should be ignored." 2. **Cache the delegation.** The NS records and any addresses are stored for later lookups. 3. **Rebuild the candidate list.** The new name servers replace the old list, sorted by what the resolver knows about them, such as past response times. 4. **Pick a server with an address and send the same question.** If it fails or does not answer, move to the next. 5. **Repeat** until an answer, a name error, or a failure of every candidate. ## When the addresses are missing Glue exists because of a circular dependency. RFC 1034 notes that without it "the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn". Rules about when a zone must publish glue belong to zone delegation; the effect on resolution is what matters here: - **Name inside the child zone** (`ns1.example.com` for `example.com`): the address comes as glue, and the resolver can continue at once. - **Name in an unrelated zone** (`ns2.example.net`): the `com` server need not supply an address. If the resolver picks that server, it must first resolve `ns2.example.net`, a lookup that can itself start at the root. - RFC 1034 suggests starting those address lookups **in parallel** while continuing with any server whose address is already known, and puts **bounding the work** first among a resolver's priorities. ## How much the resolver trusts it Referral data is useful for finding servers, not for answering clients. RFC 2181 section 5.4.1 ranks data by trustworthiness, and places data from the authority section of a non-authoritative answer and additional information near the bottom. Such data "should not be cached in such a way that they would ever be returned as answers to a received query". When the child zone's own servers later return their NS set in an authoritative answer, that copy outranks the parent's. ## Telling a referral from look-alikes - A **NODATA** reply also has NOERROR and an empty answer. RFC 2308 distinguishes them by the authority section: a SOA record, or the absence of NS records, marks NODATA; NS records for a lower zone mark a referral. What NODATA means belongs to the message-format topic. - A **name error** carries the NXDOMAIN code, so it is never a referral whatever its authority section holds.