rfc9824v3.txt   rfc9824.txt 
Internet Engineering Task Force (IETF) S. Huque Internet Engineering Task Force (IETF) S. Huque
Request for Comments: 9824 Salesforce Request for Comments: 9824 Salesforce
Updates: 4034, 4035 C. Elmerot Updates: 4034, 4035 C. Elmerot
Category: Standards Track Cloudflare Category: Standards Track Cloudflare
ISSN: 2070-1721 O. Gudmundsson ISSN: 2070-1721 O. Gudmundsson
Retired/Unaffiliated
August 2025 August 2025
Compact Denial of Existence in DNSSEC Compact Denial of Existence in DNSSEC
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 nonexistent name by claiming that the name exists but 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 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
skipping to change at line 145 skipping to change at line 144
type bitmap because Empty Non-Terminal (ENT) names (which positively type bitmap because Empty Non-Terminal (ENT) names (which positively
exist) also have no record types at the name and will return exactly exist) also have no record types at the name and will return exactly
the same Type Bit Maps field. the same Type Bit Maps field.
This specification defines the use of NXNAME (128), a synthetic RR This specification defines the use of NXNAME (128), a synthetic RR
type to signal the presence of a nonexistent name. See Section 9. type to signal the presence of a nonexistent name. See Section 9.
The mnemonic for this RR type is NXNAME, chosen to clearly The mnemonic for this RR type is NXNAME, chosen to clearly
distinguish it from the response code mnemonic NXDOMAIN. 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 nonexistent 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],
and it 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 ("Signaled Response Code Restoration") to described in Section 5.1 ("Signaled Response Code Restoration") to
better restore NXDOMAIN visibility to various applications that may better restore NXDOMAIN visibility to various applications that may
skipping to change at line 182 skipping to change at line 181
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 nonexistent name "a.example.com." For example, a request for the nonexistent name "a.example.com."
would result in the generation of the following NSEC record (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 Nonexistent Types 3.2. Responses for Nonexistent Types
When the authoritative server receives a query for a name that exists When the authoritative server receives a query for a name that exists
but has no resource record sets associated with the queried type, it but has no resource record sets associated with the queried type, it
generates a NODATA response with a dynamically constructed signed generates a NODATA response with a dynamically constructed signed
NSEC record in the Authority section. The owner name of the NSEC 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 record matches the QNAME. The Next Domain Name field is set to the
skipping to change at line 240 skipping to change at line 239
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 that 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 nonexistent name. However, if 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 SHOULD NOT forward these queries upstream or attempt
iterative resolution. Many DNS server implementations already return iterative resolution. Many DNS server implementations already return
errors for all types in the range for Meta-TYPEs and QTYPEs, except errors for all types in the range for Meta-TYPEs and QTYPEs, except
those types that are already defined to support queries. those types that are already defined to support queries.
Optionally, a DNS server MAY also include the following Extended DNS Optionally, a DNS server MAY also include the following Extended DNS
Error (EDE) code [RFC8914] in the response: 30 (Invalid Query Type). Error (EDE) code [RFC8914] in the response: 30 (Invalid Query Type).
See Section 9. 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
NSEC3 [RFC5155] uses hashed names to provide zone enumeration NSEC3 [RFC5155] uses hashed names to provide zone enumeration
defense. This protection is already better provided by minimally defense. This protection is better provided by minimally covering
covering NSEC records. NSEC3's Opt-Out feature also provides no NSEC records. NSEC3's Opt-Out feature also provides no specific
specific benefit for online signing implementations (minimally benefit for online signing implementations (minimally covering NSEC3
covering NSEC3 records provide no useful Opt-Out span). Hence, there records provide no useful Opt-Out span). Hence, there is no known
is no known advantage to implementing Compact Denial of Existence advantage to implementing Compact Denial of Existence with NSEC3.
with NSEC3. However, an existing implementation of conventional However, an existing implementation of conventional NSEC3 online
NSEC3 online signing migrating to Compact Denial of Existence may signing migrating to Compact Denial of Existence may find it simpler
find it simpler to do so with NSEC3 rather than implementing NSEC to do so with NSEC3 rather than implementing NSEC from scratch.
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.
skipping to change at line 715 skipping to change at line 713
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. 11 change blocks. 
19 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.48.