Summary

  • RFC 8806 lets a recursive resolver use a complete root-zone copy served on the same host. The service answers only that host's resolvers and keeps data identical to the public root, including DNSSEC records.
  • The copy follows the root SOA timers and must never be served stale. Before expiry, the resolver switches to non-local roots. This is a bounded execution path, not transferred root authority.

Imagine a resolver answering its first root question after a network path fails. No packet leaves the chassis. The answer comes from a complete root zone held by a small authoritative service beside the recursive process.

That scene sounds like independence. RFC 8806 makes it almost the opposite. The service is allowed to reduce a resolver's external dependency only while it remains dependent on the public root for the identity, validity and lifetime of every answer it gives.

The boundary is unusually physical. The local service may answer the recursive resolver on its own machine. It must not answer a resolver in the next rack, another virtual machine on a different host or a client elsewhere on the operator's network.

Its root data cannot be edited into a local policy view. Its signed answers are not trusted merely because they crossed no wire. If its copy approaches expiry, the resolver must leave it.

Paul E. Hoffman is the second-listed of two authors of RFC 8806, with Warren Kumari. The document is an Informational RFC reflecting IETF consensus, not a personal command or proof that Hoffman operates any deployment. His documentary role matters because this design turns “local root” from an expansive political phrase into a narrow operating contract.

A root service that cannot serve the network

RFC 8806 describes an authoritative server holding the complete root zone on the same host as a recursive resolver. The recursive resolver directs its root queries to that local service. Remote root-server paths remain available, but they need not carry every root query during ordinary operation.

The local service is not offered as infrastructure to other machines. It must answer only resolver software on its own host and must not answer any other resolver. RFC 7706, the earlier document that RFC 8806 replaced, fixed the service to loopback addresses. The newer RFC allows more implementation flexibility while preserving the single-host access rule.

That rule is not an incidental firewall suggestion. It defines the failure domain. A bad copy, broken authoritative process or mistaken configuration can damage the recursive service on that machine. It should not become a conveniently reachable source of bad root data for an entire campus or region.

It also removes the strongest rhetorical overreach. A locally served copy is not a new member of the public root-server system. It is not a national or regional root. It does not create a separate namespace. The machine receives no power to decide which top-level domains exist. It gains a shorter execution path to data whose authority remains elsewhere.

This is the minimum-specification shape at its best. An operator may adopt the method voluntarily. The common rule says what must remain interoperable and what the local service must never become. Deployment detail stays local, but the authority boundary does not.

The answer is local; the reference is not

RFC 8806 requires the locally served data to be identical to the public DNS root. An operator should not alter glue records. The copy must contain the entire zone, including DNSSEC records, rather than a convenient subset of popular delegations.

Completeness matters because a recursive resolver does not know in advance which top-level domain the next client will ask about. A selective copy can turn an ordinary miss into a false statement about the namespace. A modified copy can make local policy indistinguishable from root fact.

DNSSEC supplies a second boundary. The recursive resolver must validate signed answers from the local service in the same way it validates answers received from remote roots. Physical proximity is not provenance. The validating resolver needs the current public root key-signing-key trust anchor.

Hoffman is also one of four authors of RFC 7958, which documents publication of root trust anchors by IANA. That document explains why a configured trust anchor sits outside the DNSSEC signature chain as the point from which validation begins. It complements automated trust-anchor maintenance; it does not make a downloaded file trustworthy merely because an operator saved it locally.

The result is a useful inversion. A local answer can avoid the network while still proving its relationship to the shared public root. Reducing transport dependency does not require creating a new source of truth. The copy remains useful precisely because it cannot authorize itself.

Freshness ends at an SOA deadline

A root copy is not a snapshot to preserve indefinitely. RFC 8806 tells the operator to refresh it according to the root zone's SOA timers. The complete zone may arrive through AXFR or a published root-zone file, depending on the available service and implementation.

The local copy can trail the globally served root for a short period. Public root operators may receive change notifications that a resolver-local copy does not. That lag is accepted only inside the zone's freshness contract.

Expiry is the hard stop. The local service must not continue serving stale root data. Before the SOA expiry is reached, the recursive resolver must immediately switch to non-local root servers.

That requirement changes the meaning of fallback. Remote roots are not an optional disaster-recovery accessory added after the local architecture is complete. They are part of the local architecture's safety proof. Without a tested route out, the operator has built a cache whose convenience can outlive its evidence.

A failed refresh can hide more than an administrative detail. If a top-level domain is newly delegated or its root records change after the local copy stops moving, clients behind the resolver can receive an obsolete view of an entire branch of DNS. RFC 8806 therefore points operators toward monitoring SOA changes, not merely checking whether the local authoritative process still answers.

Process health is the shallow test. Evidence of freshness joins the copy's serial, acquisition time, validation state, SOA refresh and expiry values, the last successful comparison with the public root, and the resolver's observed fallback behavior. A green socket with a dying zone is not resilience.

Priming is a different receipt

Resolvers already have a way to find current root-server information. RFC 8109, co-authored by Hoffman, describes priming. A resolver sends a query to a remote root server to obtain the current root NS RRset and related addresses, allowing it to update the server information seeded by root hints.

Priming does not install an authoritative copy of the complete root zone. It initializes the resolver's knowledge of where public root service can be reached. A root hints file, a priming response, a complete zone transfer and a local authoritative service are four different artifacts.

The difference is operationally important. A successful priming query says the resolver has refreshed its map of root servers. It does not say a local root copy is complete, current or inside its SOA lifetime. Conversely, a healthy local copy does not excuse a stale trust anchor or an untested remote fallback path.

Collapsing those receipts into “root is configured” makes audits comforting and useless. Each mechanism needs its own evidence and its own failure test.

Privacy and resilience are purchased with local fragility

RFC 8806 identifies privacy and resilience benefits. Root queries and answers can stay off the network, reducing what an observer on the path can see. A resolver can continue answering root questions when remote root servers are unreachable or under attack.

The performance case is less dramatic. Valid top-level-domain data usually has long TTLs and is cached, so ordinary resolvers do not need to ask the root on every client query. A local root copy is not a universal latency accelerator.

The design also introduces fate-sharing. The recursive resolver and its local authoritative dependency occupy the same host. A local resource problem, software fault or configuration error can affect both. The mechanism exchanges some external path risk for a concentrated local operating obligation.

Acquisition services carry another uncertainty. RFC 8806 lists ways to transfer or download the zone but does not promise those services will exist forever. IANA currently publishes the root-zone file, root hints and trust-anchor material. An observation on 30 August 2026 is not a guarantee of tomorrow's acquisition path.

These are reasons to test the method, not reasons to forbid it. Running-Code Primacy asks whether the actual resolver validates, refreshes and exits as designed. A citation to a MUST is not a refresh receipt; a local answer is not evidence that the fallback will work after expiry.

Hoffman's attribution stops where operation begins

The current IETF profile for Paul E. Hoffman, reviewed on 30 August 2026, lists 83 RFCs, chair roles in three working groups and membership in the RFC Production Advisory Team. The same public record includes RFC 7706, RFC 7958, RFC 8109 and RFC 8806.

Those facts document an unusually broad standards career. They remain time-stamped: group roles and RFC counts can change. More importantly, co-authorship does not prove that Hoffman invented the local-root method alone, recommends it for every resolver or controls how an operator implements it.

The attribution boundary mirrors the technical one. A name on a consensus document proves participation in specifying a mechanism. It does not turn the author into the authority behind every running copy. A zone on a local host proves possession of data. It does not turn the host into the authority behind the root.

RFC 8806 is strongest where its local service is weakest. The copy cannot answer its neighbor, rewrite its source, trust itself or outlive its deadline. Those constraints let an operator reduce dependency without pretending that locality is sovereignty.

Sources