| Internet-Draft | LocalRoot | January 2026 |
| Kumari, et al. | Expires 21 July 2026 | [Page] |
DNS recursive resolver operators need to provide the best service possible for their users, which includes providing an operationally robust and privacy protecting service. Challenges to these deployment goals include difficulty of getting responses from the root servers (such as during a network attack), longer-than-desired round-trip times to the closest DNS root server, and privacy issues relating to queries sent to the DNS root servers. Resolvers can solve all of these issues by simply serving an already cached a copy of the full root zone.¶
This document shows how resolvers can fetch, cache and maintain a copy of the root zone, how to detect if the contents becomes stale, and procedures for handling error conditions.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://wkumari.github.io/draft-wkumari-dnsop-localroot-bcp/draft-wkumari-dnsop-localroot-bcp.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wkumari-dnsop-localroot-bcp/.¶
Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (mailto:dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/.¶
Source for this draft and an issue tracker can be found at https://github.com/https://github.com/wkumari/draft-wkumari-dnsop-localroot-bcp.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 July 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
DNS recursive resolvers have to provide responses to all queries from their clients, even those for domain names that do not exist. For each queried name that is within a top-level domain (TLD) that is not in the recursive resolver's cache, the resolver must send a query to a DNS root server to get the information for that TLD or to find out that the TLD does not exist. Many of the queries to root servers get answers that are referrals to other servers. But, research shows that the vast majority of queries going to the root are for names that do not exist in the DNS root zone [DNEROOTNAMES]. Regardless of whether the queries get positive or negative answers, there are privacy implications related to the eavesdropping of these queries as they are being transmitted to the DNS root servers.¶
Caching the IANA root zone data locally, commonly referred to as running a "LocalRoot" instance, provides a method for the operator of a recursive resolver to use a complete copy of the IANA root zone locally instead of sending requests to the Root Server System (RSS). This goal can be implemented using a number of different techniques, including as described in this document. However, the net effect will be the same: few, if any, queries should be sent to the actual RSS.¶
Implementation techniques are documented herein for achieving LocalRoot functionality (see Section 3). At a high level, this involves a LocalRoot implementation pre-fetching the root zone at regular intervals and populating its resolver's cache with information, or by running an authoritative server in parallel that acts as a local, authoritative root server for its associated resolver. Other mechanisms for implementing LocalRoot functionality MAY be used. To a client, the net effect of using any technique SHOULD be nearly indistinguishable to that of a non-Localroot resolver.¶
This behavior SHOULD be used by all general-purpose recursive resolvers used on the public Internet.¶
Note that enabling LocalRoot functionality in a resolver should have little effect on improving resolver speed to its stub resolver clients for queries under Top Level Domains (TLDs), as the TTL for most TLDs is long-lived (two days in the current root zone). Thus, most TLD nameserver and address records are typically already in a resolver's cache. Negative answers from the root servers are also cached in a similar fashion, though potentially for a shorter time based on the SOA negative cache timing (one day in the current root zone).¶
Also note that a different approach to partially mitigating some of the privacy problems that a LocalRoot enabled resolver solves can be achieved using the "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] functionality.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Readers are expected to be familiar with the terminology defined in [RFC8499]. In addition, the following terminology will be used in this document:¶
IANA root zone: the Internet's globally unique DNS root zone as published by IANA [RFC2826]. This is the same source of root zone data used by the Root Server Operators [RSSAC055]. [RFC8499] describes the same root zone as "The zone of a DNS-based tree whose apex is the zero- length label. Also sometimes called ''the DNS root'."¶
IANA root zone data: the complete set of records that makes up the IANA root zone.¶
A LocalRoot enabled resolver: a recursive resolver that makes use of a local copy of the root zone data while performing its DNS resolution process.¶
A LocalRoot implementation: the software or system of software responsible for implementing the functionality described in this specification. A LocalRoot implementation may be implemented as a singular component within a recursive resolver or within multiple components operating in coordination. Implementations may also vary significantly in how these tasks are performed, ranging from static configuration to more active systems. We refer to this entire system, regardless of implementation sytle, as a "LocalRoot implementation".¶
To implement the goals described in Section 1.1 and meet the requirements described in Section 4, a LocalRoot enabled resolver will need to perform three fundamental tasks:¶
Identify locations from where root zone data can be obtained (Section 3.1).¶
Downloading and refreshing the root zone data from one of the publication points (Section 3.2).¶
Integrating and serving the data while performing DNS resolutions (Section 3.3).¶
Implementing these tasks entirely alleviates the need for sending any (other) DNS requests to the RSS.¶
Each of these tasks are described in greater detail in the subsections below.¶
For a LocalRoot enabled resolver to serve up to date data, an implementation must be able to fetch the contents of the entire IANA root zone on a regular basis from at least one publication source. Implementations can find sources of root zone data in a number of ways, including but not limited to:¶
An operationally configured list of sources (for example a file of URLs) that can be used to fetch a copy of the IANA root zone.¶
A list of sources distributed with the resolver software itself, (akin to how the root hints file is distributed with many resolvers today).¶
Downloading a list of available sources from IANA. The mechanism and list format for doing so is described in [draft-hardaker-dnsop-iana-root-zone-publication-points], which asks IANA to aggregate, publish and maintain a list of IANA DNS root zone sources at TBD-URL Guidance to IANA (or for other entities wishing to collect and redistribute a list of sources) for how to collect and maintain a list of IANA root data publication sources is also discussed separately in [draft-hardaker-dnsop-root-zone-publication-list-guidelines].¶
Once a list of available publication points of IANA root zone data have been configured or obtained, a LocalRoot implementation MAY be use the following steps to obtain and maintain an up to date copy of the IANA root zone data. Note that as long as the desired effect of performing normal DNS resolution remains stable when combined with LocalRoot functionality, other implementation strategies MAY be used.¶
If a local copy of the IANA root zone data is unavailable for use in DNS resolution at any point in these steps, resolvers SHOULD fall back to performing DNS resolution by issuing queries directly to the RSS instead. If a resolver is unable to do so, it MUST respond to client requests with a SERVFAIL response code.¶
A LocalRoot implementation SHOULD use a list of root zone sources identified in Section 3.1 for obtaining a copy of the IANA root zone.¶
A LocalRoot implementation SHOULD select one of the available sources from step 1, and from it retrieve a current copy of the IANA root zone. Resolvers SHOULD prioritize sources that can be fetched the most efficiently. For example, when supported, https sources should be preferred as it allows for compression negotiation as well as the use of low-cost, well-distributed Content Delivery Networks (CDNs).¶
When sending requests to a source of IANA root zone data, the resolver SHOULD minimize its impact on the source by querying at a rate no faster than specified by the SOA refresh timer and SHOULD use data freshness protocol checks instead of downloading the entire contents at each refresh (example checks include the HEAD method [RFC9110] when using HTTP(s) or by querying the root zone's SOA over DNS first when using AXFR, IXFR or XoT). Once fetched, an implementation MUST NOT make use of the obtained IANA root zone data with a SOA serial number older than any previously obtained copy [RFC1982].¶
If the LocalRoot implementation failed to retrieve the IANA root zone data in step 2, or the SOA serial number was deemed to be older than the already cached data, then it SHOULD attempt to retrieve the IANA root zone data from another source. If the LocalRoot implementation resolver has exhausted the list of sources, it SHOULD stop attempting to download the IANA root zone data and SHOULD wait another refresh time length until retrying sources again.¶
Having successfully downloaded a copy of the IANA root zone, the LocalRoot implementation MUST verify the contents of the IANA root zone data using the ZONEMD [RFC8976] record contained within it. Note that this REQUIRES verification of the ZONEMD record using DNSSEC [BCP237] with the configured IANA root zone trust anchor. The contents of the fetched zone MUST NOT be used until after ZONEMD verification, including its DNSSEC verification, is complete and successful. Once the IANA root zone data has been verified, the LocalRoot implementation can begin LocalRoot enabled DNS resolution, potentially using the steps defined in Section 3.3.¶
The resolver MUST check at least one the sources in step 1 at a regular interval to identify when a new copy of the IANA root zone data is available. This frequency MAY be configurable and SHOULD default to the IANA root zone's current SOA refresh value. When a resolver has detected that a new copy of the IANA root zone data is available, the resolver SHOULD start at step 2 to obtain a new copy of the IANA root zone data. Resolvers MAY check multiple sources to ensure one source has not fallen significantly behind in its copy of the IANA root zone.¶
Any mechanism a LocalRoot implementation uses to integrate the IANA root zone data obtained in Section 3.2 to perform DNS resolution tasks is sufficient if it is virtually indistinguishable to the DNS resolver's clients. Two example implementation strategies are included below.¶
Once the IANA root zone data has been collected and verified as complete and correct (Section 3.2), a resolver MAY simply update its cache with the newly obtained records.¶
The following requirements are to be followed when creating and/or deploying a LocalRoot implementation:¶
A LocalRoot implementation MUST have a configured DNSSEC trust anchor such as an up-to-date copy of the public part of the Key Signing Key (KSK) [RFC4033] or used to sign the DNS root or its DS record.¶
A LocalRoot implementation MUST retrieve or be provisioned with a copy of the entire current root zone (including all DNSSEC-related records) (see Section 3.2).¶
A LocalRoot implementation MUST validate the contents of the root zone using ZONEMD [RFC8976], and MUST check the validity of the ZONEMD record using DNSSEC.¶
A LocalRoot implementation MUST use and serve records from the root zone without modification.¶
A LocalRoot enabled resolver SHALL return identical answers about the DNS root, or any other part of the DNS, as if it would if it were not operating as a LocalRoot enabled resolver.¶
A LocalRoot implementation SHOULD be able to fall back to querying the authoritative RSS servers whenever the local copy of the root zone data is unavailable or has been deemed stale (see Section 3.2).¶
A LocalRoot implementation MUST have an upper time limit beyond which if a new copy of the IANA root zone data is not available it will revert to sending regular DNS queries to the RSS for performing DNS resolutions on behalf of its clients. This upper limit value MAY be configurable and SHOULD default to the root zone's current SOA expiry value. Once the LocalRoot implementation's copy of the IANA root zone has been successfully refreshed and is no longer considered expired, the resolver may resume LocalRoot enabled resolution operations.¶
There are areas of potential concern that are mitigated to some extent by using this mechanism.¶
Secure DNS verification of an obtained copy of the IANA root zone is possible because of the use of the RSS's ZONEMD [RFC8976] record. This allows for the entire zone to be fetched and subsequently verified before being used within recursive resolvers resolvers. DNSSEC provides the same assurance for individual signed resource records sourced from the root zone, including of the ZONEMD record itself.¶
One privacy concern with the use of DNS is the leakage of potentially sensitive information that may be contained in the query name used in DNS queries. Most root servers (except b.root-servers.net) do not currently support queries over encrypted transports, resulting in query names that are visible to on-the-wire eavesdroppers, and may also be held in any operational logs maintained by root server operators. Such concerns may be mitigated by Query Name Minimization [RFC9156], but common implementations of this mechanism appear to only minimize query names of four or fewer labels, and the uptake rate of query name minimization appears to be quite low [QNAMEMIN]. Furthermore, even with Query Name Minimization, queries for non-existent names (generated from keyword searches and mis-configurations) can cause additional privacy leaks. [RFC8806] eliminates the need for the resolver to perform specific queries to any root nameserver, and obviates any such consideration of query name leakage [LOCALROOTPRIVACY].¶
Another issue solved with LocalRoot is that when information is always available locally, usage of it is no longer subject to DDoS attacks against dependent networks and remote servers. By having the answers effectively permanently in cache, no queries to the upstream service provider (such as root servers) are needed since LocalRoot enabled resolvers effectively always have a cached set of data that is considered fresh longer than the typical TTL records within the zone [CACHEME] [LOCALROOTPRIVACY].¶
This document contains no requests to IANA, although its companion documents do.¶
The authors have discussed this idea with many people, and have likely forgotten to acknowledge and credit many of them. If we discussed this with you, and you are not listed, please please let us know and we'll add you.¶
This work has been founded upon previous documents. Most importantly, [RFC8806], authored by Warren Kumari and Paul Hoffman, and "On Eliminating Root Nameservers from the DNS" [NOROOTS] by Mark Allman.¶
The authors would like to thank Joe Abley, Vint Cerf, John Crain, Marco Davids, Peter Koch, Matt Larson, Florian Obser, Swapneel Patnekar, Puneet Sood, Robert Story, Ondrej Sury, Suzanne Woolf, and many many others for their comments, suggestions and input to both past and current versions of this document.¶
In addition, one of the authors would like to once again thank the bands "Infected Mushroom", "Kraftwerk", and "deadmau5" for providing the soundtrack to which this was written. Another author recently discovered the band "Trampled by Turtles" while working on this document and is submitting it as a nomination for the best-band-name-ever award.¶
Note: DNSOP needs to discuss whether to publish this as a BCP or as a proposed standard. Currently this is listed as STD track based on a number of preliminary conversations the authors had with both operators and IETF participants.¶
[RFC8806] is an Informational document that describes a mechanism that resolver operators can use to improve the performance, reliability, and privacy of their resolvers. This document concludes the concept of [RFC8806] was a success, but that actual implementation of it has varied according to the needs of various code bases and operational environments. Thus, this document houses many of the original concepts of [RFC8806] but is largely a complete rewrite to match modern expectations based on recent implementation and deployment experiences.¶
This document differs in a number of critical ways (TBD: this list is incomplete):¶
promotes the behavior in [RFC8806] to be either a Proposed standard or a Best Current Practice, depending on what the WG decides.¶
RECOMMENDS that resolver implementations provide a simple configuration option to enable or disable functionality, and¶
RECOMMENDS that resolver implementations enable this behavior by default, and¶
REQUIRES that [RFC8976] be used to validate the IANA root zone information before loading it.¶
Adds a mechanism for priming the list of places for fetching root zone data.¶
Adds protocol steps for ensuring resolution stability and resiliency.¶
[RFC8806] Section 2 (Requirements) states that:¶
The system MUST be able to run an authoritative service for the root zone on the same host. The authoritative root service MUST only respond to queries from the same host. One way to assure not responding to queries from other hosts is to run an authoritative server for the root that responds only on one of the loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 in IPv6). Another method is to have the resolver software also act as an authoritative server for the root zone, but only for answering queries from itself.¶
This document relaxes this requirement. Resolver implementations can achieve the desired behavior of directly serving the contents of the root zone via multiple implementation choices, beyond those listed in [RFC8806]. This can include the implementation guidance described in RFC8806, but this document allows for implementations to select any mechanism for fetching and re-distributing the contents of the root zone on their resolver service addresses as long as the other requirements specified in this document are still followed (see Section 4).¶
For example, an implementation can simply "prefill" the resolver's cache with the current contents of the root zone. As the resulting behavior is (essentially) indistinguishable from the mechanism defined in RFC8806, this is viewed as being an acceptable implementation decision.¶