rfc9824.original   rfc9824.txt 
Internet Engineering Task Force S. Huque Internet Engineering Task Force (IETF) S. Huque
Internet-Draft Salesforce Request for Comments: 9824 Salesforce
Updates: 4034, 4035 (if approved) C. Elmerot Updates: 4034, 4035 C. Elmerot
Intended status: Standards Track Cloudflare Category: Standards Track Cloudflare
Expires: 31 August 2025 O. Gudmundsson ISSN: 2070-1721 O. Gudmundsson
Retired / Unaffiliated September 2025
27 February 2025
Compact Denial of Existence in DNSSEC Compact Denial of Existence in DNSSEC
draft-ietf-dnsop-compact-denial-of-existence-07
Abstract Abstract
This document describes a technique to generate a signed DNS response This document describes a technique to generate a signed DNS response
on demand for a non-existent name by claiming that the name exists on demand for a nonexistent name by claiming that the name exists but
but doesn't have any data for the queried record type. Such answers doesn't have any data for the queried record type. Such responses
require only one minimally covering NSEC or NSEC3 record, allow require only one minimally covering NSEC or NSEC3 record, allow
online signing servers to minimize signing operations and response online signing servers to minimize signing operations and response
sizes, and prevent zone content disclosure. sizes, and prevent zone content disclosure.
This document updates RFC 4034 and 4035. This document updates RFCs 4034 and 4035.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/shuque/id-dnssec-compact-lies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 31 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9824.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 1. Introduction and Motivation
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Distinguishing non-existent names . . . . . . . . . . . . . . 4 2. Distinguishing Nonexistent Names
3. Generating Responses with NSEC . . . . . . . . . . . . . . . 4 3. Generating Responses with NSEC
3.1. Responses for Non-Existent Names . . . . . . . . . . . . 4 3.1. Responses for Nonexistent Names
3.2. Responses for Non-Existent Types . . . . . . . . . . . . 5 3.2. Responses for Nonexistent Types
3.3. Responses for Wildcard Matches . . . . . . . . . . . . . 5 3.3. Responses for Wildcard Matches
3.4. Responses for Unsigned Referrals . . . . . . . . . . . . 6 3.4. Responses for Unsigned Referrals
3.5. Responses to explicit queries for NXNAME . . . . . . . . 6 3.5. Responses to Explicit Queries for NXNAME
4. Generating Responses with NSEC3 . . . . . . . . . . . . . . . 7 4. Generating Responses with NSEC3
5. Response Code Restoration . . . . . . . . . . . . . . . . . . 8 5. Response Code Restoration
5.1. Signaled Response Code Restoration . . . . . . . . . . . 8 5.1. Signaled Response Code Restoration
6. Operational Implications . . . . . . . . . . . . . . . . . . 9 6. Operational Implications
7. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 9 7. Updates to RFCs
7.1. Updates to RFC 4034 . . . . . . . . . . . . . . . . . . . 9 7.1. Updates to RFC 4034
7.2. Updates to RFC 4035 . . . . . . . . . . . . . . . . . . . 10 7.2. Updates to RFC 4035
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Other Approaches
Appendix A. Other Approaches . . . . . . . . . . . . . . . . . . 14 Appendix B. Historical Implementation Notes
Appendix B. Historical Implementation Notes . . . . . . . . . . 15 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
1. Introduction and Motivation 1. Introduction and Motivation
One of the functions of the Domain Name System Security Extensions One of the functions of DNS Security Extensions (DNSSEC) [RFC9364] is
(DNSSEC) [RFC9364] is "Authenticated Denial of Existence", i.e., "authenticated denial of existence", i.e., proving that a DNS name or
proving that a DNS name or record type does not exist. Normally, record type does not exist. Normally, this is done by means of
this is done by means of signed NSEC or NSEC3 records. In the signed NSEC or NSEC3 records. In the precomputed signature model,
precomputed signature model, these records chain together existing these records chain together existing names, or cryptographic hashes
names, or cryptographic hashes of them in the zone. In the online of them, in the zone. In the online signing model, described for
signing model, described in NSEC and NSEC3 "White Lies" [RFC4470] NSEC in [RFC4470] and for NSEC3 in Appendix B of [RFC7129], they are
[RFC7129], they are used to dynamically compute an epsilon function used to dynamically compute an epsilon function around the QNAME.
around the queried name. A "Type Bit Maps" field in the data of the The Type Bit Maps field in the data of the NSEC or NSEC3 record
NSEC or NSEC3 record asserts which resource record types are present asserts which resource record (RR) types are present at the name.
at the name.
The response for a non-existent name requires up to 2 signed NSEC The response for a nonexistent name requires up to two signed NSEC
records or up to 3 signed NSEC3 records (and for online signers, the records or up to three signed NSEC3 records (and for online signers,
associated cryptographic computation), to prove that (1) the name did the associated cryptographic computation) to prove that (1) the name
not explicitly exist in the zone, and (2) that it could not have been did not explicitly exist in the zone and (2) it could not have been
synthesized by a wildcard. synthesized by a wildcard.
This document describes an alternative technique, "Compact Denial of This document describes an alternative technique, "Compact Denial of
Existence" or "Compact Answers", to generate a signed DNS response on Existence" or "Compact Answers", to generate a signed DNS response on
demand for a non-existent name by claiming that the name exists but demand for a nonexistent name by claiming that the name exists but
has no resource records associated with the queried type, i.e., it has no resource record sets associated with the queried type, i.e.,
returns a NODATA response rather than an NXDOMAIN response. A NODATA it returns a NODATA response rather than an NXDOMAIN response. A
response, which has a response code (RCODE) of NOERROR and an empty NODATA response, which has a response code (RCODE) of NOERROR and an
ANSWER section, requires only one NSEC or NSEC3 record matching the empty ANSWER section, requires only one NSEC or NSEC3 record matching
queried name. This has two advantages: the DNS response size is the QNAME. This has two advantages: The DNS response size is
smaller, and it reduces the online cryptographic work involved in smaller, and it reduces the online cryptographic work involved in
generating the response. generating the response.
The use of minimally covering NSEC or NSEC3 records also prevents The use of minimally covering NSEC or NSEC3 records also prevents
adversaries from enumerating the entire contents of DNS zones by adversaries from enumerating the entire contents of DNS zones by
walking the NSEC chain, or by performing an offline dictionary attack walking the NSEC chain or performing an offline dictionary attack on
on the hashes in the NSEC3 chain. the hashes in the NSEC3 chain.
This document assumes a reasonable level of familiarity with DNS This document assumes a reasonable level of familiarity with DNS
operations and protocol terms. Much of the terminology is explained operations and protocol terms. Much of the terminology is explained
in further detail in "DNS Terminology" [RFC9499]. in further detail in "DNS Terminology" [RFC9499].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Distinguishing non-existent names 2. Distinguishing Nonexistent Names
This method generates NODATA responses for non-existent names that This method generates NODATA responses for nonexistent names that
don't match a DNS wildcard. Since there are clearly no record types 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 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 only contain the NSEC and RRSIG types (and in the case of NSEC3, the
the Type Bit Maps field will be empty). Tools that need to Type Bit Maps field will be empty). Tools that need to accurately
accurately identify non-existent names in responses cannot rely on identify nonexistent names in responses cannot rely on this specific
this specific type bitmap because Empty Non-Terminal (ENT) names type bitmap because Empty Non-Terminal (ENT) names (which positively
(which positively exist) also have no record types at the name and exist) also have no record types at the name and will return exactly
will return exactly the same Type Bit Maps field. the same Type Bit Maps field.
This specification defines the use of a synthetic Resource Record
type to signal the presence of a non-existent name. The mnemonic for
this RR type is "NXNAME", chosen to clearly distinguish it from the
response code mnemonic NXDOMAIN.
Type Value Meaning This specification defines the use of NXNAME (128), a synthetic RR
NXNAME 128 NXDOMAIN indicator for Compact Denial of Existence type to signal the presence of a nonexistent name. See Section 9.
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 This RR type is added to the NSEC Type Bit Maps field for responses
to non-existent names, in addition to the required RRSIG and NSEC 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 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 [RFC6895], Type Bit Maps field. It is a "Meta-TYPE", as defined in [RFC6895],
stores no data in a DNS zone, and cannot be usefully queried. and it stores no data in a DNS zone and cannot be usefully queried.
Section 3.5 describes what a DNS resolver or authoritative server Section 3.5 describes what a DNS resolver or authoritative server
should do if it receives an explicit query for NXNAME. should do if it receives an explicit query for NXNAME.
No special handling of this RR type is required on the part of DNS No special handling of this RR type is required on the part of DNS
resolvers. However, resolvers may optionally implement the behavior resolvers. However, resolvers may optionally implement the behavior
described in Section 5.1 (Response Code Restoration) to better described in Section 5.1 ("Signaled Response Code Restoration") to
restore NXDOMAIN visibility to various applications that may remain better restore NXDOMAIN visibility to various applications that may
oblivious to the new NXNAME signal. remain oblivious to the new NXNAME signal.
3. Generating Responses with NSEC 3. Generating Responses with NSEC
This section describes various types of answers generated by This section describes various types of answers generated by
authoritative servers implementing Compact Denial of Existence using authoritative servers implementing Compact Denial of Existence using
NSEC. Section 4 describes changes needed to support NSEC3. NSEC. Section 4 describes changes needed to support NSEC3.
3.1. Responses for Non-Existent Names 3.1. Responses for Nonexistent Names
When the authoritative server receives a query for a non-existent When the authoritative server receives a query for a nonexistent name
name in a zone that it serves, a NODATA response (response code in a zone that it serves, a NODATA response (response code NOERROR,
NOERROR, empty Answer section) is generated with a dynamically empty Answer section) is generated with a dynamically constructed
constructed NSEC record with the owner name matching the queried name NSEC record with the owner name matching the QNAME placed in the
(QNAME) placed in the Authority section. Authority section.
The Next Domain Name field SHOULD be set to the immediate The Next Domain Name field SHOULD be set to the immediate
lexicographic successor of the QNAME. This is accomplished by adding lexicographic successor of the QNAME. This is accomplished by adding
a leading label with a single null (zero-value) octet. The Type Bit 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: Maps field MUST only have the bits set for the following RR Types:
RRSIG, NSEC, and NXNAME. RRSIG, NSEC, and NXNAME.
For example, a request for the non-existing name "a.example.com." For example, a request for the nonexistent name "a.example.com."
would result in the following NSEC record to be generated (in DNS would result in the generation of the following NSEC record (in DNS
presentation format): presentation format):
a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME a.example.com. 300 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
The NSEC record MUST have corresponding RRSIGs generated. The NSEC record MUST have corresponding RRSIGs generated.
3.2. Responses for Non-Existent Types 3.2. Responses for Nonexistent Types
When the authoritative server receives a query for a name that When the authoritative server receives a query for a name that exists
exists, but has no resource record sets associated with the queried but has no resource record sets associated with the queried type, it
type, it generates a NODATA response, with a dynamically constructed generates a NODATA response with a dynamically constructed signed
signed NSEC record in the Authority Section. The owner name of the NSEC record in the Authority section. The owner name of the NSEC
NSEC record matches the queried name. The Next Domain Name field is record matches the QNAME. The Next Domain Name field is set to the
set to the immediate lexicographic successor of the QNAME. The Type immediate lexicographic successor of the QNAME. The Type Bit Maps
Bit Maps field lists the available Resource Record types at the name. field lists the available RR types at the name.
An Empty Non-Terminal is a special subset of this category, where the An ENT is a special subset of this category, where the name has no
name has no resource record sets of any type (but has descendant resource record sets of any type (but has descendant names that do).
names that do). For a query for an Empty Non-Terminal, the NSEC Type For a query for an ENT, the NSEC Type Bit Maps field will only
Bit Maps field will only contain RRSIG and NSEC. (Note that this is contain RRSIG and NSEC. (Note that this is substantially different
substantially different than the ENT response in precomputed NSEC, than the ENT response in precomputed NSEC, where the NSEC record has
where the NSEC record has the same type bitmap, but "covers" rather the same type bitmap but "covers" rather than matches the ENT and has
than matches the ENT, and has the Next Domain Name field set to the the Next Domain Name field set to the next lexicographic descendant
next lexicographic descendent of the ENT in the zone.) of the ENT in the zone.)
3.3. Responses for Wildcard Matches 3.3. Responses for Wildcard Matches
For wildcard matches, the authoritative server will provide a For wildcard matches, the authoritative server will provide a
dynamically signed response that claims that the queried name exists dynamically signed response that claims that the QNAME exists
explicitly. Specifically, the answer RR set will have an RRSIG explicitly. Specifically, the answer RRset will have an RRSIG record
record demonstrating an exact match (i.e., the label count in the demonstrating an exact match (i.e., the label count in the RRSIG
RRSIG RDATA will be equal to the number of labels in the query name RDATA will be equal to the number of labels in the query name minus
minus the root label). This obviates the need to include an NSEC the root label). This obviates the need to include an NSEC record in
record in the Authority section of the response that shows that no the Authority section of the response that shows that no closer match
closer match than the wildcard was possible. than the wildcard was possible.
For a Wildcard NODATA match (where the queried name matches a For a wildcard NODATA match (where the QNAME matches a wildcard but
wildcard but no data for the queried type exists), a response akin to no data for the queried type exists), a response akin to a non-
a non-wildcard NODATA is returned. The Answer section is empty, and wildcard NODATA is returned. The Answer section is empty, and the
the Authority section contains a single NSEC record that matches the Authority section contains a single NSEC record that matches the
query name with a Type Bit Maps field representing the list of types query name with a Type Bit Maps field representing the list of types
available at the wildcard. available at the wildcard.
3.4. Responses for Unsigned Referrals 3.4. Responses for Unsigned Referrals
Per the DNSSEC protocol, a referral to an unsigned subzone includes Per the DNSSEC protocol, a referral to an unsigned subzone includes
an NSEC record whose Owner Name matches the subzone, and which proves an NSEC record whose owner name matches the subzone and proves the
the delegation is unsigned by the absence of the DS RRtype bit in the delegation is unsigned by the absence of the Delegation Signer (DS)
Type Bit Maps field. RR type bit in the Type Bit Maps field.
With Compact Denial of Existence, the Next Domain Name field for this With Compact Denial of Existence, the Next Domain Name field for this
NSEC record is computed with a slightly different epsilon function NSEC record is computed with a slightly different epsilon function
than the immediate lexicographic successor of the Owner Name, as that than the immediate lexicographic successor of the owner name, as that
name would then fall under the delegated subzone. Instead, the Next name would then fall under the delegated subzone. Instead, the Next
Domain Name field is formed by appending a zero octet to the first Domain Name field is formed by appending a zero octet to the first
label of the Owner Name. label of the owner name.
For example, a referral response for the subzone sub.example.com For example, a referral response for the subzone sub.example.com
would include an NSEC record like the following: would include an NSEC record like the following:
sub.example.com. 3600 IN NSEC sub\000.example.com. NS RRSIG NSEC sub.example.com. 300 IN NSEC sub\000.example.com. NS RRSIG NSEC
3.5. Responses to explicit queries for NXNAME 3.5. Responses to Explicit Queries for NXNAME
NXNAME is a meta type which should not appear anywhere in a DNS 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 message apart from the NSEC type bitmap of a Compact Answer response
for a non-existent name. If however a DNS server implementing this for a nonexistent name. However, if a DNS server implementing this
specification receives an explicit query for the NXNAME RR type, this specification receives an explicit query for the NXNAME RR type, this
section describes what the response should be. section describes what the response ought to be.
If an explicit query for the NXNAME RR type is received, the DNS If an explicit query for the NXNAME RR type is received, the DNS
server MUST return a Format Error (response code FORMERR). A server MUST return a Format Error (response code FORMERR). A
resolver should not forward these queries upstream or attempt resolver MUST NOT forward these queries upstream or attempt iterative
iterative resolution. Many DNS server implementations already return resolution. Many DNS server implementations already return errors
errors for all types in the meta and q-type range except those types for all types in the range for Meta-TYPEs and QTYPEs, except those
that are already defined to support queries. types that are already defined to support queries.
Optionally, a DNS server MAY also include the following [RFC8914]
Extended DNS Error (EDE) Code in the response:
INFO-CODE Purpose Optionally, a DNS server MAY also include the following Extended DNS
30 Invalid Query Type Error (EDE) code [RFC8914] in the response: 30 (Invalid Query Type).
See Section 9.
Note that this EDE code is generally applicable to any RR type that Note that this EDE code is generally applicable to any RR type that
should not appear in DNS queries. ought not appear in DNS queries.
4. Generating Responses with NSEC3 4. Generating Responses with NSEC3
The NSEC3 protocol [RFC5155] uses hashed names to provide zone NSEC3 [RFC5155] uses hashed names to provide zone enumeration
enumeration defense. This protection is already better provided by defense. This protection is better provided by minimally covering
minimally covering NSEC records. NSEC3's Opt-Out feature also NSEC records. NSEC3's Opt-Out feature also provides no specific
provides no specific benefit for online signing implementations benefit for online signing implementations (minimally covering NSEC3
(minimally covering NSEC3 records provide no useful Opt-Out span). records provide no useful Opt-Out span). Hence, there is no known
Hence, there is no known advantage to implementing Compact Denial of advantage to implementing Compact Denial of Existence with NSEC3.
Existence with NSEC3. However, an existing implementation of However, an existing implementation of conventional NSEC3 online
traditional NSEC3 online signing migrating to Compact Denial of signing migrating to Compact Denial of Existence may find it simpler
Existence may find it simpler to do so with NSEC3 than implementing to do so with NSEC3 rather than implementing NSEC from scratch.
NSEC from scratch.
For NSEC3, the functional details of the protocol remain as described For NSEC3, the functional details of the protocol remain as described
in Section 3, with the following changes: in Section 3, with the following changes.
NSEC3 records and their signatures are dynamically generated instead NSEC3 records and their signatures are dynamically generated instead
of NSEC. of NSEC.
The NSEC3 parameters should be set to algorithm 1, a flags field of 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 0, an additional hash iteration count of 0, and an empty salt. In
DNS presentation format, this is "1 0 0 -". DNS presentation format, this is "1 0 0 -".
The Owner Name of the NSEC3 resource record is the NSEC3 hash of the The owner name of the NSEC3 resource record is the NSEC3 hash of the
relevant domain name, encoded in Base32 with Extended Hex Alphabet relevant domain name, encoded in Base32 with Extended Hex Alphabet
([RFC4648], Section 7), prepended as a single label to the name of ([RFC4648], Section 7), prepended as a single label to the name of
the zone. The Next Hashed Owner Name is the immediate name successor the zone. The Next Hashed Owner Name is the immediate name successor
of the unencoded binary form of the previous hash, which can be of the unencoded binary form of the previous hash, which can be
computed by adding one to the binary hash value. computed by adding one to the binary hash value.
In responses for non-existent names, the Type Bit Maps field will In responses for nonexistent names, the Type Bit Maps field will
contain only the NXNAME meta-type. In responses to Empty Non- contain only the NXNAME Meta-TYPE. In responses to ENT names, the
Terminal names, the Type Bit Maps field will be empty. Type Bit Maps field will be empty.
For example, a request for the non-existent name "a.example.com." For example, a request for the nonexistent name "a.example.com."
would result in the following NSEC3 record to be generated: would result in the generation of the following NSEC3 record:
H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - ( H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (
H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME ) H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )
Unlike Compact Denial of Existence with NSEC, no special form of the Unlike Compact Denial of Existence with NSEC, no special form of the
next name field for unsigned referrals is needed. The Hashed Next Next Hashed Owner Name field for unsigned referrals is needed. The
Owner Name field remains the NSEC3 hash of original owner name plus Next Hashed Owner Name field remains the NSEC3 hash of original owner
one. name plus one.
5. Response Code Restoration 5. Response Code Restoration
For non-existent names, implementations should try wherever possible, For nonexistent names, implementations should try to preserve the
to preserve the response code value of 3 (NXDOMAIN). This is response code value of 3 (NXDOMAIN) whenever possible. This is
generally possible for non-DNSSEC enabled queries, namely those which generally possible for non-DNSSEC-enabled queries, namely those that
do not set the DNSSEC_OK EDNS flag (DO bit). For such queries, do not set the DO bit ("DNSSEC answer OK") in the EDNS0 OPT header.
authoritative servers implementing Compact Denial of Existence could For such queries, authoritative servers implementing Compact Denial
return a normal NXDOMAIN response. There may be limited benefit to of Existence could return a normal NXDOMAIN response. However, there
doing this however, since most modern DNS resolvers are DNSSEC-aware, may be limited benefit to doing this since most modern DNS resolvers
and by [RFC3225] Section 3, DNSSEC-aware recursive servers are are DNSSEC aware, and per Section 3 of [RFC3225], DNSSEC-aware
required to set the DO bit on outbound queries, regardless of the recursive servers are required to set the DO bit on outbound queries,
status of the DO bit on incoming requests. regardless of the status of the DO bit on incoming requests.
A validating resolver that understands the NXNAME signal from an A validating resolver that understands the NXNAME signal from an
authoritative server could modify the response code from NOERROR to authoritative server could modify the response code from NOERROR to
NXDOMAIN in responses they return to downstream queriers that have NXDOMAIN in responses they return to downstream queriers that have
not set the DO bit in their requests. not set the DO bit in their requests.
5.1. Signaled Response Code Restoration 5.1. Signaled Response Code Restoration
This section describes an optional but recommended scheme to permit This section describes an optional but recommended scheme to permit
signaled restoration of the NXDOMAIN RCODE for DNSSEC enabled signaled restoration of the NXDOMAIN RCODE for DNSSEC-enabled
responses. A new EDNS0 [RFC6891] header flag is defined in the 2nd responses. A new EDNS0 [RFC6891] header flag is defined in the
most significant bit of the flags field in the EDNS0 OPT header. second most significant bit of the flags field in the EDNS0 OPT
This flag is referred to as the "Compact Answers OK (CO)" flag. header. This flag is referred to as the Compact Answers OK (CO)
flag.
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION | 0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|CO| Z | 2: |DO|CO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
When this flag is sent in a query by a resolver, it indicates that When this flag is sent in a query by a resolver, it indicates that
the resolver will accept a signed NXNAME enhanced NODATA response for the resolver will accept a NODATA response with a signed NXNAME for a
a non-existent name together with the response code field set to nonexistent name, together with the response code field set to
NXDOMAIN (3). NXDOMAIN (3).
In responses to such queries, a Compact Denial authoritative server In responses to such queries, an authoritative server implementing
implementing this signaling scheme, will set the Compact Answers OK both Compact Denial of Existence and this signaling scheme will set
EDNS header flag, and for non-existent names will additionally set the Compact Answers OK EDNS header flag and, for nonexistent names,
the response code field to NXDOMAIN. will additionally set the response code field to NXDOMAIN.
EDNS is a hop by hop signal, so resolvers will need to record the 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 presence of this flag in associated cache data and respond to
downstream DNSSEC enabled queriers appropriately. If the querier downstream DNSSEC-enabled queriers appropriately. If the querier
does not set the Compact Answers OK flag, the resolver will need to 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. reset the response code back to NOERROR (0) for an NXNAME response.
6. Operational Implications 6. Operational Implications
For DNSSEC enabled queries, a signed zone at an authoritative server For DNSSEC-enabled queries, a signed zone at an authoritative server
implementing Compact Answers will never return a response with a implementing Compact Answers will never return a response with a
response code of NXDOMAIN, unless they have implemented the optional response code of NXDOMAIN, unless they have implemented the optional
response code restoration feature described in Section 5.1. response code restoration feature described in Section 5.1.
Similarly, resolvers not implementing this feature will also not be Similarly, resolvers not implementing this feature will also not be
able to return NXDOMAIN. In the absence of this, tools that rely on able to return NXDOMAIN. In the absence of this, tools that rely on
accurately determining non-existent names will need to infer them accurately determining nonexistent names will need to infer them from
from the presence of the NXNAME RR type in the Type Bit Maps field of the presence of the NXNAME RR type in the Type Bit Maps field of the
the NSEC record in NODATA responses from these servers. NSEC record in NODATA responses from these servers.
Address lookup functions typically invoked by applications may need Address lookup functions typically invoked by applications may need
to do more work when dealing with implementations of Compact Answers. to do more work when dealing with implementations of Compact Answers.
For example, a NODATA response to the lookup of an AAAA record for a For example, a NODATA response to the lookup of a AAAA record for a
non-existent name, can cause such functions to issue another query at nonexistent name can cause such functions to issue another query at
the same name for an A record. Whereas an NXDOMAIN response to the the same name for an A record, whereas an NXDOMAIN response to the
first query could suppress additional queries for other types at that first query could suppress additional queries for other types at that
name. Address lookup functions could be enhanced to issue DNSSEC name. Address lookup functions could be enhanced to issue DNSSEC-
enabled queries and to examine the NSEC Type Bit Maps field in enabled queries and to examine the NSEC Type Bit Maps field in
responses to accurately determine non-existent names. Note that this responses to accurately determine nonexistent names. Note that this
is less of a concern with Happy Eyeballs [RFC8305] style of is less of a concern with connection functions like Happy Eyeballs
connection functions that typically issue back to back DNS queries [RFC8305] that typically issue back-to-back DNS queries without
without waiting for individual responses. waiting for individual responses.
Protocol optimizations that enable DNS resolvers to synthesize Protocol optimizations that enable DNS resolvers to synthesize
NXDOMAIN or wildcard responses, like [RFC8020] and [RFC8198], cannot NXDOMAIN or wildcard responses, like those described in [RFC8020] and
be realized from responses that use Compact Denial of Existence. In [RFC8198], cannot be realized from responses that use Compact Denial
general, no online signing scheme that employs minimally covering of Existence. In general, no online signing scheme that employs
NSEC or NSEC3 records (including this one) permits RFC 8198 style minimally covering NSEC or NSEC3 records (including this one) permits
NXDOMAIN or wildcard response synthesis. Additionally, this protocol NXDOMAIN or wildcard response synthesis in the style described in
also precludes RFC 8020 style NXDOMAIN synthesis for DNSSEC enabled [RFC8198]. Additionally, this protocol also precludes NXDOMAIN
responses. synthesis for DNSSEC-enabled responses in the style described in
[RFC8020].
7. Updates to RFCs 7. Updates to RFCs
7.1. Updates to RFC 4034 7.1. Updates to RFC 4034
[RFC4034] Section 4.1.2, The Type Bit Maps Field, states the Section 4.1.2 of [RFC4034] ("The Type Bit Maps Field") states the
following: following:
* Bits representing pseudo-types MUST be clear, as they do not | Bits representing pseudo-types MUST be clear, as they do not
appear in zone data. If encountered, they MUST be ignored upon | appear in zone data. If encountered, they MUST be ignored upon
being read. | being read.
This paragraph is updated to the following: This paragraph is updated to the following:
* Bits representing pseudo-types MUST be clear, as they do not | Bits representing pseudo-types MUST be clear, as they do not
appear in zone data. If encountered, they MUST be ignored upon | appear in zone data. If encountered, they MUST be ignored upon
being read. There is one exception to this rule for Compact | being read. There is one exception to this rule for Compact
Denial of Existence (RFC TBD), where the NXNAME pseudo-type is | Denial of Existence (RFC 9824), where the NXNAME pseudo-type is
allowed to appear in responses to non-existent names. | allowed to appear in responses to nonexistent names.
Note: as a practical matter, no known resolver insists that pseudo- Note: As a practical matter, no known resolver insists that pseudo-
types must be clear in the NSEC Type Bit Maps, so this restriction 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 (prior to its revision) has posed no problem for the deployment of
this mechanism. this mechanism.
7.2. Updates to RFC 4035 7.2. Updates to RFC 4035
[RFC4035] Section 2.3, Including NSEC RRs in a Zone, states the Section 2.3 of [RFC4035] ("Including NSEC RRs in a Zone") states the
following: following:
* An NSEC record (and its associated RRSIG RRset) MUST NOT be the | An NSEC record (and its associated RRSIG RRset) MUST NOT be the
only RRset at any particular owner name. That is, the signing | only RRset at any particular owner name. That is, the signing
process MUST NOT create NSEC or RRSIG RRs for owner name nodes | 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 | that were not the owner name of any RRset before the zone was
signed. The main reasons for this are a desire for namespace | signed. The main reasons for this are a desire for namespace
consistency between signed and unsigned versions of the same zone | consistency between signed and unsigned versions of the same zone
and a desire to reduce the risk of response inconsistency in | and a desire to reduce the risk of response inconsistency in
security oblivious recursive name servers. | security oblivious recursive name servers.
This paragraph is updated to the following:: This paragraph is updated to the following:
* An NSEC record (and its associated RRSIG RRset) MUST NOT be the | An NSEC record (and its associated RRSIG RRset) MUST NOT be the
only RRset at any particular owner name. That is, the signing | only RRset at any particular owner name. That is, the signing
process MUST NOT create NSEC or RRSIG RRs for owner name nodes | 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 | that were not the owner name of any RRset before the zone was
signed. The main reasons for this are a desire for namespace | signed. The main reasons for this are a desire for namespace
consistency between signed and unsigned versions of the same zone | consistency between signed and unsigned versions of the same zone
and a desire to reduce the risk of response inconsistency in | and a desire to reduce the risk of response inconsistency in
security oblivious recursive name servers. This concern only | security oblivious recursive name servers. This concern only
applies to implementations of DNSSEC that employ pre-computed | applies to implementations of DNSSEC that employ precomputed
signatures. There is an exception to this rule for online signing | signatures. There is an exception to this rule for online signing
implementations of DNSSEC (e.g., Minimally Covering NSEC, and | implementations of DNSSEC (e.g., minimally covering NSEC and
Compact Denial of Existence), where dynamically generated NSEC | Compact Denial of Existence), where dynamically generated NSEC
records can be produced for owner names that don't exist or are | records can be produced for owner names that don't exist or are
empty non-terminals. | ENTs.
8. Security Considerations 8. Security Considerations
Online signing of DNS records requires authoritative servers for the Online signing of DNS records requires authoritative servers for the
DNS zone to have access to the private signing keys. Exposing DNS zone to have access to the private signing keys. Exposing
signing keys on Internet reachable servers makes them more vulnerable signing keys on Internet-reachable servers makes them more vulnerable
to attack. to attack.
Additionally, generating signatures on-demand is more computationally Additionally, generating signatures on demand is more computationally
intensive than returning pre-computed signatures. Although the intensive than returning precomputed signatures. Although the
Compact Answers scheme reduces the number of online signing Compact Answers scheme reduces the number of online signing
operations compared to previous techniques like White Lies, it still operations compared to previous techniques like White Lies, it still
may make authoritative servers more vulnerable to computational may make authoritative servers more vulnerable to computational
denial of service attacks than pre-computed signatures. The use of denial-of-service attacks than precomputed signatures. The use of
signature algorithms (like those based on Elliptic Curves) that have signature algorithms (like those based on elliptic curves) that have
a comparatively low cost for signing is recommended. a comparatively low cost for signing is recommended.
Some security tools rely on detection of non-existent domain names by Some security tools rely on detection of nonexistent domain names by
examining the response code field of DNS response messages. A examining the response code field of DNS response messages. A
NOERROR code in that field rather than NXDOMAIN will impact such NOERROR (rather than NXDOMAIN) code in that field will impact such
tools. Implementation of the optional response code restoration tools. Implementation of the optional response code restoration
scheme will help recover NXDOMAIN visibility for these tools. Note scheme will help recover NXDOMAIN visibility for these tools. Note
that the DNS header is not cryptographically protected, so the that the DNS header is not cryptographically protected, so the
response code field cannot be authenticated. Thus inferring the response code field cannot be authenticated. Thus, inferring the
status of a response from signed data in the body of the DNS message 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 is actually more secure. These tools could be enhanced to recognize
the (signed) NXNAME signal. the (signed) NXNAME signal.
Because this method does not allow for aggressive negative caching Because this method does not allow for aggressive negative caching
among resolvers, it allows for certain types of denial-of-service among resolvers, it allows for certain types of denial-of-service
attacks to be more effective. This includes so-called Pseudorandom attacks to be more effective. This includes so-called Pseudorandom
Subdomain Attacks [PRSD-ATTACK], where random names are queried, Subdomain Attacks [PRSD-ATTACK], where random names are queried,
either directly via botnets or across a wide range of public resolver either directly via botnets or across a wide range of public resolver
services, in order to intentionally generate non-existence responses services, in order to intentionally generate nonexistent responses
from the authoritative servers for a domain. If the resolver cannot from the authoritative servers for a domain. If the resolver cannot
synthesize NXDOMAIN responses from NSEC records, it must pass all synthesize NXDOMAIN responses from NSEC records, it must pass all
queries on to the domain's authority servers, making resource queries on to the domain's authority servers, making resource
exhaustion more likely at those latter servers, if those servers do exhaustion more likely at those latter servers if they do not have
not have the capacity to absorb those additional queries. the capacity to absorb those additional queries.
If the motivating aspects of this specification (minimizing response If the motivating aspects of this specification (minimizing response
size and computational costs) are not a concern, DNSSEC deployments size and computational costs) are not a concern, DNSSEC deployments
can opt for a different method (e.g., traditional online signing or can opt for a different method (e.g., conventional online signing or
pre-computed signatures), and avoid imposing the challenges of precomputed signatures) and avoid imposing the challenges of NXDOMAIN
NXDOMAIN visibility. visibility.
9. Acknowledgements 9. IANA Considerations
The Compact Answers technique (then called "Black Lies") was IANA has allocated the following in the "Resource Record (RR) TYPEs"
originally proposed in [BLACK-LIES] by Filippo Valsorda and Olafur registry in the "Domain Name System (DNS) Parameters" registry group,
Gudmundsson, and implemented by Cloudflare. The Empty Non-Terminal from the range for Meta-TYPEs. A lower number in this range lowers
distinguisher RR type was originally proposed in [ENT-SENTINEL] by the size of the Type Bit Maps field, which reduces the overall size
Shumon Huque, and deployed by NS1. The NXNAME type is based on the of the DNS response message.
FDOM type proposed in [NXDOMAIN-TYPE] by Gudmundsson and Valsorda.
Especially detailed discussions on many technical aspects of this +========+=======+=============================+===========+
document were conducted with Paul Vixie, Jan Vcelak, Viktor Dukhovni, | Type | Value | Meaning | Reference |
Ed Lewis, and John Levine. The authors would also like to thank the +========+=======+=============================+===========+
many other members of the IETF DNS Operations working group for | NXNAME | 128 | NXDOMAIN indicator for | RFC 9824 |
helpful comments and discussions. | | | Compact Denial of Existence | |
+--------+-------+-----------------------------+-----------+
10. IANA Considerations Table 1
IANA is requested to do the following: 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 Section 5.1.
Allocate a new DNS Resource Record type code for NXNAME from the +=======+======+====================+===========+
"Resource Record (RR) Types" registry in the "DNS parameters" | Bit | Flag | Description | Reference |
registry group, from the meta type range. Specifically, the lowest +=======+======+====================+===========+
available number (currently 128) in the meta types range is requested | Bit 1 | CO | Compact Answers OK | RFC 9824 |
to be allocated. A lower number lowers the size of the Type Bit Maps +-------+------+--------------------+-----------+
field, which reduces the overall size of the DNS response message.
Type Value Meaning Table 2
NXNAME 128 NXDOMAIN indicator for Compact Denial of Existence
Allocate the "Compact Answers OK" flag in the "EDNS Header Flags (16 Last, IANA has allocated the following code point in the "Extended
bits)" registry in the "Domain Name System (DNS) Parameters" registry DNS Error Codes" registry in the "Domain Name System (DNS)
group. Set the Flag field to "CO", as described in Section 5.1. Parameters" registry group. This code point is described in
Section 3.5.
Allocate a code point for "Invalid Query Type" in the "Extended DNS +===========+====================+===========+
Error Codes" registry in the "Domain Name System (DNS) Parameters" | INFO-CODE | Purpose | Reference |
registry group, as described in Section 3.5. +===========+====================+===========+
| 30 | Invalid Query Type | RFC 9824 |
+-----------+--------------------+-----------+
INFO-CODE Purpose Table 3
30 Invalid Query Type
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, DOI 10.17487/RFC3225, December 2001, RFC 3225, DOI 10.17487/RFC3225, December 2001,
<https://www.rfc-editor.org/info/rfc3225>. <https://www.rfc-editor.org/info/rfc3225>.
skipping to change at page 13, line 46 skipping to change at line 593
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914, Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020, DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>. <https://www.rfc-editor.org/info/rfc8914>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023, RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>. <https://www.rfc-editor.org/info/rfc9364>.
11.2. Informative References 10.2. Informative References
[BLACK-LIES] [COMPACT] Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of Existence or Black Lies", Work in Progress, Internet-
Existence or Black Lies", <https://tools.ietf.org/html/ Draft, draft-valsorda-dnsop-black-lies-00, 21 March 2016,
draft-valsorda-dnsop-black-lies>. <https://datatracker.ietf.org/doc/html/draft-valsorda-
dnsop-black-lies-00>.
[ENT-SENTINEL] [ENT-SENTINEL]
Huque, S., "Empty Non-Terminal Sentinel for Black Lies", Huque, S., "Empty Non-Terminal Sentinel for Black Lies",
<https://www.ietf.org/archive/id/draft-huque-dnsop- Work in Progress, Internet-Draft, draft-huque-dnsop-
blacklies-ent-01.html>. blacklies-ent-01, 27 July 2021,
<https://datatracker.ietf.org/doc/html/draft-huque-dnsop-
blacklies-ent-01>.
[NXDOMAIN-TYPE] [NXDOMAIN-TYPE]
Gudmundsson, O. and F. Valsorda, "Signaling NSEC record Gudmundsson, O. and F. Valsorda, "Signaling NSEC record
owner name nonexistence", <https://tools.ietf.org/html/ owner name nonexistence", Work in Progress, Internet-
draft-ogud-fake-nxdomain-type/>. Draft, draft-ogud-fake-nxdomain-type-00, 7 May 2015,
<https://datatracker.ietf.org/doc/html/draft-ogud-fake-
nxdomain-type-00>.
[PRSD-ATTACK] [PRSD-ATTACK]
Nishida, K., "Water Torture: A Slow Drip DNS DDoS Attack Nishida, K., "Water Torture: A Slow Drip DNS DDoS Attack
on QTNet", <https://conference.apnic.net/data/39/ on QTNet", <https://conference.apnic.net/data/39/
dnswatertortureonqtnet_1425130417_1425507043.pptx>. dnswatertortureonqtnet_1425130417_1425507043.pptx>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>. February 2014, <https://www.rfc-editor.org/info/rfc7129>.
skipping to change at page 14, line 44 skipping to change at line 644
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024, RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>. <https://www.rfc-editor.org/info/rfc9499>.
Appendix A. Other Approaches Appendix A. Other Approaches
In the past, some implementations of Compact Denial of Existence have In the past, some implementations of Compact Denial of Existence have
used other means to differentiate NXDOMAIN from Empty Non-Terminals. used other means to differentiate NXDOMAIN from ENTs.
One method employed by both Cloudflare and Amazon Route53 for a One method employed by both Cloudflare and Amazon Route53 for a
period of time was the following: for responses to Empty Non- period of time was the following: For responses to ENTs, they
Terminals, they synthesized the NSEC Type Bit Maps to include all synthesized the NSEC Type Bit Maps field to include all record types
record types supported except for the queried type. This method has supported except for the queried type. This method has the
the undesirable effect of no longer being able to reliably determine undesirable effect of no longer being able to reliably determine the
the existence of ENTs, and of making the Type Bit Maps field larger existence of ENTs and of making the Type Bit Maps field larger than
than it needs to be. It also has the potential to confuse validators it needs to be. It also has the potential to confuse validators and
and others tools that infer type existence from the NSEC record. others tools that infer type existence from the NSEC record.
Another way to distinguish NXDOMAIN from ENT is to define the Another way to distinguish NXDOMAIN from ENT is to define the
synthetic Resource Record type for ENTs instead, as specified in synthetic RR type for ENTs instead, as specified in [ENT-SENTINEL].
[ENT-SENTINEL]. This method was successfully deployed in the field This method was successfully deployed in the field by NS1 for a
by NS1 for a period of time. This typically imposes less work on the period of time. This typically imposes less work on the server since
server since NXDOMAIN responses are a lot more common than ENTs. At NXDOMAIN responses are a lot more common than ENTs. At the time it
the time it was deployed, it also allowed a common bitmap pattern was deployed, it also allowed a common bitmap pattern ("NSEC RRSIG")
("NSEC RRSIG") to identify NXDOMAIN across this and other to identify NXDOMAIN across this and other implementations that
implementations that returned a broad bitmap pattern for Empty Non- returned a broad bitmap pattern for ENTs. However, the advantage of
Terminals. However, the advantage of the NXNAME RR type is that it the NXNAME RR type is that it explicitly identifies NXDOMAIN
explicitly identifies NXDOMAIN responses, and allows them to be responses and allows them to be distinguished conclusively from
distinguished conclusively from potential ENT responses in other potential ENT responses in other online signing NSEC implementations.
online signing NSEC implementations.
Appendix B. Historical Implementation Notes Appendix B. Historical Implementation Notes
At the time of publication, the basic Compact Denial of Existence At the time of publication, the basic Compact Denial of Existence
method using NSEC is implemented by Cloudflare, NS1, Amazon Route53, method using NSEC is implemented by Cloudflare, NS1, Amazon Route53,
and Knot DNS's optional online signing module. From early 2021 until and Knot DNS's optional online signing module. From early 2021 until
November 2023, NS1 had deployed the Empty Non-Terminal distinguisher November 2023, NS1 had deployed the ENT distinguisher [ENT-SENTINEL]
[ENT-SENTINEL] using the private RR type code 65281. A version of using the private RR type code 65281. A version of the NXNAME
the NXNAME distinguisher using the private RR type code 65238 was distinguisher using the private RR type code 65238 was deployed by
deployed by both Cloudflare (from July 2023) and NS1 (from November both Cloudflare (from July 2023) and NS1 (from November 2023) until
2023) until roughly September 2024. Since September 2024 both roughly September 2024. Since September 2024, both Cloudflare and
Cloudflare and NS1 have deployed NXNAME using the officially NS1 have deployed NXNAME using the officially allocated code point of
allocated code point of 128. Oracle Cloud Initiative implemented 128. Oracle Cloud Initiative implemented Compact Denial of Existence
Compact Denial of Existence using NSEC3 in October 2024. using NSEC3 in October 2024.
Acknowledgements
The Compact Answers technique was originally proposed in [COMPACT] by
Filippo Valsorda and Olafur Gudmundsson and implemented by
Cloudflare. The ENT distinguisher RR type was originally proposed in
[ENT-SENTINEL] by Shumon Huque and deployed by NS1. The NXNAME type
is based on the FDOM type proposed in [NXDOMAIN-TYPE] by Gudmundsson
and Valsorda.
Especially detailed discussions on many technical aspects of this
document were conducted with Paul Vixie, Jan Včelák, Viktor Dukhovni,
Ed Lewis, and John Levine. 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 Authors' Addresses
Shumon Huque Shumon Huque
Salesforce Salesforce
415 Mission Street, 3rd Floor 415 Mission Street, 3rd Floor
San Francisco, CA 94105 San Francisco, CA 94105
United States of America United States of America
Email: shuque@gmail.com Email: shuque@gmail.com
Christian Elmerot Christian Elmerot
Cloudflare Cloudflare
101 Townsend St. 101 Townsend St.
San Francisco, CA 94107 San Francisco, CA 94107
United States of America United States of America
Email: elmerot@cloudflare.com Email: elmerot@cloudflare.com
Olafur Gudmundsson Olafur Gudmundsson
Retired / Unaffiliated
Email: ogud@ogud.com Email: ogud@ogud.com
 End of changes. 101 change blocks. 
352 lines changed or deleted 357 lines changed or added

This html diff was produced by rfcdiff 1.48.