]> Google, Inc.

warren@kumari.net

USC/ISI and Google, Inc.

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

Operations and Management Domain Name System Operations DNS DNSSEC zone cut delegation referral 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. { Editor note: This document contains a FAQ section. It will help answer questions about why this document is not a BCP but still has BCP in the name, how and why this document differs from RFC8806, etc etc etc. The FAQ section is intended to be removed before publication. } 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 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 . 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.

Local Caching of Root Server Data 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 ). 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. 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" functionality. This document obsoletes .

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.

Terminology used in this document Readers are expected to be familiar with the terminology defined in . 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 . This is the same source of root zone data used by the Root Server Operators . describes the same root zone as "The zone of a DNS-based tree whose apex is the zero-length label. Sometimes also 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 IANA 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 style, as a "LocalRoot implementation".

Components of a LocalRoot enabled resolver To implement the goals described in and meet the requirements described in , a LocalRoot enabled resolver will need to perform three fundamental tasks:

1. Identify locations from where IANA root zone data can be obtained ().
2. Download and refresh the IANA root zone data from one of the publication points ().
3. Integrating and serving the IANA root zone data while performing DNS resolutions ().

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.

Identifying locations from where IANA root zone data can be obtained 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 IANA root zone data in a number of ways, including, but not limited to:

1. 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.
2. A list of sources distributed with the resolver software itself, (akin to how the root hints file is distributed with many resolvers today).
3. Downloading a list of available sources from IANA. The mechanism and list format for doing so is described in , 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 zone data publication sources is also discussed separately in .

Downloading and refreshing IANA root zone data Once a list of available publication points of IANA root zone data is configured or obtained, a LocalRoot implementation MAY 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.

1. A LocalRoot implementation SHOULD use a list of root zone sources identified in for obtaining a copy of the IANA root zone.
2. 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 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 .
3. If the LocalRoot implementation fails to retrieve the IANA root zone data in step 2, or the SOA serial number is 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 has exhausted the list of sources, it SHOULD stop attempting to download the IANA root zone data and SHOULD wait one refresh interval before retrying sources.
4. After successfully downloading a copy of the IANA root zone, the LocalRoot implementation MUST verify the contents of the IANA root zone data using the ZONEMD record contained within it. Note that this REQUIRES verification of the ZONEMD record using DNSSEC 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 is verified, the LocalRoot implementation can begin LocalRoot enabled DNS resolution, potentially using the steps defined in .
5. The resolver MUST check at least one of 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 detects 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.

Integrating and serving the IANA root zone data during resolution Any mechanism a LocalRoot implementation uses to integrate the IANA root zone data obtained in to perform DNS resolution tasks is sufficient if it is virtually indistinguishable to the DNS resolver's clients. Three example implementation strategies are included below.

Pre-caching the IANA root zone data Once the IANA root zone data has been collected and verified as complete and correct (), a resolver MAY simply update its cache with the newly obtained records. Note that it is RECOMMENDED that such implementations also perform aggressive DNSSEC caching , otherwise significant traffic will still be sent to the Root Server System.

Running a local authoritative copy of the IANA root zone in parallel described an implementation mechanism where a copy of the IANA root zone could be run in an authoritative 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 IANA root zone instead of the RSS itself. Note that required that the parallel server be running on a loopback address, but this specification removes that requirement. Instead, implementations MAY run the parallel service on any service address it can legitimately use. However, such a server MUST NOT use an address of one of the official root server addresses in the root zone.

Zone loaded and served by Recursive Resolvers Recursive resolvers may load authoritative zones to be used when constructing query responses to clients, for example to serve the zones. This approach is taken by the BIND 9 Mirror Zones feature, and the zone is updated using normal secondary zone update processing.

LocalRoot enabled resolver requirements 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) or used to sign the IANA root or its DS record.
• A LocalRoot implementation MUST retrieve or be provisioned with a copy of the entire current IANA root zone (including all DNSSEC-related records) (see ).
• A LocalRoot implementation MUST validate the contents of the IANA root zone using ZONEMD , and MUST check the validity of the ZONEMD record using DNSSEC.
• A LocalRoot implementation MUST use and serve records from the IANA root zone without modification.
• A LocalRoot enabled resolver SHALL return identical answers about the IANA 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 IANA root zone data is unavailable or has been deemed stale (see ).
• 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. It MUST NOT be longer than the IANA 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.
• A LocalRoot implementation MUST revert to using regular DNS for querying the root servers when the downloaded zone contains RRTYPEs or cryptographic algorithm types it does not understand.
• A LocalRoot implementation SHOULD use the EDNS EXPIRE Option .

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

IANA root zone data security Secure DNS verification of an obtained copy of the IANA root zone is possible because of the use of the RSS's ZONEMD 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 IANA root zone, including of the ZONEMD record itself.

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

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

IANA Considerations This document contains no requests to IANA, although its companion documents do.

References Normative References 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. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. 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. 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 Internet Architecture Board This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. 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. This work has been founded upon previous documents. Most importantly, , authored by Warren Kumari and Paul Hoffman, and "On Eliminating Root Nameservers from the DNS" 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.

History of the LocalRoot concept 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. 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 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 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):

1. promotes the behavior in to be either a Proposed standard or a Best Current Practice, depending on what the WG decides.
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 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.

An important change 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. Resolver implementations can achieve the desired behavior of directly serving the contents of the root zone via multiple implementation choices, beyond those listed in . 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 ). 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.

Frequently Asked Questions (FAQ) NOTE: This section to be removed before publication. It is here to help answer questions that have been raised during the development of this document, and to help clarify the intent of the document. It is intentionally written in a more informal style than the rest of the document... well, this isn't strictly true - it's not intentionally less formal, it's just that I really didn't want to bother making it more formal :-)

Why is this a BCP and not a Proposed Standard?! It's not. We initially thought it should be a BCP, but discussions with the WG quickly convinced us that resolver operators should be able to make the decision themselves. The draft name (draft-wkumari-dnsop-localroot-bcp) does currently contain "bcp", but when this is adopted we plan on changing the name to "draft-ietf-dnsop-localroot" (or similar). We don't want to change it now, as that would just confuse things further (like the DT "Search Email Archives" functionality, etc.)

Does this document require new functionality in resolvers? No. Almost all resolvers already implement the concepts described in this draft. For example, BIND 9 has a "mirror" zone type , Unbound has an "auth-zone" type , and Knot Resolver has a "prefill" module . Our goal with this document was to better describe the differences in existing implementations by defining the expected behavior of a LocalRoot implementation, rather than by being explicit in how software must be implemented. This document also contains additional functionality that resolver implementations may choose to implement (draft-hardaker-dnsop-iana-root-zone-publication-points), but this is simply optional enhancements, and not a requirement.

So, isn't this just RFC 8806?! No. Many resolvers already implement the behavior described in , but are not strictly compliant with . Hence, the reason for restating the goals into expected behavior rather than specifying a required, exact implementation. Specifically, states that the resolver must run an authoritative service for the root zone on the same host, and that the authoritative root service must only respond to queries from the same host. Most resolvers do not implement the LocalRoot features this way, and instead implement a "prefill" of the resolver's cache, or act more like a secondary. This document describes the behavior that implementations should strive to meet, not the implementation details themselves.

Loss of measurement data / the ability of researchers to measure the root server system This is a concern that has been raised by some researchers - if resolvers implement LocalRoot functionality, they won't show up in the DITL data, as they are not querying the root servers. Yes, this is completely true - whenever you increase the privacy of a system, you reduce the amount of information that leaks from that system. The authors note that this issue already affects the DITL data, as many resolvers already implement LocalRoot functionality (or similar) and many operators have deployed those features, and thus do not query the root servers. In addition, the DITL data is already missing a sizable amount of the queries - see Kazunori Fujiwara's presentation from DNS-OARC 46 (Edinburgh): . Furthermore, the DITL data, while useful and fascinating, only provides a very narrow view of the DNS: it only shows queries that are sent to the root servers, and does not show queries that are sent to other servers (such as TLDs, or authoritative servers for other zones), doesn't account for caching, etc.