Internet-Draft Running a Root Server Local to a Resolve December 2025
Kumari, et al. Expires 6 June 2026 [Page]
Workgroup:
Domain Name System Operations
Internet-Draft:
draft-wkumari-dnsop-localroot-bcp-latest
Updates:
RFC8806 (if approved)
Published:
Intended Status:
Best Current Practice
Expires:
Authors:
W. Kumari
Google, Inc.
W. Hardaker
USC/ISI and Google, Inc.
J. Reid
RTFM llp
G. Huston
APNIC

Running a Root Server Local to a Resolver

Abstract

Many DNS recursive resolver operators wish to prevent snooping by third parties of requests sent to DNS root servers. In addition, some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Resolvers can solve both of these issues by serving or pre-caching a copy of the full root zone on the same server or within the resolver software.

This document shows how to fetch, cache and maintain such a copy of the root zone, how to detect if it becomes stale, and mechanisms for handling error states. This specification is designed to increase the resiliency, privacy and efficiency of DNS resolver services.

This document obsoletes [RFC8806].

/* Ed (WK): Open questions / ToDo / Notes (to be removed before publication):

  1. I started writing this as rfc8806-bis, but as I did so I realized that it is likely better as a standalone document.

  2. This document recommends ("Operation Considerations") using HTTP(S) for fetching the zone. We still need to add text to cover priming and discuss the bootstrapping issue. In addition, we need to add text about loadbalancing and fetching from multiple sources. Much of the premise behind RFC8806 is that it doesn't matter where you fetch the zone from, as long as you validate it, and use zone checksums [RFC8976]. */

About This Document

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.

Status of This Memo

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 6 June 2026.

▲

Table of Contents

1. Introduction

DNS recursive resolvers have to provide answers 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 root server to get the information for that TLD or to find out that the TLD does not exist. Research shows that the vast majority of queries going to the root are for names that do not exist in the root zone.

Many of the queries from recursive resolvers to root servers get answers that are referrals to other servers. Malicious third parties might be able to observe that traffic on the network between the recursive resolver and root servers.

Caching the root zone data locally, commonly referred to as running a "LocalRoot" instance, provides a method for the operator of a recursive resolver to have a complete copy of the IANA root zone locally rather than sending requests for it to the Root Server System (RSS). This can be implemented using a number of different implementation techniques, but the net effect is the same: few, if any, queries are sent to the actual RSS.

Note that enabling LocalRoot functionality in a resolver will probably have little effect on improving resolver speed to a stub resolver for good queries under Top Level Domains (TLDs), as the TTL for most TLDs is already long-lived (two days in the current root zone). Thus the data is 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.

Two potential implementation mechanisms are documented herein for achieving LocalRoot functionality: having the resolver pre-fetch the root zone at regular intervals and pre-populate its cache with information, or by running an authoritative server in parallel with the recursive resolver that acts as a locally authoritative root server. To a client, the net effect of using any technique should be nearly indistinguishable to that of a non-Localroot resolver.

A different approach to partially mitigating some of the problems that a LocalRoot enabled resolver solves can be achieved using "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] functionality.

Readers are expected to be familiar with [RFC8499].

2. Conventions and Definitions

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.

3. Making RFC8806 behavior be a Best Current Practice

Note: DNSOP needs to discuss whether to publish this as a BCP or as a bis-document and making LocalRoot a proposed standard (RFC8806 is informational)

[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 experiment [RFC8806] was a success. The reality is that secure DNS resolution using a local copy of the IANA root zone is possible because technologies like DNSSEC and ZONEMD [RFC8976] allow for the contents to be fetched from any location and subsequently verified and used within validating resolvers.

This document:

  1. promotes the behavior in [RFC8806] to be a Best Current Practice.

  2. RECOMMENDS that resolver implementations provide a simple configuration option to enable or disable functionality, and

  3. RECOMMENDS that resolver implementations enable this behavior by default. and

  4. REQUIRES that [RFC8976] be used to validate the IANA root zone information before loading it.

  5. Adds a mechanism for priming the list of places for fetching root zone data.

  6. Adds protocol steps for ensuring resolution stability and resiliency.

3.1. Changes from RFC8806

[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 what is 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. For example, this can be done by simply "prefilling" the resolver's cache with the 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. In the end, the fundamental requirement is simply: resolvers MUST return the records from the root zone without modification.

3.2. Applicability

This behavior should apply to all general-purpose recursive resolvers used on the public Internet.

4. LocalRoot enabled resolver requirements

In order to implement the mechanism described in this document:

A corollary of the above list is that a resolver operating as a LocalRoot MUST return equivalent answers about the DNS root or any other part of the DNS as if it was not operating as a LocalRoot.

5. Functionality of a LocalRoot enabled resolver

The functionality of LocalRoot enabled resolver includes:

  1. Identifying locations from where root zone data can be obtained Section 5.1.

  2. Downloading and refreshing the root zone data from one of the publication points Section 5.2.

  3. Integrating and serving the data while performing DNS resolutions Section 5.3, Paragraph 1

5.1. Identifying locations from where root zone data can be obtained

In order for the LocalRoot functionality to be effective, an implementation must be able to fetch the contents of the entire IANA root zone. Implementations can find sources in a number of ways, including but not limited to:

  1. Using a locally configured list of sources (for example a file or URLs) from which to fetch a copy of the IANA root zone.

  2. Using a list of sources distributed with the resolver software itself.

  3. By downloading a copy of available sources from the IANA using the sources described in Section 5.1.1.

To support LocalRoot implementations, IANA will aggregate, publish and maintain a list of IANA DNS root zone sources at TBD-URL Section 5.1.1. Guidance to IANA or for other entities wishing to collect and redistribute a list of sources for IANA root server data is discussed in [draft-hardaker-dnsop-root-zone-publication-list-guidelines].

5.1.1. IANA maintained list of root zone publication points

This list of IANA root zone data publication points available at TBD-URL may be used when downloading and refreshing the root zone data, as described in Section 5.2. Specifically, this IANA DNS root zone publication list MAY be used by the resolver software directly, or by the operating system a resolver is deployed on, or by a network operator when configuring a resolver.

The contents of the IANA DNS root publication points file MUST verified as to its integrity as having come from IANA and MUST be verified as complete.

5.1.1.1. root zone publication points

NOTE: this is but an example format that is expected to spur discussions within IETF working groups like DNSOP. Whether this is a list in a simple line-delimited format like below or signed JSON or signed PGP or ... is subject to debate.

The format of the IANA root zone data publication points file will consist of two parts, separated by a line containing four dashes and a newline ("----\n"). The top section of the file contain a newline delimited list of URLs [RFC2056]. The second section, following the line containing four dashes, will contain a cryptographic checksum or signature. Note that the format of this file applies to the IANA maintained list of root zone publication points, but may or may not be a format used by other publication point aggregation lists.

URLs in the list may include any protocol capable of transferring DNS zone data, including HTTPS [RFC9110], AXFR [draft-hardaker-dnsop-dns-xfr-scheme], XoT [draft-hardaker-dnsop-dns-xfr-scheme], etc.

Any URLs that reference an unknown transfer protocol SHOULD be discarded. If after filtering the list there are no acceptable list elements left, the resolver MUST revert to using regular DNS queries to the IANA root zone instead of operating as a LocalRoot.

The first line of the cryptograhpic checksum section will contain a checksum or signature type string specifying what the remaining lines in the checksum or signature section will contain.

An minimal example publication point file, containing only a single AXFR publication point of b.root-servers.net:

axfr:b.root-servers.net/.
----
SHA256
67d687eb21e59321dbb8115c51d1b4ddbd6634362859d130ed77b47a4410656c
5.1.1.2. Publication point operational considerations

Implementations SHOULD optimize retrieval to minimize impacts on the server. Because the list is not expected to change frequently, implementations SHOULD refrain from querying the IANA source more than once a week.

5.2. Protocol steps

When initializing an implementation's LocalRoot mechanism, the following steps MAY be used to implement the LocalRoot functionality. Note that as long as the desired effect of performing normal DNS resolution remains stable when combined with LocalRoot functionality, other implementations MAY be used.

If local root zone data is unavailable at any point in these steps, resolvers SHOULD fall back to performing DNS resolution by issuing queries to the RSS as needed. If a resolver is unable to do so, it MUST respond to client requests with a SERVFAIL response code.

  1. The resolver SHOULD use a list of root zone sources identified in Section 5.1 for obtaining a copy of the IANA root zone.

  2. The resolver MUST 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 they can fetch the most efficiently. For example, when supported, https sources should be preferred as it allows for compression negotiation as well as the possibility of using low-cost, well-distributed CDNs to distribute the zone files. When querying a source of IANA root zone data, the resolver SHOULD minimize impact to the source by querying at a rate no faster than specified by the SOA refresh timer and SHOULD use data freshness protocol checks over 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 an obtained IANA root zone with a SOA serial number less than any previously obtained copy [RFC1982].

  3. If the resolver failed to retrieve the IANA root zone content in step 2, or the zone content's serial number was deemed to be older than an already cached copy then it SHOULD attempt to retrieve the IANA root zone from another source on that list if there are other available sources from available sources from step 1. If the resolver has exhausted the list of sources, it SHOULD stop attempting to download the IANA root zone and wait another refresh time length until retrying all of the sources again.

  4. Having successfully downloaded a copy of the IANA root zone, the resolver MUST verify the contents of the IANA root zone using the ZONEMD [RFC8976] record contained within it. Note that this REQUIRES verification of the ZONEMD record using DNSSEC [BCP237] and the configured IANA root zone trust anchor. The contents of the fetched zone MUST NOT be used until after ZONEMD verification is complete and successful. Once the zone data has been verified as the IANA root zone, the resolver can begin LocalRoot enabled DNS resolution, potentially using the steps defined in Section 5.3, Paragraph 1.

  5. The resolver MUST check the sources in step 1 at a regular interval to identify when a new copy of the IANA root zone is available. This internal 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 is available, the resolver SHOULD start at step 1 to obtain a new zone. Resolvers MAY check multiple sources to ensure one source has not fallen significantly behind in its copy of the IANA root zone.

Resolvers MUST have an upper limit beyond which if a new copy is not available it will revert to using regular DNS queries to the IANA root zone instead of continuing to use the previously downloaded copy. If at any point this upper limit has been reached, the resolver SHOULD fall back to using regular DNS mechanisms 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.

5.3. Integrating root zone data into the resolution process

Any mechanism that a recursive resolver can use to serve the data obtained in Section 5.2 in such a way that it is functionally indishinguishable to a client from having followed regular DNS resolution processes should be considered an acceptable implementation. Two example implementation descriptions are included in the following two subsections.

5.3.1. Pre-caching the root zone data

Once the root zone data has been collected and verified as complete and correct (Section 5.2), a resolver MAY simply update its cache with the newly obtained values. This functionally entirely alleviates the need for sending any (other) DNS requests to the RSS.

5.3.2. Running a local authoratative copy of the root zone in parallel

[RFC8806] described an implementation mechanism where a copy of the root zone could be run in an authoratative server running in parallel to the recursive resolver. The recursive resolver could then be configured to simply point at this parallel server for obtaining data related to the root zone instead of the RSS itself. Note that [RFC8806] required that the parallel server be running on a loopback address and this specification removes that requirement and allows the parallel service to run on any address it can legitimately be used on. Note that the server MUST NOT use an address of one of the official root server addresses in the root zone.

6. Operational Considerations

/* TOP POSTING ED (WH): I believe we can delete the following discussion, but didn't want to do so without chatting with WK first. */

/* ED (WH): I don't think we can get away without describing how/where to pull this information from at some point. The ICANN https servers are one source, or should resolver code bases use their own defined CDNs?

(WK): 100% agree. I personally think that this should be hosted on multiple CDNs, and that expecting a single server or service to always be available would be a massive mistake. But, I also don't think that resolvers should pull from their own CDNs - I don't want Acme Anvil and Resolvers (or their CDN!) go out of business, and have Acme Resolvers fail. This is (I believe) a sufficiently small amount of data that hosting it on multiple CDNs should be trivial.... but, I also believe that this topic should be discussed with the WG. */

/* Ed (WK): We might want to add some more discussions around failure handling, but, 1: [RFC8806] already covers much of this and 2: "don't teach your grandmother to suck eggs" - implementations already handle this, so let's not try to overspecify or over-constrain what they do. */

7. Security Considerations

There are areas of potential concern that are mitigated to some extent by using this mechanism.

7.1. Leakage of potentially sensitive information

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].

7.2. Local resiliency of the DNS

Another issue solved with LocalRoot is that when information is always available locally, usage of it is no longer subject to DDoS attacks against the remote servers. By having the answers effectively permanently in cache, no queries to the upstream service provider (such as root servers) are needed since [RFC8806] resolvers effectively always have a cached set of data that is considered fresh longer than the typical TTL records within the zone [CACHEME] [LOCALROOTPRIVACY].

8. IANA Considerations

TBD: describe the request for IANA to support a list of root server publication points at TBD-URL.

9. References

9.1. Normative References

[BCP237]
Best Current Practice 237, <https://www.rfc-editor.org/info/bcp237>.
At the time of writing, this BCP comprises the following:
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, , <https://www.rfc-editor.org/info/rfc9364>.
[RFC1982]
Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, , <https://www.rfc-editor.org/rfc/rfc1982>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4033]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, , <https://www.rfc-editor.org/rfc/rfc4033>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8198]
Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, , <https://www.rfc-editor.org/rfc/rfc8198>.
[RFC8499]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, , <https://www.rfc-editor.org/rfc/rfc8499>.
[RFC8806]
Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, , <https://www.rfc-editor.org/rfc/rfc8806>.
[RFC8976]
Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Hardaker, "Message Digest for DNS Zones", RFC 8976, DOI 10.17487/RFC8976, , <https://www.rfc-editor.org/rfc/rfc8976>.

9.2. Informative References

[BIND-MIRROR]
"BIND 9 Mirror Zones", n.d., <https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-type%20mirror>.
[CACHEME]
"Cache Me If You Can: Effects of DNS Time-to-Live", n.d., <https://ant.isi.edu/~johnh/PAPERS/Moura19b.pdf>.
[draft-hardaker-dnsop-dns-xfr-scheme]
"The DNS XFR URI Schemes", n.d., <https://datatracker.ietf.org/doc/draft-hardaker-dnsop-dns-xfr-scheme/>.
[draft-hardaker-dnsop-root-zone-publication-list-guidelines]
"Guidelines for IANA DNS Root Zone Publication List Providers", n.d., <https://raw.githubusercontent.com/hardaker/draft-hardaker-dnsop-root-zone-publication-list-guidelines/refs/heads/main/draft-hardaker-dnsop-root-zone-publication-list-guidelines.md>.
[KNOT-PREFILL]
"Knot Resolver Prefill", n.d., <https://knot-resolver.readthedocs.io/en/stable/modules-prefill.html>.
[LOCALROOTPRIVACY]
"Analyzing and mitigating privacy with the DNS root service", n.d., <http://ant.isi.edu/~hardaker/papers/2018-02-ndss-analyzing-root-privacy.pdf>.
[NOROOTS]
"On Eliminating Root Nameservers from the DNS", n.d., <https://www.icir.org/mallman/pubs/All19b/All19b.pdf>.
[QNAMEMIN]
"DNS Query Privacy", n.d., <https://www.potaroo.net/ispcol/2019-08/qmin.html>.
[RFC2056]
Denenberg, R., Kunze, J., and D. Lynch, "Uniform Resource Locators for Z39.50", RFC 2056, DOI 10.17487/RFC2056, , <https://www.rfc-editor.org/rfc/rfc2056>.
[RFC5936]
Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, , <https://www.rfc-editor.org/rfc/rfc5936>.
[RFC7706]
Kumari, W. and P. Hoffman, "Decreasing Access Time to Root Servers by Running One on Loopback", RFC 7706, DOI 10.17487/RFC7706, , <https://www.rfc-editor.org/rfc/rfc7706>.
[RFC7766]
Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, , <https://www.rfc-editor.org/rfc/rfc7766>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9156]
Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, , <https://www.rfc-editor.org/rfc/rfc9156>.
[UNBOUND-AUTH-ZONE]
"Unbound Auth Zone", n.d., <https://nlnetlabs.nl/documentation/unbound>.

Acknowledgments

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. These include [RFC7706] and [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.

Authors' Addresses

Warren Kumari
Google, Inc.
Wes Hardaker
USC/ISI and Google, Inc.
Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
United Kingdom
Geoff Huston
APNIC
6 Cordelia St
South Brisbane QLD 4101
Australia