Making LocalRoot a Best Current Practice

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 2 March 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

[RFC8806] provides "a method for the operator of a recursive resolver to have a complete root zone locally, and to hide queries for the root zone from outsiders. The basic idea is to create an up-to-date root zone service on the same host as the recursive server, and use that service when the recursive resolver looks up root information."¶

While [RFC8806] behavior can be achieved by "manually" configuring software that acts as a secondary server for the root-zone (see [RFC8806] Section B.1. Example Configuration: BIND 9.12 and Section B.2 Example Configuration: Unbound 1.8), most resolver implementations now support simpler, and more robust, configuration mechanisms to enable this support. For example, ISC BIND 9.14 and above supports "mirror" zones, Unbound 1.9 supports "auth-zone", and Knot Resolver uses its "prefill" module to load the root zone information. See Appendix A for configuration details. In addition to providing simpler configuration of the LocalRoot mechanism, these mechanisms support "falling back" to querying the root-servers directly if they are unable to fetch the entire root zone.¶

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

[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:¶

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. RECOMMENDS that [RFC8976] be used to validate the zone information before loading it.¶

4. 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. Some resolver implementations achieve the behavior described in RFC8806 by fetching the zone information and "prefilling" their cache with this information. As the resulting behavior is (essentially) indistinguishable from the mechanism defined in RFC8806, this is viewed as being an acceptable implementation decision.¶

5. Applicability

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

6. Operational Considerations

In order for the [RFC8806] mechanism to be effective, a resolver must be able to fetch the contents of the entire root zone. This is currently usually performed through AXFR ([RFC5936]). In order for AXFR to work, the resolver must be able to use TCP (which is already required by [RFC7766]).¶

Resolvers MAY allow fetching this information via HTTPS. Where possible, HTTPS should be preferred as it will allow for compression as well as the possibility of using low-cost, well-distributed CDNs to distribute the zone files.¶

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

Resolvers MUST validate the contents of the zone before using it. This SHOULD be done using the mechanism in [RFC8976], but MAY be done by validating every signed record in a zone with DNSSEC [RFC9364].¶

/* 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 overconstrain what they do. */¶

/* Ed (GH): As the NS records are unsigned the possibility of tampering with the root zone exists through these unsigned NS records. For this reason ZONEMD should be strongly recommended, or even MUST be used.*/¶

/* Ed (WH): I agree with GH, and said as much in [LOCALROOTPRIVACY] */¶

7. Security Considerations

There are three areas of potential concern that can be mitigated to some extent by using this mechanism, coupled with the use of [RFC8976].¶

The first is the potential to insert corrupted referral address records in response to queries to a root server. The referral addresses provided in a referral response is not a DNSSEC-signed record in the root zone, and thus there is the potential for an on-the-wire insertion attack by replacing this part of a referral response with a different address set. If ZONEMD is used to authenticate the the local copy of the root zone, such on-the-wire attacks are not feasible.¶

The second is the issue of leak 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].¶

/* Ed (WK): Fill this in. I think that it just contains descriptions of the benefits from RFC8806, but I'm guessing that there are some other concerns too... */¶

Security requirements associated with the need to verify that the contents of the retrieved root zone are correct were discussed above, and mitigated by the usage of [RFC8976].¶

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 Vint Cerf, John Crain, Puneet Sood, Robert Story, Suzanne Woolf.¶

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

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 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"
  prefetch: yes

Authors' Addresses