DNS Root Server System Usage Considerations

1.1. Document Conventions

To evaluate the potential changes to RSS communication in Section 3, 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.¶

2.1. QName Minimization

The original DNS protocol specifications [RFC1035] 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" [RFC9156] 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."¶

2.2. Aggressive NSEC

The "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] [RFC9077] 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 (Section 3.1) and latency (Section 3.5) when communicating with the RSS, as fewer queries are sent and more responses can be generated immediately from the cache.¶

2.3. Encrypted 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) [RFC7858] and "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094] (along with supplemental information [RFC8310]) which collectively are referred to as "DNS over (D)TLS".¶

In addition, "DNS Queries over HTTPS (DoH)" [RFC8484], "DNS over Dedicated QUIC Connections" [RFC9250], and "Oblivious DNS over HTTPS" [RFC9230] enable DNS over encrypted HTTP transports.¶

The "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative" DNS [RFC9539] 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.¶

2.4. Serve Stale

The "Serving Stale Data to Improve DNS Resiliency" [RFC8767] 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.¶

2.5. DNSSEC

DNSSEC [RFC9364] 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.¶

2.6. 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 [RFC7706], [RFC8806], and [LOCALROOT], and in academic research [NOROOTS], [ROOTPRIVACY]. It is implemented in [BINDMIRROR], [KNOTMODULE], [UNBOUNDAUTHZONE], [LOCALROOTISI].¶

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

3.1. 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 ([ROOTPRIVACY]). 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 DNS: Moderate¶

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

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

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

3.4. 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 (Section 3.3.2).¶

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

• LocalRoot: Complete¶

  LocalRoot implementations within resolvers download and verify the entire contents of the root zone using DNSSEC and ZONEMD, including associated glue records, and thus eliminates this threat entirely for incoming queries.¶

3.5. 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 [RFC8806] 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.¶