Internet Engineering Task Force S. Huque Internet-Draft Salesforce Intended status: Standards Track C. Elmerot Expires: 29 August 2023 Cloudflare 25 February 2023 Compact Denial of Existence in DNSSEC draft-huque-dnsop-compact-lies-00 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 NSEC record and allow online signing servers to minimize signing operations and response sizes. 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 29 August 2023. Copyright Notice Copyright (c) 2023 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. Huque & Elmerot Expires 29 August 2023 [Page 1] Internet-Draft Compact Denial of Existence in DNSSEC February 2023 Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 2. Distinguishing NXDOMAIN from Empty Non-Terminal Names . . . . 3 3. Responses for Non-Existent Names . . . . . . . . . . . . . . 3 4. Responses for Wildcard Matches . . . . . . . . . . . . . . . 4 5. Responses for Empty Non-Terminals . . . . . . . . . . . . . . 4 6. Operational Implications . . . . . . . . . . . . . . . . . . 4 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 11.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction and Motivation One of the functions of the Domain Name System Security Extensions (DNSSEC) [RFC4033] [RFC4034] [RFC4035] [RFC5155] 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] [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 upto 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 Lies", 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 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. Huque & Elmerot Expires 29 August 2023 [Page 2] Internet-Draft Compact Denial of Existence in DNSSEC February 2023 2. Distinguishing NXDOMAIN from Empty Non-Terminal 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. Today, some specific implementations of Compact Lies avoid the NXDOMAIN identification problem by synthesizing the NSEC type bitmap for ENTs to include all record types supported except for the queried type. This has the undesirable effect of no longer being able to reliably determine the existence of ENTs. This document defines the use of a synthetic Resource Record type to signal the presence of an Empty Non-Terminal name. The mnemonic for this RR type is "ENT" and its type code is [TBD]. This RR type is added to the NSEC type bitmap for responses to ENTs. No special handling of this RR type is needed on the part of DNS resolvers. 3. Responses for Non-Existent Names When an authoritative server implementing Compact Lies 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 name SHOULD be set to the immediate lexicographic successor of the QNAME. The generated NSEC record's type bitmap MUST have only the RRSIG and NSEC bits set. 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 The NSEC record MUST have corresponding RRSIGs generated. Huque & Elmerot Expires 29 August 2023 [Page 3] Internet-Draft Compact Denial of Existence in DNSSEC February 2023 4. Responses for Wildcard Matches For wildcard matches, a Compact Lies implementation will typically provide a dynamically signed response that claims that the queried name exists explicitly. This obviates the need to include an NSEC record in the Additional section of the response that shows that no closer match than the wildcard was possible. Similarly, Wildcard NODATA responses (where the queried name matches a wildcard but no data for the queried type exists), a response akin to a regular NODATA is returned. The Answer section is empty, and the Additional section contains a single NSEC record that matches the query name with a type bitmap representing the list of types available at the wildcard. 5. Responses for Empty Non-Terminals When an authoritative server implementing Compact Lies receives a query for an Empty Non-Terminal name, it generates a NODATA response in the usual way, except that it adds the additional Empty Non- Terminal distinguisher RR type code in the NSEC type bitmap field. Corresponding RRSIG signature record(s) MUST also be generated. ent1.example.net. 3600 IN NSEC \000.ent.example.net. RRSIG NSEC ENT Note that this RR type only appears in the type bitmap of an NSEC record in response to a query for an Empty Non-Terminal name. It causes no special processing on the part of validating resolvers. Queries for the ENT RR type itself at an actual Empty Non-Terminal MUST also elicit the response described in this section. 6. Operational Implications A signed zone at an authoritative server implementing Compact Lies will never return a response with a response code of NXDOMAIN. Tools that rely on accurately determining non-existent names will need to infer them from the NSEC type bitmap pattern of "NSEC RRSIG". Address lookup functions typically invoked by applications won't see a practical impact from this indistinguishability. For a non- existent name, the getaddrinfo() function for example will return an exit code of EAI_NODATA rather than EAI_NONAME. But either way the effect on the caller is the same: it will obtain a response with a non-zero exit code and no available addresses. Huque & Elmerot Expires 29 August 2023 [Page 4] Internet-Draft Compact Denial of Existence in DNSSEC February 2023 7. Implementation Status Cloudflare, NS1, and Amazon Route53 currently implement the base Compact Lies scheme. NS1 additonally implements the Empty Non- Terminal distinguisher in the NSEC type bitmap, using the private RR type code 65281. 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 Lies 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. 9. Acknowledgements The Compact Lies technique (then called "Black Lies") was originally proposed in [COMPACT-LIES] by F. Valsorda and O. Gudmunsson, and implemented by Cloudflare. The Empty Non-Terminal distinguisher RR type was originally proposed in [ENT-SENTINEL] by S. Huque. 10. IANA Considerations IANA is requested to allocate a new DNS Resource Record type code for the Empty Non-Terminal distinguisher in the DNS parameters registry: ENT [TBD] Empty Non-Terminal Distinguisher for Compact Lies 11. References 11.1. Normative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . Huque & Elmerot Expires 29 August 2023 [Page 5] Internet-Draft Compact Denial of Existence in DNSSEC February 2023 [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, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, . 11.2. Informative References [COMPACT-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", . Authors' Addresses Shumon Huque Salesforce 415 Mission Street, 3rd Floor San Francisco, CA 94105 United States of America Email: shuque@gmail.com Huque & Elmerot Expires 29 August 2023 [Page 6] Internet-Draft Compact Denial of Existence in DNSSEC February 2023 Christian Elmerot Cloudflare 101 Townsend St. San Francisco, CA 94107 United States of America Email: elmerot@cloudflare.com Huque & Elmerot Expires 29 August 2023 [Page 7]