rfc9824v2.txt   rfc9824.txt 
skipping to change at line 88 skipping to change at line 88
Authors' Addresses Authors' Addresses
1. Introduction and Motivation 1. Introduction and Motivation
One of the functions of DNS Security Extensions (DNSSEC) [RFC9364] is One of the functions of DNS Security Extensions (DNSSEC) [RFC9364] is
"authenticated denial of existence", i.e., proving that a DNS name or "authenticated denial of existence", i.e., proving that a DNS name or
record type does not exist. Normally, this is done by means of record type does not exist. Normally, this is done by means of
signed NSEC or NSEC3 records. In the precomputed signature model, signed NSEC or NSEC3 records. In the precomputed signature model,
these records chain together existing names, or cryptographic hashes these records chain together existing names, or cryptographic hashes
of them, in the zone. In the online signing model, described for of them, in the zone. In the online signing model, described for
NSEC in [RFC4470] and for NSEC3 White Lies in [RFC7129], they are NSEC in [RFC4470] and for NSEC3 in Appendix B of [RFC7129], they are
used to dynamically compute an epsilon function around the QNAME. used to dynamically compute an epsilon function around the QNAME.
The Type Bit Maps field in the data of the NSEC or NSEC3 record 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. asserts which resource record (RR) types are present at the name.
The response for a nonexistent name requires up to two signed NSEC The response for a nonexistent name requires up to two signed NSEC
records or up to three signed NSEC3 records (and for online signers, records or up to three signed NSEC3 records (and for online signers,
the associated cryptographic computation) to prove that (1) the name the associated cryptographic computation) to prove that (1) the name
did not explicitly exist in the zone and (2) 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.
skipping to change at line 272 skipping to change at line 272
should not appear in DNS queries. should 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 already better provided by minimally
covering NSEC records. NSEC3's Opt-Out feature also provides no covering NSEC records. NSEC3's Opt-Out feature also provides no
specific benefit for online signing implementations (minimally specific benefit for online signing implementations (minimally
covering NSEC3 records provide no useful Opt-Out span). Hence, there covering NSEC3 records provide no useful Opt-Out span). Hence, there
is no known advantage to implementing Compact Denial of Existence is no known advantage to implementing Compact Denial of Existence
with NSEC3. However, an existing implementation of traditional NSEC3 with NSEC3. However, an existing implementation of conventional
online signing migrating to Compact Denial of Existence may find it NSEC3 online signing migrating to Compact Denial of Existence may
simpler to do so with NSEC3 rather than implementing NSEC from find it simpler to do so with NSEC3 rather than implementing NSEC
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 -".
skipping to change at line 490 skipping to change at line 490
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 nonexistent 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 they do not have exhaustion more likely at those latter servers if they do 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
precomputed signatures) and avoid imposing the challenges of NXDOMAIN precomputed signatures) and avoid imposing the challenges of NXDOMAIN
visibility. visibility.
9. IANA Considerations 9. IANA Considerations
IANA has allocated the following in the "Resource Record (RR) TYPEs" IANA has allocated the following in the "Resource Record (RR) TYPEs"
registry in the "Domain Name System (DNS) Parameters" registry group, registry in the "Domain Name System (DNS) Parameters" registry group,
from the range for Meta-TYPEs. A lower number in this range lowers 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 the size of the Type Bit Maps field, which reduces the overall size
of the DNS response message. of the DNS response message.
skipping to change at line 597 skipping to change at line 597
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>.
10.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", Work in Progress, Internet-
Draft, draft-valsorda-dnsop-black-lies-00, 21 March 2016, Draft, draft-valsorda-dnsop-black-lies-00, 21 March 2016,
<https://datatracker.ietf.org/doc/html/draft-valsorda- <https://datatracker.ietf.org/doc/html/draft-valsorda-
dnsop-black-lies-00>. 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",
Work in Progress, Internet-Draft, draft-huque-dnsop- Work in Progress, Internet-Draft, draft-huque-dnsop-
blacklies-ent-01, 27 July 2021, blacklies-ent-01, 27 July 2021,
<https://datatracker.ietf.org/doc/html/draft-huque-dnsop- <https://datatracker.ietf.org/doc/html/draft-huque-dnsop-
skipping to change at line 686 skipping to change at line 685
using the private RR type code 65281. A version of the NXNAME using the private RR type code 65281. A version of the NXNAME
distinguisher using the private RR type code 65238 was deployed by distinguisher using the private RR type code 65238 was deployed by
both Cloudflare (from July 2023) and NS1 (from November 2023) until both Cloudflare (from July 2023) and NS1 (from November 2023) until
roughly September 2024. Since September 2024, both Cloudflare and roughly September 2024. Since September 2024, both Cloudflare and
NS1 have deployed NXNAME using the officially allocated code point of NS1 have deployed NXNAME using the officially allocated code point of
128. Oracle Cloud Initiative implemented Compact Denial of Existence 128. Oracle Cloud Initiative implemented Compact Denial of Existence
using NSEC3 in October 2024. using NSEC3 in October 2024.
Acknowledgements Acknowledgements
The Compact Answers technique (then called "Black Lies") was The Compact Answers technique was originally proposed in [COMPACT] by
originally proposed in [BLACK-LIES] by Filippo Valsorda and Olafur Filippo Valsorda and Olafur Gudmundsson and implemented by
Gudmundsson and implemented by Cloudflare. The ENT distinguisher RR Cloudflare. The ENT distinguisher RR type was originally proposed in
type was originally proposed in [ENT-SENTINEL] by Shumon Huque and [ENT-SENTINEL] by Shumon Huque and deployed by NS1. The NXNAME type
deployed by NS1. The NXNAME type is based on the FDOM type proposed is based on the FDOM type proposed in [NXDOMAIN-TYPE] by Gudmundsson
in [NXDOMAIN-TYPE] by Gudmundsson and Valsorda. and Valsorda.
Especially detailed discussions on many technical aspects of this Especially detailed discussions on many technical aspects of this
document were conducted with Paul Vixie, Jan Včelák, Viktor Dukhovni, 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 Ed Lewis, and John Levine. The authors would also like to thank the
many other members of the IETF DNS Operations Working Group for many other members of the IETF DNS Operations Working Group for
helpful comments and discussions. helpful comments and discussions.
Authors' Addresses Authors' Addresses
Shumon Huque Shumon Huque
 End of changes. 5 change blocks. 
14 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.48.