]> Google, Inc.

warren@kumari.net

USC/ISI

ietf@hardakers.net

RTFM llp

St Andrews House 382 Hillington Road, Glasgow Scotland G51 4BL UK jim@rfc1035.com

APNIC

6 Cordelia St South Brisbane QLD 4101 Australia gih@apnic.net

Layer 9 Technologies, LLC.

david.conrad@layer9.tech

Operations and Management Domain Name System Operations DNS DNSSEC zone cut delegation referral RFC 8806 (often called "LocalRoot") defines a mechanism whereby a recursive resolver can fetch the contents of an entire zone and place this information into the resolver's cache. This has several benefits, including increased reliability, increased performance, improved privacy, and decreased or mitigation of the effect of some types of DoS attacks. While the majority of DNS resolver implementations natively support RFC 8806, it remains tricky to configure and maintain. This document recommends that DNS resolver software simplify this configuration, and further suggests that configuration becomes the default. This document updates Section 2 of RFC8806 by relaxing the requirement that implementations MUST run an authoritative service. /* 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 . */

About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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 behavior can be achieved by "manually" configuring software that acts as a secondary server for the root-zone (see 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.

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 when, and only when, they appear in all capitals, as shown here.

Making RFC8806 behavior be a Best Current Practice 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 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 be used to validate the zone information before loading it.

Changes from 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.

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

Operational Considerations In order for the 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 (). In order for AXFR to work, the resolver must be able to use TCP (which is already required by ). 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? (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. */ Resolvers MUST validate the contents of the zone before using it, including validating the ZONEMD record, using the mechanism in . /* Ed (WK): We might want to add some more discussions around failure handling, but, 1: 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. */

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 , 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 . Furthermore, even with Query Name Minimization, queries for non-existent names (generated from keyword searches and mis-configurations) can cause additional privacy leaks. eliminates the need for the resolver to perform specific queries to any root nameserver, and obviates any such consideration of query name leakage . 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 resolvers effectively always have a cached set of data that is considered fresh longer than the typical TTL records within the zone .

IANA Considerations This document has no IANA actions.

References Normative References 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. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. This document obsoletes RFC 7706. This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK] This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. n.d. n.d. n.d. n.d. n.d. n.d.

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.

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

ISC BIND 9.14 and above See the BIND documentation for mirror zones. Example configuration using a "mirror" zone:

Knot Resolver See the Knot Resolver Cache prefilling documentation for more information. The following example configuration will prefill the root zone using HTTPS:

Unbound 1.9 and above See the Unbound documentation for Authority Zone Options configuration. The following example configuration will prefill the root zone using HTTPS: