Compact Denial of Existence in DNSSEC Salesforce
415 Mission Street, 3rd Floor San Francisco CA 94105 United States of America shuque@gmail.com
Cloudflare
101 Townsend St. San Francisco CA 94107 United States of America elmerot@cloudflare.com
ogud@ogud.com
OPS dnsop DNS DNSSEC Denial of Existence Compact Denial of Existence Compact Answers Black Lies NXDOMAIN NODATA Empty Non-Terminal This document describes a technique to generate a signed DNS response on demand for a nonexistent name by claiming that the name exists but doesn't have any data for the queried record type. Such responses require only one minimally covering NSEC or NSEC3 record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. This document updates RFCs 4034 and 4035.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
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 () 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
  • .  Introduction and Motivation
    • .  Requirements Language
  • .  Distinguishing Nonexistent Names
  • .  Generating Responses with NSEC
    • .  Responses for Nonexistent Names
    • .  Responses for Nonexistent Types
    • .  Responses for Wildcard Matches
    • .  Responses for Unsigned Referrals
    • .  Responses to Explicit Queries for NXNAME
  • .  Generating Responses with NSEC3
  • .  Response Code Restoration
    • .  Signaled Response Code Restoration
  • .  Operational Implications
  • .  Updates to RFCs
    • .  Updates to RFC 4034
    • .  Updates to RFC 4035
  • .  Security Considerations
  • .  IANA Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • .  Other Approaches
  • .  Historical Implementation Notes
  • Acknowledgements
  • Authors' Addresses
Introduction and Motivation One of the functions of DNS Security Extensions (DNSSEC) is "authenticated denial of existence", i.e., proving that a DNS name or record type does not exist. Normally, this is done by means of signed NSEC or NSEC3 records. In the precomputed signature model, these records chain together existing names, or cryptographic hashes of them, in the zone. In the online signing model, described for NSEC in and for NSEC3 in , they are used to dynamically compute an epsilon function around the QNAME. The Type Bit Maps field in the data of the NSEC or NSEC3 record asserts which resource record (RR) types are present at the name. The response for a nonexistent name requires up to two signed NSEC records or up to three signed NSEC3 records (and for online signers, the associated cryptographic computation) to prove that (1) the name did not explicitly exist in the zone and (2) it could not have been synthesized by a wildcard. This document describes an alternative technique, "Compact Denial of Existence" or "Compact Answers", to generate a signed DNS response on demand for a nonexistent name by claiming that the name exists but has no resource record sets associated with the queried type, i.e., it returns a NODATA response rather than an NXDOMAIN response. A NODATA response, which has a response code (RCODE) of NOERROR and an empty ANSWER section, requires only one NSEC or NSEC3 record matching the QNAME. This has two advantages: The DNS response size is smaller, and it reduces the online cryptographic work involved in generating the response. The use of minimally covering NSEC or NSEC3 records also prevents adversaries from enumerating the entire contents of DNS zones by walking the NSEC chain or performing an offline dictionary attack on the hashes in the NSEC3 chain. This document assumes a reasonable level of familiarity with DNS operations and protocol terms. Much of the terminology is explained in further detail in "DNS Terminology" .
Requirements Language 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.
Distinguishing Nonexistent Names This method generates NODATA responses for nonexistent names that don't match a DNS wildcard. Since there are clearly no record types for such names, the NSEC Type Bit Maps field in the response will only contain the NSEC and RRSIG types (and in the case of NSEC3, the Type Bit Maps field will be empty). Tools that need to accurately identify nonexistent names in responses cannot rely on this specific type bitmap because Empty Non-Terminal (ENT) names (which positively exist) also have no record types at the name and will return exactly the same Type Bit Maps field. This specification defines the use of NXNAME (128), a synthetic RR type to signal the presence of a nonexistent name. See . The mnemonic for this RR type is NXNAME, chosen to clearly distinguish it from the response code mnemonic NXDOMAIN. This RR type is added to the NSEC Type Bit Maps field for responses to nonexistent names, in addition to the mandated RRSIG and NSEC types. If NSEC3 is being used, this RR type is the sole entry in the Type Bit Maps field. It is a "Meta-TYPE", as defined in , and it stores no data in a DNS zone and cannot be usefully queried. describes what a DNS resolver or authoritative server should do if it receives an explicit query for NXNAME. No special handling of this RR type is required on the part of DNS resolvers. However, resolvers may optionally implement the behavior described in ("Signaled Response Code Restoration") to better restore NXDOMAIN visibility to various applications that may remain oblivious to the new NXNAME signal.
Generating Responses with NSEC This section describes various types of answers generated by authoritative servers implementing Compact Denial of Existence using NSEC. describes changes needed to support NSEC3.
Responses for Nonexistent Names When the authoritative server receives a query for a nonexistent name in a zone that it serves, a NODATA response (response code NOERROR, empty Answer section) is generated with a dynamically constructed NSEC record with the owner name matching the QNAME placed in the Authority section. The Next Domain Name field SHOULD be set to the immediate lexicographic successor of the QNAME. This is accomplished by adding a leading label with a single null (zero-value) octet. The Type Bit Maps field MUST only have the bits set for the following RR Types: RRSIG, NSEC, and NXNAME. For example, a request for the nonexistent name "a.example.com." would result in the generation of the following NSEC record (in DNS presentation format): a.example.com. 300 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME The NSEC record MUST have corresponding RRSIGs generated.
Responses for Nonexistent Types When the authoritative server receives a query for a name that exists but has no resource record sets associated with the queried type, it generates a NODATA response with a dynamically constructed signed NSEC record in the Authority section. The owner name of the NSEC record matches the QNAME. The Next Domain Name field is set to the immediate lexicographic successor of the QNAME. The Type Bit Maps field lists the available RR types at the name. An ENT is a special subset of this category, where the name has no resource record sets of any type (but has descendant names that do). For a query for an ENT, the NSEC Type Bit Maps field will only contain RRSIG and NSEC. (Note that this is substantially different than the ENT response in precomputed NSEC, where the NSEC record has the same type bitmap but "covers" rather than matches the ENT and has the Next Domain Name field set to the next lexicographic descendant of the ENT in the zone.)
Responses for Wildcard Matches For wildcard matches, the authoritative server will provide a dynamically signed response that claims that the QNAME exists explicitly. Specifically, the answer RRset will have an RRSIG record demonstrating an exact match (i.e., the label count in the RRSIG RDATA will be equal to the number of labels in the query name minus the root label). This obviates the need to include an NSEC record in the Authority section of the response that shows that no closer match than the wildcard was possible. For a wildcard NODATA match (where the QNAME matches a wildcard but no data for the queried type exists), a response akin to a non-wildcard NODATA is returned. The Answer section is empty, and the Authority section contains a single NSEC record that matches the query name with a Type Bit Maps field representing the list of types available at the wildcard.
Responses for Unsigned Referrals Per the DNSSEC protocol, a referral to an unsigned subzone includes an NSEC record whose owner name matches the subzone and proves the delegation is unsigned by the absence of the Delegation Signer (DS) RR type bit in the Type Bit Maps field. With Compact Denial of Existence, the Next Domain Name field for this NSEC record is computed with a slightly different epsilon function than the immediate lexicographic successor of the owner name, as that name would then fall under the delegated subzone. Instead, the Next Domain Name field is formed by appending a zero octet to the first label of the owner name. For example, a referral response for the subzone sub.example.com would include an NSEC record like the following: sub.example.com. 300 IN NSEC sub\000.example.com. NS RRSIG NSEC
Responses to Explicit Queries for NXNAME NXNAME is a Meta-TYPE that SHOULD NOT appear anywhere in a DNS message apart from the NSEC type bitmap of a Compact Answer response for a nonexistent name. However, if a DNS server implementing this specification receives an explicit query for the NXNAME RR type, this section describes what the response ought to be. If an explicit query for the NXNAME RR type is received, the DNS server MUST return a Format Error (response code FORMERR). A resolver MUST NOT forward these queries upstream or attempt iterative resolution. Many DNS server implementations already return errors for all types in the range for Meta-TYPEs and QTYPEs, except those types that are already defined to support queries. Optionally, a DNS server MAY also include the following Extended DNS Error (EDE) code in the response: 30 (Invalid Query Type). See . Note that this EDE code is generally applicable to any RR type that ought not appear in DNS queries.
Generating Responses with NSEC3 NSEC3 uses hashed names to provide zone enumeration defense. This protection is better provided by minimally covering NSEC records. NSEC3's Opt-Out feature also provides no specific benefit for online signing implementations (minimally covering NSEC3 records provide no useful Opt-Out span). Hence, there is no known advantage to implementing Compact Denial of Existence with NSEC3. However, an existing implementation of conventional NSEC3 online signing migrating to Compact Denial of Existence may find it simpler to do so with NSEC3 rather than implementing NSEC from scratch. For NSEC3, the functional details of the protocol remain as described in , with the following changes. NSEC3 records and their signatures are dynamically generated instead of NSEC. The NSEC3 parameters SHOULD be set to algorithm 1, a flags field of 0, an additional hash iteration count of 0, and an empty salt. In DNS presentation format, this is "1 0 0 -". The owner name of the NSEC3 resource record is the NSEC3 hash of the relevant domain name, encoded in Base32 with Extended Hex Alphabet (), prepended as a single label to the name of the zone. The Next Hashed Owner Name is the immediate name successor of the unencoded binary form of the previous hash, which can be computed by adding one to the binary hash value. In responses for nonexistent names, the Type Bit Maps field will contain only the NXNAME Meta-TYPE. In responses to ENT names, the Type Bit Maps field will be empty. For example, a request for the nonexistent name "a.example.com." would result in the generation of the following NSEC3 record: H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - ( H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME ) Unlike Compact Denial of Existence with NSEC, no special form of the Next Hashed Owner Name field for unsigned referrals is needed. The Next Hashed Owner Name field remains the NSEC3 hash of original owner name plus one.
Response Code Restoration For nonexistent names, implementations should try to preserve the response code value of 3 (NXDOMAIN) whenever possible. This is generally possible for non-DNSSEC-enabled queries, namely those that do not set the DO bit ("DNSSEC answer OK") in the EDNS0 OPT header. For such queries, authoritative servers implementing Compact Denial of Existence could return a normal NXDOMAIN response. However, there may be limited benefit to doing this since most modern DNS resolvers are DNSSEC aware, and per , DNSSEC-aware recursive servers are required to set the DO bit on outbound queries, regardless of the status of the DO bit on incoming requests. A validating resolver that understands the NXNAME signal from an authoritative server could modify the response code from NOERROR to NXDOMAIN in responses they return to downstream queriers that have not set the DO bit in their requests.
Signaled Response Code Restoration This section describes an optional but recommended scheme to permit signaled restoration of the NXDOMAIN RCODE for DNSSEC-enabled responses. A new EDNS0 header flag is defined in the second most significant bit of the flags field in the EDNS0 OPT header. This flag is referred to as the Compact Answers OK (CO) flag. +0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |DO|CO| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ When this flag is sent in a query by a resolver, it indicates that the resolver will accept a NODATA response with a signed NXNAME for a nonexistent name, together with the response code field set to NXDOMAIN (3). In responses to such queries, an authoritative server implementing both Compact Denial of Existence and this signaling scheme will set the Compact Answers OK EDNS header flag and, for nonexistent names, will additionally set the response code field to NXDOMAIN. EDNS is a hop-by-hop signal, so resolvers will need to record the presence of this flag in associated cache data and respond to downstream DNSSEC-enabled queriers appropriately. If the querier does not set the Compact Answers OK flag, the resolver will need to reset the response code back to NOERROR (0) for an NXNAME response.
Operational Implications For DNSSEC-enabled queries, a signed zone at an authoritative server implementing Compact Answers will never return a response with a response code of NXDOMAIN, unless they have implemented the optional response code restoration feature described in . Similarly, resolvers not implementing this feature will also not be able to return NXDOMAIN. In the absence of this, tools that rely on accurately determining nonexistent names will need to infer them from the presence of the NXNAME RR type in the Type Bit Maps field of the NSEC record in NODATA responses from these servers. Address lookup functions typically invoked by applications may need to do more work when dealing with implementations of Compact Answers. For example, a NODATA response to the lookup of a AAAA record for a nonexistent name can cause such functions to issue another query at the same name for an A record, whereas an NXDOMAIN response to the first query could suppress additional queries for other types at that name. Address lookup functions could be enhanced to issue DNSSEC-enabled queries and to examine the NSEC Type Bit Maps field in responses to accurately determine nonexistent names. Note that this is less of a concern with connection functions like Happy Eyeballs that typically issue back-to-back DNS queries without waiting for individual responses. Protocol optimizations that enable DNS resolvers to synthesize NXDOMAIN or wildcard responses, like those described in and , cannot be realized from responses that use Compact Denial of Existence. In general, no online signing scheme that employs minimally covering NSEC or NSEC3 records (including this one) permits NXDOMAIN or wildcard response synthesis in the style described in . Additionally, this protocol also precludes NXDOMAIN synthesis for DNSSEC-enabled responses in the style described in .
Updates to RFCs
Updates to RFC 4034 ("The Type Bit Maps Field") states the following:
Bits representing pseudo-types MUST be clear, as they do not appear in zone data. If encountered, they MUST be ignored upon being read.
This paragraph is updated to the following:
Bits representing pseudo-types MUST be clear, as they do not appear in zone data. If encountered, they MUST be ignored upon being read. There is one exception to this rule for Compact Denial of Existence (RFC 9824), where the NXNAME pseudo-type is allowed to appear in responses to nonexistent names.
Note: As a practical matter, no known resolver insists that pseudo-types not be set in the NSEC Type Bit Maps field, so this restriction (prior to its revision) has posed no problem for the deployment of this mechanism.
Updates to RFC 4035 ("Including NSEC RRs in a Zone") states the following:
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce the risk of response inconsistency in security oblivious recursive name servers.
This paragraph is updated to the following:
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce the risk of response inconsistency in security oblivious recursive name servers. This concern only applies to implementations of DNSSEC that employ precomputed signatures. There is an exception to this rule for online signing implementations of DNSSEC (e.g., minimally covering NSEC and Compact Denial of Existence), where dynamically generated NSEC records can be produced for owner names that don't exist or are ENTs.
Security Considerations Online signing of DNS records requires authoritative servers for the DNS zone to have access to the private signing keys. Exposing signing keys on Internet-reachable servers makes them more vulnerable to attack. Additionally, generating signatures on demand is more computationally intensive than returning precomputed signatures. Although the Compact Answers scheme reduces the number of online signing operations compared to previous techniques like White Lies, it still may make authoritative servers more vulnerable to computational denial-of-service attacks than precomputed signatures. The use of signature algorithms (like those based on elliptic curves) that have a comparatively low cost for signing is recommended. Some security tools rely on detection of nonexistent domain names by examining the response code field of DNS response messages. A NOERROR (rather than NXDOMAIN) code in that field will impact such tools. Implementation of the optional response code restoration scheme will help recover NXDOMAIN visibility for these tools. Note that the DNS header is not cryptographically protected, so the response code field cannot be authenticated. Thus, inferring the status of a response from signed data in the body of the DNS message is actually more secure. These tools could be enhanced to recognize the (signed) NXNAME signal. Because this method does not allow for aggressive negative caching among resolvers, it allows for certain types of denial-of-service attacks to be more effective. This includes so-called Pseudorandom Subdomain Attacks , where random names are queried, either directly via botnets or across a wide range of public resolver services, in order to intentionally generate nonexistent responses from the authoritative servers for a domain. If the resolver cannot synthesize NXDOMAIN responses from NSEC records, it must pass all queries on to the domain's authority servers, making resource exhaustion more likely at those latter servers if they do not have the capacity to absorb those additional queries. If the motivating aspects of this specification (minimizing response size and computational costs) are not a concern, DNSSEC deployments can opt for a different method (e.g., conventional online signing or precomputed signatures) and avoid imposing the challenges of NXDOMAIN visibility.
IANA Considerations IANA has allocated the following in the "Resource Record (RR) TYPEs" registry in the "Domain Name System (DNS) Parameters" registry group, from the range for Meta-TYPEs. A lower number in this range lowers the size of the Type Bit Maps field, which reduces the overall size of the DNS response message.
Type Value Meaning Reference
NXNAME 128 NXDOMAIN indicator for Compact Denial of Existence RFC 9824
IANA has also allocated the following flag in the "EDNS Header Flags (16 bits)" registry in the "Domain Name System (DNS) Parameters" registry group. This flag is described in .
Bit Flag Description Reference
Bit 1 CO Compact Answers OK RFC 9824
Last, IANA has allocated the following code point in the "Extended DNS Error Codes" registry in the "Domain Name System (DNS) Parameters" registry group. This code point is described in .
INFO-CODE Purpose Reference
30 Invalid Query Type RFC 9824
References Normative References Key words for use in RFCs to Indicate Requirement Levels 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. Indicating Resolver Support of DNSSEC In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK] Resource Records for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Protocol Modifications for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Minimally Covering NSEC Records and DNSSEC On-line Signing This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK] The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] DNS Security (DNSSEC) Hashed Authenticated Denial of Existence The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] Extension Mechanisms for DNS (EDNS(0)) The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. Domain Name System (DNS) IANA Considerations This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Extended DNS Errors This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. DNS Security Extensions (DNSSEC) 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. Informative References Compact DNSSEC Denial of Existence or Black Lies CloudFlare Inc. CloudFlare Inc. Work in Progress Empty Non-Terminal Sentinel for Black Lies Salesforce The Black Lies method of providing compact DNSSEC denial of existence proofs has some operational implications. Depending on the specific implementation, it may provide no way to reliably distinguish Empty Non-Terminal names from names that actually do not exist. This draft describes the use of a synthetic DNS resource record type to act as an explicit signal for Empty Non-Terminal names and which is conveyed in an NSEC type bitmap. Work in Progress Signaling NSEC record owner name nonexistence CloudFlare Inc. CloudFlare Inc. Work in Progress Water Torture: A Slow Drip DNS DDoS Attack on QTNet Authenticated Denial of Existence in the DNS Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three. This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses. NXDOMAIN: There Really Is Nothing Underneath This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. Aggressive Use of DNSSEC-Validated Cache 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. Happy Eyeballs Version 2: Better Connectivity Using Concurrency Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. DNS Terminology 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 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 updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.
Other Approaches In the past, some implementations of Compact Denial of Existence have used other means to differentiate NXDOMAIN from ENTs. One method employed by both Cloudflare and Amazon Route53 for a period of time was the following: For responses to ENTs, they synthesized the NSEC Type Bit Maps field to include all record types supported except for the queried type. This method has the undesirable effect of no longer being able to reliably determine the existence of ENTs and of making the Type Bit Maps field larger than it needs to be. It also has the potential to confuse validators and others tools that infer type existence from the NSEC record. Another way to distinguish NXDOMAIN from ENT is to define the synthetic RR type for ENTs instead, as specified in . This method was successfully deployed in the field by NS1 for a period of time. This typically imposes less work on the server since NXDOMAIN responses are a lot more common than ENTs. At the time it was deployed, it also allowed a common bitmap pattern ("NSEC RRSIG") to identify NXDOMAIN across this and other implementations that returned a broad bitmap pattern for ENTs. However, the advantage of the NXNAME RR type is that it explicitly identifies NXDOMAIN responses and allows them to be distinguished conclusively from potential ENT responses in other online signing NSEC implementations.
Historical Implementation Notes At the time of publication, the basic Compact Denial of Existence method using NSEC is implemented by Cloudflare, NS1, Amazon Route53, and Knot DNS's optional online signing module. From early 2021 until November 2023, NS1 had deployed the ENT distinguisher using the private RR type code 65281. A version of the NXNAME distinguisher using the private RR type code 65238 was deployed by both Cloudflare (from July 2023) and NS1 (from November 2023) until roughly September 2024. Since September 2024, both Cloudflare and NS1 have deployed NXNAME using the officially allocated code point of 128. Oracle Cloud Initiative implemented Compact Denial of Existence using NSEC3 in October 2024.
Acknowledgements The Compact Answers technique was originally proposed in by and and implemented by Cloudflare. The ENT distinguisher RR type was originally proposed in by and deployed by NS1. The NXNAME type is based on the FDOM type proposed in by Gudmundsson and Valsorda. Especially detailed discussions on many technical aspects of this document were conducted with , , , , and . The authors would also like to thank the many other members of the IETF DNS Operations Working Group for helpful comments and discussions.
Authors' Addresses Salesforce
415 Mission Street, 3rd Floor San Francisco CA 94105 United States of America shuque@gmail.com
Cloudflare
101 Townsend St. San Francisco CA 94107 United States of America elmerot@cloudflare.com
ogud@ogud.com