Summary

  • RFC 9609 moves a recursive resolver from inherited bootstrap addresses to current DNS data. The configured list is a way to begin asking; it is not the finished root view.
  • A valid priming response has NOERROR, AA, the root NS RRset in Answer and an empty Authority section. It can still omit some A or AAAA records from Additional without setting TC, because the response is not a referral and those addresses are not glue under RFC 9471.
  • A resolver must close the gap explicitly: retry a non-responsive target against a different configured address, identify missing names, query their A and AAAA records directly, admit the results to cache and then observe actual resolution. Each stage is its own receipt.

The resolver has just started. Its cache is empty, but its software package contains a list of IP addresses said to reach the DNS root. It sends a query for the root NS RRset and receives what looks like a perfect green light: NOERROR, the Authoritative Answer bit, the expected NS records in the Answer section and no Authority section at all.

An operator could reasonably call that transaction successful. It was. The error begins when success is enlarged into a claim the response did not make. The Additional section may not contain every IPv4 and IPv6 address for every root-server identifier. The server is not required to set the Truncated bit merely because some of those addresses are absent. Asking the same question again may reproduce the same omission.

RFC 9609 makes this edge case part of Best Current Practice rather than a footnote. Published in February 2025 as BCP 209, it replaces RFC 8109 and describes how one common class of recursive resolver initializes its cache. The lesson is larger than DNS startup: an authoritative answer, an authenticated record set, a complete dependency set and a working service are four different forms of evidence.

Configuration is a starting witness

The original DNS architecture in RFC 1034 describes a resolver beginning with an empty cache and a safety-belt structure—historically called SBELT—containing places from which it can ask about the root. Modern software normally receives those addresses from a vendor or distributor. That package is useful precisely because a machine with no cache cannot discover everything from nothing.

But the list is inherited memory. It can be accurate when shipped and stale years later. Root-server identifiers have been stable for decades, while their addresses can change. RFC 9609 therefore does not ask configuration to be the permanent source of operational truth. It asks configuration to make the first successful contact possible, then lets current DNS data take over.

The priming query is deliberately ordinary: QNAME ., QTYPE NS, QCLASS IN. It can travel over UDP or TCP. The Recursion Desired bit should be zero. When UDP is used, source-port randomization under RFC 5452 makes forged answers harder, and RFC 7873 cookies can add another obstacle. RFC 6891 EDNS support lets the resolver advertise a useful message size.

Each measure answers a bounded question. A random source port is not freshness. A cookie is not address completeness. EDNS capacity is not proof that the sender included every available record. A configured destination that responds is not proof that every other configured destination is current. The startup chain works because these controls are composed, not because one control silently contains all the rest.

Failure must change the target

RFC 9609 makes target diversity operational rather than decorative. If a priming query receives no response, the resolver must try a different address from its configuration. Repeating against the same unreachable target would test persistence, not recoverability.

The initial target should also be selected randomly from the configured addresses. That spreads load across root-server identifiers and prevents a fixed first entry from becoming an accidental centre of gravity. A resolver may choose IPv4 or IPv6 based on what it knows about local connectivity; the standard does not pretend both paths are always equally usable.

After priming, the preference changes. If the root NS RRset is still in cache and the resolver prefetches before expiry, it should query an address from that cached state rather than return to potentially old installation data. The authority of the bootstrap list is thus designed to diminish after use. It is a ladder, not a throne.

This is where the distinction drawn in Heng Lu's minimum-initial-specification note becomes practical. The common layer supplies only enough deterministic structure to enter interoperable operation. Later choices—such as which responsive root server to prefer—remain local. RFC 9609 names common strategies but refuses to make one universal. Running resolvers measure and choose.

The success shape is exact but narrow

A priming response must have NOERROR and AA set. The root NS RRset belongs in Answer because it originates at the root. Authority is empty because the answer already contains that RRset. Additional carries A and AAAA records for the named servers.

Those requirements matter. They let an implementation reject responses that do not have the expected protocol shape. They do not turn the shape into a completeness guarantee.

The standard specifically says software should not expect 13 NS records. The number is familiar enough to be seductive, but it is not the validity rule. Nor should one confuse identifiers with operators or physical instances. RFC 9609's publication-time description counted more than 1,500 instances, but that historical observation is not a current census and is not needed to validate a priming response.

The response should enter the cache as ordinary DNS data. That phrasing is important. Root information is operationally consequential, yet its TTLs, expiry and reuse are not granted a mystical status outside the cache model. The root zone is not to be treated as special when a primed resolver later chooses among cached name servers.

TC is not a completeness receipt here

The hardest operational detail is the absence of an alarm. The combined A and AAAA address material can exceed a response's available size. Some addresses can therefore be absent from Additional. Many protocols teach operators to look for TC=1 as the sign that a DNS response was cut short. Priming breaks the casual version of that intuition.

RFC 9471 requires authoritative servers to set TC when message-size constraints prevent complete glue from being included in a referral. A priming response is not a referral. The root-server addresses in its Additional section are not glue for that rule. RFC 9609 consequently states that there is no required number of root-server addresses in the response and no expectation that TC will confess their omission.

This produces a precise evidence boundary:

  • NOERROR says the server returned no DNS error.
  • AA says the responder is authoritative for the answer.
  • the NS RRset says which identifiers are named at that observation point.
  • DNSSEC validation can authenticate a signed RRset within its chain.
  • Additional supplies some address material.
  • TC has its protocol meaning, but TC=0 does not certify that all desired root addresses arrived.
  • a populated cache does not by itself prove that every cached address is reachable from this resolver.

The green lights are real. They are merely local.

Repetition may repeat the blind spot

If a server emits Additional records in a fixed order, sending the same priming query again can return the same prefix and omit the same tail. Retry volume then increases while information gain remains zero.

RFC 9609 gives the resolver a different task: determine which root-server identifiers lack address information and issue direct A and AAAA queries for those names. The recovery changes the question. It converts an unstructured hope for a larger repeat into a bounded reconciliation operation.

That distinction belongs in monitoring. A “priming succeeded” counter should not be asked to stand for “all desired address families were learned.” Operators need at least the structural response result, the validated NS-set result, address coverage by identifier and family, direct-query completion, cache admission and subsequent reachability. Aggregating those into one green indicator destroys the causal path needed during failure.

A signed name set does not sign every address

At RFC 9609's publication, the root NS RRset was signed and a validating resolver could authenticate it. The relevant A and AAAA records were under root-servers.net, which the RFC states was not signed at that time. The Article must preserve that date boundary: standards text records the conditions it described, not a perpetual fact about future DNS state.

The security consequence is still instructive. A forged priming response can try to install attacker-controlled root addresses. A validating resolver will detect false data when the later chain reaches signed material, but unsigned delegations and zones do not inherit protection simply because the root NS RRset was authentic. Authentication attaches to particular data under particular validation paths.

The DNSSEC introduction in RFC 4033 explains the security services and their limits. It does not convert availability, policy correctness or completeness into signature properties. A resolver also needs robust query selection, cache handling and observation of resulting behavior.

A local root changes distance, not evidence classes

RFC 8806 describes serving a full root-zone copy locally to a resolver. RFC 9609 says that such a resolver can prime its cache using the same methods. Locality can reduce dependency on a remote exchange and change latency and failure exposure. It does not make configuration, authoritative data, cache state and observed resolution identical.

A local service can be running while its copy is stale. A valid zone can be loaded while the resolver is pointed elsewhere. A successful local response can populate only the fields that response contains. “Local” is a topology statement, not a universal proof of correctness.

The operating record should show the handoff

Leadership teams rarely need packet-level detail for its own sake. They need to know which evidence would distinguish a bad package, unreachable starting addresses, a malformed response, an incomplete Additional section, failed direct lookups, bad cache admission and a later resolution failure.

The useful record is a handoff ledger:

  1. Which configured addresses were available at startup, and from which software or operator revision?
  2. Which address was selected, over which family, and did a response arrive?
  3. Did the response satisfy NOERROR, AA, Answer and Authority requirements?
  4. Which root NS RRset was accepted, with what validation result and TTL?
  5. Which identifiers had A and AAAA coverage in Additional?
  6. Which missing records triggered direct queries, and what did those queries return?
  7. What was admitted to cache, and when will it expire?
  8. Which cached targets were actually reachable from the resolver?
  9. Did subsequent resolution succeed separately for signed and unsigned paths?

This ledger does not centralize future server choice. It makes the local choice inspectable. It follows Heng Lu's running-code argument: the document coordinates behavior, but the deployed system creates operational reality through implementation, validation and observed use.

The limit is the point

RFC 9609 does not prove that a named resolver follows the practice, that a root operator returned a particular record set, or that an attack occurred. It does not set a business availability target or guarantee a user's application outcome. It specifies a disciplined way to cross a bootstrap boundary.

That modest scope is why the standard is valuable. The resolver begins with a claim embedded in configuration. It obtains an authoritative DNS answer. It authenticates what can be authenticated. It notices what the response is not required to reveal. It asks narrower follow-up questions. It replaces inherited memory with current cache state and then tests that state by using it.

The reality-layers note warns against allowing a record to impersonate the world it describes. Priming offers a constructive version of the same lesson. Configuration is not the root. An NS RRset is not reachability. AA is not completeness. TC=0 is not a signed declaration that nothing is missing. A standards document is not a deployment.

The trustworthy system is the one that preserves those boundaries and still closes the chain.