]> Google, Inc.

ietf@hardakers.net

Google

warren@kumari.net

Operations and Management Domain Name System Operations DNS DNSSEC root zone This document explores various technologies developed to enhance the DNS, focusing specifically on interactions with the DNS Root Server System (RSS). It examines a number of the protocols and evaluates their impact on communication with the RSS. About This Document 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 This document explores various technologies developed to enhance the DNS, focusing specifically on interactions with the DNS Root Server System (RSS). It examines a number of the protocols and evaluates their impact on communication with the RSS. While the necessity of a centralized source for a unique internet naming system is beyond the scope of this document, it is thoroughly addressed in . The document begins by briefly describing and referencing various communication enhancements in . It then provides an analysis of how these enhancements impact communication with the RSS in .

Document Conventions To evaluate the potential changes to RSS communication in , this document categorizes the solutions using the following keywords:

• Minimal: The technique addresses a problem with only a minimal amount of improvement.
• Moderate: The technique provides a moderate level of improvement in addressing a problem.
• Significant: The technique offers substantial improvement for communicating with the RSS, even though it does not entirely address the problem space.
• Complete: The technique fully enhances communication with the RSS and/or completely mitigates the defined concern.

Techniques Improving Communication with the RSS This section outlines various techniques designed to improve communication with the DNS Root Server System (RSS), particularly in addressing security or efficiency concerns. These techniques are further analyzed in to evaluate their effectiveness in mitigating each of the concerns.

QName Minimization The original DNS protocol specifications indicated that the entire query name being handled by a resolver should be sent to upstream authoritative servers; this behavior leaks all the labels in a query to all the authoritative servers used in the resolution process, even when the authoritative server doesn't use all the labels when generating a response. The "DNS Query Name Minimisation to Improve Privacy" specification describes how recursive resolvers can minimize this privacy leakage by describing how the resolver "no longer always sends the full original QNAME and original QTYPE to the upstream name server."

Aggressive NSEC The "Aggressive Use of DNSSEC-Validated Cache" specification describes how validating recursive resolvers can reduce the number of queries sent to authoritative servers by allowing "DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards." (Ed note: The NSEC example used in this paragraph is an accurate example as of this writing, but may change over time.) Aggressive NSEC leverages NSEC records to prevent redundant queries for non-existent TLDs. Validating resolvers can use NSEC records to synthesize negative responses for non-existent TLDs based on previously received NSEC records. For example, a query for a non-existent TLD (e.g., ".example") will return an NSEC record cryptographically proving that the no names between ".events" and ".exchange" exist. Subsequent queries within the NSEC TTL for a non-existent TLD that falls between ".events" and ".exchange" (e.g., ".evil") can be answered immediately without sending a query to the RSS. This technique is particularly effective in reducing queries to the RSS for non-existent TLDs, as once a single query between two valid TLDs has been sent, validating resolvers can make use of the returned NSEC records to prevent future queries between the two bounding TLDs from needing resolution. This improves both privacy () and latency () when communicating with the RSS, as fewer queries are sent and more responses can be generated immediately from the cache.

Encrypted and Authenticated DNS There are a variety of protocols that enable encrypted DNS transactions both between stubs and recursive resolvers, and between recursive resolvers and authoritative servers. These include "DNS over Transport Layer Security" (TLS) and "DNS over Datagram Transport Layer Security (DTLS)" (along with supplemental information ) which collectively are referred to as "DNS over (D)TLS". In addition, "DNS Queries over HTTPS (DoH)" , "DNS over Dedicated QUIC Connections" , and "Oblivious DNS over HTTPS" enable DNS over encrypted HTTP transports. The "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative" DNS specification defines how recursive resolvers can communicate with authoritative servers that support encrypted TLS sessions. However, the specification is currently published under an EXPERIMENTAL status. In all cases for the purpose of this document, we define these these connections to be verified both in terms of authenticity of the server end point (although not necessarily of the data's origin itself). As such this survey frequently rates authenticated and encrypted TLS solutions as strong candidates for solving communication problems, large scale deployments of resolver to authoritative DNS servers in particular lack a robust way for performing proper TLS server certificate authentication, which makes actual deployment a challenge.

Serve Stale The "Serving Stale Data to Improve DNS Resiliency" specification specifies how resolvers can continue to serve previously cached records even after their Time-To-Live (TTL) has expired. This approach enhances DNS resiliency by ensuring that responses remain available during periods when authoritative servers are unreachable, such as during network outages or server failures.

DNSSEC DNSSEC provides cryptographic assurance of the authenticity and integrity of DNS responses. Using digital signatures, DNSSEC ensures that data from the root and other signed zones cannot be maliciously modified without detection. This allows validating resolvers, and their clients, to verify the origin, authenticity, and correctness of DNS data.

LocalRoot LocalRoot enables recursive resolvers to maintain and use a local copy of the root zone, eliminating the need to query the root servers directly. This concept has been documented for over a decade in , , and , and in academic research , . It is implemented in , , , . The initial LocalRoot implementations relied on AXFR for transferring root zone data. More recent implementations instead support HTTP-based transfers, providing additional flexibility and scalability.

RSS Communication Improvement Effectiveness Comparison This section evaluates the impact of the techniques described in on recursive resolvers' communication with the Root Server System (RSS).

Privacy Queries sent to the RSS include those within existing Top-Level Domains (TLDs) (e.g., ".com", ".org") and for queries under non-existent domains (e.g., "sensitive.internal", sensitive.con" (sic)). When a resolver's cache lacks an answer for a domain within an associated TLD, the query is forwarded to the RSS. This exposes the query to the 12 Root Server Operators (RSOs) managing the 26 RSS identifiers (13 IPv4 and 13 IPv6) and the networks in between. The privacy sensitivity of queries sent to the RSS can vary widely, ranging from unlikely sensitive (such as a query for just ".example" without any left-hand labels) to more critical queries that leak potentially personal or system-sensitive information that was not intended to leak beyond an internal network boundary (such as ".wpad" records). Names reaching the RSS can be single labels that reveal only the TLD's name (".com" or ".xxx"), which may or may not be sensitive in nature by themselves. Queries can also contain more labels that may leak more sensitive information ("private.sensitive.example"). Accidental leaks can stem from typos, web browser keyword searches, misconfigured software, or simply because it needed to be resolved, and no privacy-protecting techniques are deployed. Note that beyond the analysis of a single record being observed, a larger or temporal analysis of all of a client's queries may reveal additional information and/or behavioral patterns (). For example, the collection of unique ccTLDs observed during the course of a 24 hour period may reveal the political bias in a resolver's clients. To mitigate issues with potentially sensitive queries leaving a resolver, various techniques are available for use that include:

• Aggressive NSEC: Significant Because Aggressive NSEC greatly reduces the quantity of queries requiring NXDOMAIN responses, it can greatly enhance a resolver's privacy by simply sending less queries. The rough worst-case scenario with a long lived cache is a transmission of 1 query per TLD in the root zone in the course of one TTL (2 days, or other implementation upper limit which can commonly be 1 day). Note that resolvers that prefer client NS records, which often have a lower TTL, may send data more frequently than what the root zone's TTL specifies. Note that DNSSEC (or at least an understanding of the NSEC record) is required to implement Aggressive NSEC. Note that Aggressive NSEC does not prevent queries for existing TLDs from leaking.
• QName Minimization: Significant QName Minimisation greatly improves privacy in the case where any sensitive information exists in the labels before the TLD (e.g. sensitive.example). However, this cannot entirely minimize the leakage of TLD names themselves, which may or may not be sensitive in nature (".xxx" is used as a common example of a TLD that may be considered sensitive). Note that like the Aggressive NSEC technique above, the sent queries are typically cached for a period of time. Unlike NSEC Aggressive Caching though, DNSSEC is not required to implement QName Minimization.
• Encrypted and authenticated DNS: Moderate Encrypted and authenticated DNS protocols, such as DNS over (D)TLS, protect queries from intermediate observers by encrypting communication. However, as of this writing, only 2 of the 13 root server identifiers support encrypted DNS, limiting the effectiveness of this technique with respect to the RSS.
• LocalRoot: Complete LocalRoot implementations maintain a local copy of the root zone, thereby completely eliminating the need to send queries to the RSS. This ensures complete privacy with respect the RSS, as no queries leave the resolver toward the RSS. Furthermore, because the data is received and verified before being used, there are only two remaining sources of trust for the information used: IANA itself and the RZM which is responsible for creating the root zone, although even they have no visibility into how resolvers make use of the data.

Disconnected operations At times, a region may become disconnected from the broader internet due to various causes, such as network outages, intentional disruptions, or natural disasters. In such scenarios, the Root Server System (RSS), as the pinnacle of the DNS hierarchy, becomes inaccessible to resolvers needing information about TLDs not in their cache. While a complete disconnection from the internet results in failures for all resolutions to external resources, local infrastructure may still be functioning and remain reachable (e.g., a ccTLD may be accessible even if the RSS is not). Solutions available for resolvers to continue operating even when disconnected from the RSS include:

• Serve Stale: Significant Serve Stale allows resolvers to reuse cached data when authoritative servers are unreachable. This approach can significantly aid disconnected scenarios, provided the required records are already in the cache. However, it cannot assist when the necessary information has not been recently cached.
• LocalRoot: Significant or Complete LocalRoot implementations that populate their cache with root zone records offer significant protection, similar to Serve Stale. But cached records may still expire if not recently accessed. Implementations that ensure the root zone contents are always available (e.g., via RFC8806 parallel infrastructure, special cache retention flags, or when loaded from a persistently refreshed file) provide complete protection against RSS disconnection.

Record Protection DNSSEC RRSIG records ensure the integrity and authenticity of DNS resource records (RRs). However, delegation-related records, such as NS records and associated glue records, are exceptions to this protection. These records, served by the parent zone, assist resolvers in reaching child zones but are not cryptographically signed. Once the resolver verifies that the child zone is serving accurate information and the DS record validates the child's DNSKEY, the child's data becomes authoritative. If the parent-side delegation records are modified, resolvers may initially be directed to incorrect infrastructure. With DNSSEC validation enabled, this would result in a denial of service or, at worst, a temporary eavesdropping issue. We analyze record protection by dividing it into in two parts: authoritative RR protection and non-authoritative delegation record protection (NS and glue).

Authoritative RR Protection All root zone records, except NS and glue records, are protected by DNSSEC, ensuring tamper resistance. Solutions for safeguarding these records include:

• DNSSEC: Significant DNSSEC protects against record modification for records served from the RSS, assuming validation is performed using a root zone DNSSEC trust anchor and the chain of trust from it is followed all the way to the child zone. Note that not all TLDs in the root zone are protected, and thus this is considered Significant since most TLDs do offer DNSSEC support and most resolvers are child-centric. Note that DNSSEC, when combined with NSEC records, allows verification of negative answers received from the root. Thus, responses for non-existent records from the root are verifiable as authentic.
• Encrypted and Authenticated DNS: Complete If the resolver is able to connect to a root server instance that offers authenticated and encrypted DNS support, then any answers they receive over that protected path can be considered properly validated even without checking the corresponding DNSSEC records. However, checking the DNSSEC records for validity themselves may still be recommended. Encrypted and authenticated DNS protection is considered Complete when the authentication of the TLS connection to the RSS can be properly verified.
• LocalRoot: Complete LocalRoot implementations download and verify the entire root zone using DNSSEC and ZONEMD records, ensuring all data is tamper-resistant. Proper DNSSEC validation of at least the ZONEMD record is required.

Non-Authoritative Data (Glue) Protection Although DNSSEC protects many of the records within the root zone, the TLD's NS, A and AAAA records in the root zone are not signed. This lack of signing leaves these records vulnerable to attacks such as man-in-the-middle modifications or cache injection, especially with parent-centric validating resolvers. These attacks could redirect traffic to non-responsive servers, causing denial-of-service issues. Alternatively, the addresses can be modified to point to alternate addresses that do respond. While these responding addresses will be unable to alter DNSSEC signed records in the root zone, they can still act as eavesdroppers and modify any unsigned glue records being passed. Note that NS and glue records from the root zone are typically cached for a lengthy period of time, which is a benefit for resolvers that receive the correct records but a detriment for those that receive modified records and have a parent-side preference. Mitigation strategies include:

• DNSSEC: None to Significant DNSSEC prevents unauthorized modification of authoritative records in DNS zones, ensuring that unsigned data cannot be falsely inserted. However, as discussed above, it does not prevent NS and glue record modification. The protection offered by DNSSEC depends on whether the resolver uses DNSSEC to validate the child side's NS, A and AAAA records. Furthermore, the TLD must be signed for this protection to be effective.
• Encrypted and authenticated DNS: Complete Encrypted and authenticated DNS provides secured communication with root server instances, assuming server endpoints are properly verified. Note, however, since NS glue records in the parent zone lack RRSIGs, proper validation the veracity of the data still requires consultation with the child zone for data authenticity verification.
• LocalRoot: Complete LocalRoot implementations download and verify the entire contents of the root zone, including NS and glue records, effectively eliminating this threat.

Bit Flipping "Bit flipping" is the term used to describe accidental modifications to bits due to memory corruption in a device or during transmission. The net effect is that at least one bit may flip randomly from 0 to 1, or vice versa. Though rare, they have been measured in network traffic arriving at very popular servers of all types. The root-servers.net zone is, unsurprisingly, a very popular domain: it bootstraps all Internet DNS resolutions. Researchers have shown that by registering alternate domain names with single or double bit flips in the root-servers.net domain name allows these alternate servers to receive requests that were intended to be sent to the real root-servers.net domain. These bit flips can cause problems similar to the above discussed glue record modifications (). Note that in this section we only discuss bitflips that are received by or sent by the resolver. Bitflips that occur in packets leaving the resolver toward the client that submitted the original query are out of scope and not covered in this document as the resolver (and the RSS) has no control over them. Solutions to detecting and rejecting bitflipped data include:

• DNSSEC: Significant Cryptographic techniques like DNSSEC properly identify and reject data with modifications of any kind, including bit flipping techniques. However, DNSSEC does not prevent NS and glue record modification since these records, as discussed above, are not protected by DNSSEC unless verified through to the client's copy of the records. Research has shown that some validating resolvers fail to detect when some bit flipping situations have occurred, however.
• Encrypted and authenticated DNS: Significant Encrypted and authenticated DNS provides secured communication with root server instances that ensures no data has been modified in flight. However, any data containing bit-flips in the root server instance itself, in the resolver's memory, or in the outgoing data transmissions cannot be protected.
• LocalRoot: Significant LocalRoot implementations within resolvers download and verify the entire contents of the root zone using DNSSEC and ZONEMD, including associated glue records. This eliminates (or at least catches) all bit flips that occur on incoming data transfers for the root zone. However, it cannot protect against bit flips that occur in-memory or in outgoing responses, and is thus only Significant.

Latency Even though almost all answers to user queries are served from the cache, some resolver operators have concerns about the latency of queries sent to the RSS. In addition, because negative answers are frequent and may be from end-user typos waiting for a response, latency to the RSS may at least matter a little. In fact, this is one motivation listed in for implementing LocalRoot. Techniques that support reducing latency to the root, often by having the answers already available, include:

• Aggressive NSEC: Significant With Aggressive NSEC deployed, queries containing right-most labels (TLD labels) that are not in the root may be answered immediately by generating the answer using an NSEC record in the (validating) resolver's cache. The result is similar to the privacy analysis showing that Aggressive NSEC provides significant latency reduction to the root zone.
• LocalRoot: Complete As above, a LocalRoot implementation already has all the records in the root zone and thus can answer immediately and without ever sending any queries to the RSS.
• Serve Stale: N/A Note that though Serve Stale may have an answer in the cache that is usable, it does not help with latency since the answer should not be used until an attempt to query the RSS has already been made.

Summary In summary, the following table summarizes the analysis in given the DNS communication technologies in and how they affect communication with the RSS.

	QName-Min	Aggr.-NSEC	Encr/Auth	Serve-Stale	DNSSEC	LocalRoot
Privacy	Signif	Signif	Moderate			Complete
Disconnection				Signif		Complete*
Auth Prot			Complete		Signif	Complete
Non-auth Prot			Complete		Signif	Complete
Bit Flipping			Signif		Signif	Signif
Latency		Signif				Complete

(*): as discussed above, this depends on the implementation with some implementations only being Significant while others are Complete.

Operational Considerations TBD

Security Considerations This document discusses a large number of security related cases in and proposes mitigation strategies, their effectiveness, and associated trade-offs.

IANA Considerations None.

Informative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. 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. Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853. 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. This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. 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. Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198. 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. This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. 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. This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses. The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d.

Acknowledgments Thank you to John Heidemann who provided valuable feedback.