Internet Engineering Task Force S. Huque Internet-Draft Salesforce Updates: 4034, 4035 (if approved) C. Elmerot Intended status: Standards Track Cloudflare Expires: 20 April 2025 O. Gudmundsson Retired / Unaffiliated 17 October 2024 Compact Denial of Existence in DNSSEC draft-ietf-dnsop-compact-denial-of-existence-05 Abstract This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimal NSEC record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. This document updates RFC 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 This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 April 2025. Huque, et al. Expires 20 April 2025 [Page 1] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 Copyright Notice Copyright (c) 2024 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 (https://trustee.ietf.org/ license-info) 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 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 2. Distinguishing non-existent names . . . . . . . . . . . . . . 3 3. Generating Responses . . . . . . . . . . . . . . . . . . . . 4 3.1. Responses for Non-Existent Names . . . . . . . . . . . . 4 3.2. Responses for Non-Existent Types . . . . . . . . . . . . 5 3.3. Responses for Wildcard Matches . . . . . . . . . . . . . 5 3.4. Responses to explicit queries for NXNAME . . . . . . . . 5 4. Response Code Restoration . . . . . . . . . . . . . . . . . . 6 4.1. Signaled Response Code Restoration . . . . . . . . . . . 6 5. Operational Implications . . . . . . . . . . . . . . . . . . 7 6. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Updates to RFC 4034 . . . . . . . . . . . . . . . . . . . 8 6.2. Updates to RFC 4035 . . . . . . . . . . . . . . . . . . . 8 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Other Approaches . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction and Motivation One of the functions of the Domain Name System Security Extensions (DNSSEC) [RFC9364] 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 in NSEC and NSEC3 "White Lies" [RFC4470] Huque, et al. Expires 20 April 2025 [Page 2] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 [RFC7129], they are used to dynamically compute an epsilon function around the queried name. A 'type bitmap' in the data field of the NSEC or NSEC3 record asserts which resource record types are present at the name. The response for a non-existent name requires up to 2 signed NSEC records or up to 3 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) that 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 non-existent name by claiming that the name exists but has no resource records 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 record matching the queried name. 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 records also prevents adversaries from enumerating the entire contents of DNS zones by walking NSEC chains. 2. Distinguishing non-existent names Since NODATA responses are generated for non-existent names, and there are no defined record types for the name, the NSEC type bitmap in the response will only contain "NSEC" and "RRSIG". Tools that need to accurately identify non-existent 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 bitmap. 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 NXNAME 128 NXDOMAIN indicator for Compact Denial of Existence Huque, et al. Expires 20 April 2025 [Page 3] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 This RR type is added to the NSEC type bitmap for responses to non- existent names (in addition to the required RRSIG and NSEC types). It is a "Meta-Type", as defined in [RFC6895], stores no data in a DNS zone, and cannot be usefully queried. Section 3.4 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 Section 4.1 (Response Code Restoration) to better restore NXDOMAIN visibility to various applications. 3. Generating Responses This section describes various types of answers generated by authoritative servers implementing Compact Denial of Existence. At the current time, the compact denial scheme is only defined for NSEC. While it could support NSEC3 too, there is no benefit in introducing the additional complexity associated with it. 3.1. Responses for Non-Existent Names When the authoritative server receives a query for a non-existent 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 queried name (QNAME). The Next Domain Name field SHOULD be set to the immediate lexicographic successor of the QNAME. The Type Bit Maps field MUST only have the bits set for the following RR Types: RRSIG, NSEC, and NXNAME. (The immedidate lexicographic successor is the typical case of the "DNS Name Successor" defined in [RFC4471]). For example, a request for the non-existing name a.example.com would cause the following NSEC record to be generated (in DNS presentation format): a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME The NSEC record MUST have corresponding RRSIGs generated. Huque, et al. Expires 20 April 2025 [Page 4] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 3.2. Responses for Non-Existent 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 queried name. The Next Domain Name field is set to the immediate lexicographic successor of the QNAME. The Type Bitmaps field lists the available Resource Record types at the name. An Empty Non-Terminal 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 Empty Non-Terminal, the NSEC type bitmap 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 descendent of the ENT in the zone.) 3.3. Responses for Wildcard Matches For wildcard matches, the authoritative server will provide a dynamically signed response that claims that the queried name exists explicitly. Specifically, the answer RR set 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 queried name 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 bitmap representing the list of types available at the wildcard. 3.4. Responses to explicit queries for NXNAME NXNAME is a meta type which should not appear anywhere in a DNS message apart from the NSEC type bitmap of a Compact Answer response for a non-existent name. If however a DNS server implementing this specification receives an explicit query for the NXNAME RR type, this section describes what the response should 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 should not forward these queries upstream or attempt Huque, et al. Expires 20 April 2025 [Page 5] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 iterative resolution. Many DNS server implementations already return errors for all types in the meta and q-type range except those types that are already defined to support queries. Optionally, a DNS server MAY also include the following [RFC8914] Extended DNS Error Code in the response: INFO-CODE Purpose 30 Invalid Query Type Note that this EDE code is generally applicable to any RR type that should not appear in DNS queries. 4. Response Code Restoration For non-existent names, implementations should try wherever possible, to preserve the response code value of 3 (NXDOMAIN). This is generally possible for non-DNSSEC enabled queries, namely those which do not set the DNSSEC_OK EDNS flag (DO bit). For such queries, authoritative servers implementing Compact Denial of Existence could return a normal NXDOMAIN response. There may be limited benefit to doing this however, since most modern DNS resolvers are DNSSEC-aware, and by [RFC3225] Section 3, 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. 4.1. 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 [RFC6891] header flag is defined in the 2nd 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 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Huque, et al. Expires 20 April 2025 [Page 6] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 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 a non-existent name together with the response code field set to NXDOMAIN (3). In responses to such queries, a Compact Denial authoritative server implementing this signaling scheme, will set the Compact Answers OK EDNS header flag, and for non-existent 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. 5. 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 Section 4.1. 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 non-existent names will need to infer them from the presence of the NXNAME RR type in the type bitmap 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 an AAAA record for a non-existent 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 would 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 bitmaps in responses to accurately determine non-existent names. Protocol optimizations that permit DNS resolvers to synthesize NXDOMAIN responses, like [RFC8020] and [RFC8198], cannot be realized with zones using Compact Denial of Existence. In general, no online signing scheme (including this one) that employs minimally covering NSEC records permits RFC 8198 style NXDOMAIN synthesis. Additionally, this protocol also precludes RFC 8020 style NXDOMAIN synthesis for DNSSEC enabled responses. 6. Updates to RFCs Huque, et al. Expires 20 April 2025 [Page 7] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 6.1. Updates to RFC 4034 [RFC4034] Section 4.1.2, 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 TBD), where the NXNAME pseudo-type is allowed to appear in responses to non-existent names. Note: as a practical matter, no known resolver insists that pseudo- types must be clear in the NSEC type bitmap, so this restriction (prior to its revision) has posed no problem for the deployment of this mechanism. 6.2. Updates to RFC 4035 [RFC4035] Section 2.3, 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 pre-computed signatures. There is an exception to this rule for online signing Huque, et al. Expires 20 April 2025 [Page 8] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 implementations of DNSSEC (e.g Minimally Covering NSEC, and Compact Denial of Existence (RFC TBD), where dynamically generated NSEC records can be produced for owner names that don't exist or are empty non-terminals. 7. Implementation Status Cloudflare, NS1, and Amazon Route53 currently implement the Compact Denial of Existence method. From early 2021 until November 2023, NS1 had deployed the Empty Non-Terminal distinguisher [ENT-SENTINEL] 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. At the current time, there are only prototype implementations of the signaled rcode restoration scheme. 8. 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 pre-computed 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 pre-computed 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 non-existent domain names by examining the response code field of DNS response messages. A NOERROR code in that field rather than NXDOMAIN 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 Water Torture Huque, et al. Expires 20 April 2025 [Page 9] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 attacks, where random names are queried, either directly via botnets or across a wide range of public resolver services, in order to intentionally generate non-existence 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 those servers 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. traditional online signing or pre-computed signatures), and avoid imposing the challenges of NXDOMAIN visibility. 9. Acknowledgements The Compact Answers technique (then called "Black Lies") was originally proposed in [BLACK-LIES] by Filippo Valsorda and Olafur Gudmundsson, and implemented by Cloudflare. The Empty Non-Terminal 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 Vcelak, Viktor Dukhovni, and Ed Lewis. The authors would also like to thank the many other members of the IETF DNS Operations working group for helpful comments and discussions. 10. IANA Considerations IANA has done or is requested to do the following: Done: Allocate a new DNS Resource Record type code for NXNAME in the DNS parameters registry, from the meta type range. Specifically, the lowest available number (currently 128) in the meta range is requested to be allocated. A lower number lowers the size of the type bitmap, which reduces the size of the DNS response message. Type Value Meaning NXNAME 128 NXDOMAIN indicator for Compact Denial of Existence Allocate the "Compact Answers OK" flag in the EDNS header, as described in Section 4.1. Huque, et al. Expires 20 April 2025 [Page 10] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 Done: Allocate a code point for the "Invalid Query Type" Extended DNS Error in the DNS parameters registry, as described in Section 3.4. Specifically code point 30 has been allocated. 11. References 11.1. Normative References [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/RFC4470, April 2006, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, . [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, . [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . Huque, et al. Expires 20 April 2025 [Page 11] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 11.2. Informative References [BLACK-LIES] Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of Existence or Black Lies", . [ENT-SENTINEL] Huque, S., "Empty Non-Terminal Sentinel for Black Lies", . [NXDOMAIN-TYPE] Gudmundsson, O. and F. Valsorda, "Signaling NSEC record owner name nonexistence", . [RFC4471] Sisson, G. and B. Laurie, "Derivation of DNS Name Predecessor and Successor", RFC 4471, DOI 10.17487/RFC4471, September 2006, . [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, . [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . Appendix A. Other Approaches In the past, some implementations of Compact Denial of Existence have used other means to differentiate NXDOMAIN from Empty Non-Terminals. One method employed by both Cloudflare and Amazon Route53 for a period of time was the following: for responses to Empty Non- Terminals, they synthesized the NSEC type bitmap 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 Bitmaps 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 Resource Record type for ENTs instead, as specified in [ENT-SENTINEL]. This method was successfully deployed in the field by NS1 for a period of time. This typically imposes less work on the Huque, et al. Expires 20 April 2025 [Page 12] Internet-Draft Compact Denial of Existence in DNSSEC October 2024 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 Empty Non- Terminals. 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. Authors' Addresses Shumon Huque Salesforce 415 Mission Street, 3rd Floor San Francisco, CA 94105 United States of America Email: shuque@gmail.com Christian Elmerot Cloudflare 101 Townsend St. San Francisco, CA 94107 United States of America Email: elmerot@cloudflare.com Olafur Gudmundsson Retired / Unaffiliated Email: ogud@ogud.com Huque, et al. Expires 20 April 2025 [Page 13]