idnits 2.17.1 draft-huque-dnsop-blacklies-ent-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 July 2021) is 1004 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Huque 3 Internet-Draft Salesforce 4 Intended status: Informational 27 July 2021 5 Expires: 28 January 2022 7 Empty Non-Terminal Sentinel for Black Lies 8 draft-huque-dnsop-blacklies-ent-01 10 Abstract 12 The Black Lies method of providing compact DNSSEC denial of existence 13 proofs has some operational implications. Depending on the specific 14 implementation, it may provide no way to reliably distinguish Empty 15 Non-Terminal names from names that actually do not exist. This draft 16 describes the use of a synthetic DNS resource record type to act as 17 an explicit signal for Empty Non-Terminal names and which is conveyed 18 in an NSEC type bitmap. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 28 January 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 54 2. Synthetic Type for Empty Non-Terminal Names . . . . . . . . . 3 55 3. Status of Black Lies specification . . . . . . . . . . . . . 4 56 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction and Motivation 67 One of the functions of the Domain Name System Security Extensions 68 (DNSSEC) [RFC4033] [RFC4034] [RFC4035] is "Authenticated Denial of 69 Existence", i.e. proving that a DNS name or record type does not 70 exist. Normally, this is done by means of NSEC or NSEC3 records. In 71 the precomputed signature model, these records chain together 72 existing names, or cryptographic hashes of them in the zone. In the 73 online signing model, they are used to dynamically compute an epsilon 74 function around the queried name. A 'type bitmap' in the data field 75 of the NSEC or NSEC3 record asserts which resource record types are 76 present at the associated name. 78 An alternative method, Black Lies [BLACKLIES], described in an 79 expired Internet draft, provides more compact denial of existence 80 proofs for online signers by relying on a clever hack. For non- 81 existent names, it claims that the name exists, but has no resource 82 records associated with the queried type, i.e. it returns a NODATA 83 response rather than an NXDOMAIN response. A NODATA response (which 84 has a response code of NOERROR, and an empty ANSWER section) requires 85 only one NSEC record matching the queried name. This has two 86 advantages: the DNS response sizes are smaller, and it reduces the 87 online cryptographic work involved in generating the responses. By 88 contrast, an NXDOMAIN response requires multiple records (up to 2 89 when using NSEC, and up to 3 when using NSEC3) to prove that (1) the 90 name did not explicitly exist in the zone, and (2) that it could not 91 have been synthesized by a wildcard. 93 The Black Lies method has some operational implications. Tools that 94 rely on the correctness of the DNS response code (e.g. obtaining 95 NXDOMAIN for non-existent domains) no longer work. Arguably, we 96 should not be doing this anyway, since the response code in the DNS 97 header cannot be authenticated. This means that NXDOMAIN has to be 98 "inferred" from signed records in the DNS response. Whether this 99 inference can be reliably drawn depends on other details of the Black 100 Lies implementation. A Black Lies NODATA response contains only 101 "NSEC" and "RRSIG" in the NSEC type bitmap. This is not sufficient 102 to infer NXDOMAIN though, because Empty Non-Terminal (ENT) responses 103 (which positively exist) will return the exact same response. DNS 104 operators often rely on precisely distinguishing NXDOMAIN from 105 NODATA, including ENT responses (such as tools that prevent the 106 creation of zone cuts or DNAME records at ENTs to avoid accidentally 107 occluding names underneath them - these have been critical safety 108 features of our DNS record provisioning systems). 110 Of the 3 implementations I've examined, NS1 (previously) and Amazon 111 Route53 suffer from this NXDOMAIN/ENT indistinguishability. 112 Cloudflare avoids this problem by synthesizing the NSEC type bitmap 113 for ENTs to include all (?) RR Types they support, except for the 114 queried type. This has the side effect though of no longer being 115 able to reliably determine the existence of ENTs. 117 2. Synthetic Type for Empty Non-Terminal Names 119 This document proposes the use of a synthetic Resource Record type to 120 signal the presence of an Empty Non-Terminal name. This RR type is 121 added to the NSEC type bitmap for responses to ENTs. Currently, the 122 deployed examples of this scheme are using the private RR type code 123 65281. So the resulting type bitmap would have "NSEC RRSIG 124 TYPE65281". Should this document be published, a formal request for 125 an RR type number could be made. 127 NS1 has implemented this scheme in their Managed DNS platform. The 128 following is an example of a response to an Empty Non- Terminal name 129 hosted on their service: 131 $ dig +dnssec +multi ent1.sfdcsd.net. A 133 ; <<>> DiG 9.16.15 <<>> +dnssec +multi ent1.sfdcsd.net. A 134 ;; global options: +cmd 135 ;; Got answer: 136 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53091 137 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 139 ;; OPT PSEUDOSECTION: 140 ; EDNS: version: 0, flags: do; udp: 1232 141 ;; QUESTION SECTION: 142 ;ent1.sfdcsd.net. IN A 144 ;; AUTHORITY SECTION: 145 ent1.sfdcsd.net. 3592 IN RRSIG NSEC 13 3 3600 ( 146 20210712120255 20210710120255 44688 sfdcsd.net. 147 lG/EJq0M1cs6vw0ragtvMV+B/Sd2CAPsxo1/WIOT6BZt 148 /QxukD5k8AeygmWYKnrR9jdb2SnXBxFEQss/mTSAOw== ) 149 ent1.sfdcsd.net. 3592 IN NSEC \000.ent1.sfdcsd.net. RRSIG NSEC TYPE65281 150 sfdcsd.net. 3592 IN SOA dns1.p08.nsone.net. hostmaster.nsone.net. ( 151 1619363158 ; serial 152 43200 ; refresh (12 hours) 153 7200 ; retry (2 hours) 154 1209600 ; expire (2 weeks) 155 3600 ; minimum (1 hour) 156 ) 157 sfdcsd.net. 3592 IN RRSIG SOA 13 2 3600 ( 158 20210712120255 20210710120255 44688 sfdcsd.net. 159 m2J7Q6mk6Y8lNxXEWVNw2/cVJPIeHZMAAeYglTgyob3s 160 mXV5hTtOpydytWFynIjdKf8YeGOpZm3zqoyLyPgMbg== ) 162 3. Status of Black Lies specification 164 Despite the fact that Black Lies is not standardized or even formally 165 published as a protocol specification, it seems to be gaining in 166 popularity and deployment. At least 3 major DNS providers 167 (Cloudflare, NS1 and Amazon Route53) have deployed it. Due to the 168 fact that Black Lies relies on contorting existing semantics of the 169 DNS protocol, it seems unlikely that it could be published as a 170 "Standards Track" specification. But given deployment realities, it 171 seems desirable to have a stable specification published for it, even 172 if its status is Informational. 174 4. Implementation Status 176 NS1 has implemented the scheme described in this document. Example 177 code to infer NXDOMAIN from Black Lies NODATA responses can be found 178 here: https://github.com/shuque/blrcode 180 5. Acknowledgements 182 Jan Vcelak of NS1. 184 6. IANA Considerations 186 TBD based on DNSOP working group deliberations. 188 7. Security Considerations 190 The method proposed in this document addresses a potential security 191 issue, namely reliably determining NXDOMAIN in Black Lies 192 implementations. 194 8. References 196 8.1. Normative References 198 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 199 Rose, "DNS Security Introduction and Requirements", 200 RFC 4033, DOI 10.17487/RFC4033, March 2005, 201 . 203 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 204 Rose, "Resource Records for the DNS Security Extensions", 205 RFC 4034, DOI 10.17487/RFC4034, March 2005, 206 . 208 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 209 Rose, "Protocol Modifications for the DNS Security 210 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 211 . 213 8.2. Informative References 215 [BLACKLIES] 216 Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of 217 Existence or Black Lies", . 220 Author's Address 221 Shumon Huque 222 Salesforce 223 415 Mission Street, 3rd Floor 224 San Francisco, CA 94105 225 United States of America 227 Email: shuque@gmail.com