Summary

  • A root-hints file is a bootstrap route, not a continuing statement of DNS authority. Its addresses let an empty resolver ask the root for current root-server information.
  • RFC 9609 defines the exchange: query . for NS, expect an authoritative root NS answer, cache it normally, expire it by TTL, and retry another configured address if the first target does not answer.
  • The design separates two kinds of evidence. Configuration says where a resolver might begin; the DNS response supplies the current, expiring state the resolver should actually use.

Analysis

At first boot, a recursive resolver can know less than its configuration file appears to say. A typical root-hints file lists addresses associated with the root server identifiers. Those lines are necessary because an empty cache cannot discover the root by asking a name server it has not yet found. Yet the file is not the root zone, and its age does not decide who is authoritative. It is a route toward a question.

The question is unusually compact. The resolver sends a query with the root name, ., as QNAME, NS as QTYPE, and the Internet class. RFC 9609 calls this a priming query. One configured address is enough to start. The response should leave the resolver with the root NS resource-record set and the available IPv4 and IPv6 addresses for those identifiers. What began as distribution-time configuration becomes ordinary cached DNS data.

That replacement is the mechanism's point. RFC 9609 says a resolver starts with no cached root-server information and finishes with a full list of names and addresses in its cache. The configured addresses are described as purported addresses: they are presumed useful, but the resolver does not elevate them into timeless operational truth. The answer is authoritative, carries a TTL, and enters the same cache lifecycle as other DNS data.

The idea reaches back to RFC 1034. Its resolver algorithm named a fallback structure SBELT, a safety belt. When cached NS information could not identify a server to ask, the resolver copied configured helpful servers into its working list. The metaphor was exact. A safety belt keeps the search from falling into an empty state; it does not steer every later query.

RFC 8109 isolated that old behaviour into a Best Current Practice in 2017. RFC 9609 replaced it in 2025, keeping the core exchange while sharpening what the starting information contains and what a valid response must look like. The update also dealt more explicitly with prefetching, incomplete address sets, root-server identifiers, and the fact that a priming response is not a referral.

The query contract matters because it limits ambiguity. The Recursion Desired bit should be zero. EDNS0 should be used, and a resolver should be prepared to reassemble at least 1024 octets. If UDP is used, its source port should be selected randomly; DNS Cookies may add another obstacle to off-path spoofing. These are defenses around a bootstrap exchange whose corruption could misdirect every later lookup.

RFC 9609 elevates the expected response properties to normative requirements. The response must be NOERROR, must have the Authoritative Answer bit set, and must carry the root NS RRset in the Answer section. The Authority section must be empty because the answer already contains that RRset. The Additional section carries the A and AAAA data available for the listed root server identifiers.

It is tempting to call those addresses glue. RFC 9609 says not to. Priming is a direct answer for the root NS RRset, not a referral to a child zone. The addresses in Additional therefore do not acquire the referral-glue semantics governed by RFC 9471. A response can omit some addresses without setting the Truncated bit, and repeating the same query may reproduce the same omission.

The recovery path is more deliberate. The resolver can issue direct A and AAAA queries for identifiers whose addresses were missing. It should not expect exactly thirteen NS records in every response merely because the current IANA hints snapshot contains thirteen identifiers. Completeness is something the resolver can assemble, not a magic property inferred from a familiar count.

Time then takes over. A resolver should prime when its cache is empty or when the cached root NS RRset expires. The NS records are not exempt from TTL processing. A resolver may prefetch before expiry; if it does, RFC 9609 recommends asking addresses already in cache rather than falling back immediately to possibly stale configured addresses. Current learned state should renew itself before old bootstrap state is consulted again.

Failure also has a prescribed direction. If one priming target does not respond, the resolver must retry a different configured address. Target selection should be random across the usable configured set, spreading load and avoiding dependence on a single starting address. This is redundancy with a purpose: the file does not need every line to work, but it must offer more than one credible path out of emptiness.

The IANA named.root snapshot frozen for this article labels itself as related to root-zone version 2026072901. It contains thirteen root identifiers, each with one A and one AAAA record, and presents a TTL of 3,600,000 seconds. Those are facts about this file, not claims about physical machines. Each identifier fronts an anycast service with many instances, and the operating system behind the root cannot be reduced to thirteen boxes.

Security is the difficult remainder. A forged priming answer can redirect the resolver toward servers chosen by an attacker. Because the root sits above every delegation, false starting data has greater reach than a false answer lower in the tree. RFC 9609 is careful: there is no definitive way to prevent priming-response redirection until those responses are protected with DNSSEC. Validation of the later query chain can expose some attacks, but it does not turn the hints file into authenticated authority.

After priming, the resolver still has policy choices. It may measure name-server speed, group servers into performance bands, or randomise within a usable set. The BCP does not mandate one strategy, beyond advising that the root should not be treated as a mystical exception. The root NS RRset is important, but it remains DNS data subject to cache, reachability, latency, and expiry.

The historical lesson is not that the DNS escaped configuration. It is that configuration was given a disciplined boundary. A vendor or operator may ship an address that helps a resolver ask its first question. Authority answers that question. TTL decides when the answer becomes old. Retry policy keeps one dead path from becoming the whole system. Continuity comes from knowing which evidence is only a hint—and arranging for a better answer to replace it.

Sources