Running a Root Server Local to a Resolver

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 30 May 2026.¶

Copyright Notice

Copyright (c) 2025 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.¶

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

4. LocalRoot enabled resolver requirements

In order to implement the mechanism described in this document:¶

• The resolver system MUST be able to validate the contents of the root zone using ZONEMD [RFC8976], which also requires supporting DNSSEC for verifying the root zone's ZONEMD record.¶

• The resolver system MUST have a configured DNSSEC trust anchor 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.¶

• The resolver system MUST be able to retrieve a copy of the entire root zone (including all DNSSEC-related records) Section 5.2.¶

• The resolver system MUST 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 Section 5.2.¶

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 6¶

6. Operational Considerations

/* 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.¶

The issue of 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].¶

The final 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

This document has no IANA actions.¶

9. References

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

The authors would like to thank Joe Abley, Vint Cerf, John Crain, Marco Davids, Paul Hoffman, 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.¶

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" and has submitted it as a nomination for the best-band-name-ever award.¶

Appendix A: Example Configurations

These examples are provided to show how the LocalRoot mechanism can be configured in various resolver implementations. They are not intended to be exhaustive, and may not work with all versions of the software.¶

/* Ed (WK): These examples are just to get started. We would appreciate contributions from the resolver operators.¶

Yes, we are fully aware of the circular dependency of trying to resolve e.g www.internic.net when bootstrapping. More discussion on serving the IANA root zone over HTTP by IP will be added later. */¶

zone "." {
    type mirror;
};

modules.load('prefill')
prefill.config({
      ['.'] = {
              url = 'https://www.internic.net/domain/root.zone',
              interval = 86400  -- seconds
              ca_file = '/etc/pki/tls/certs/ca-bundle.crt', -- optional
      }
})

auth-zone:
    name: "."
    url: "https://www.internic.net/domain/root.zone"
    zonefile: "root.zone"
    fallback-enabled: yes
    for-downstream: no
    for-upstream: yes
    zonefile: "root.zone"

Authors' Addresses