idnits 2.17.1 draft-yorgos-dnsop-dry-run-dnssec-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 March 2022) is 777 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group Y. Thessalonikefs 3 Internet-Draft W. Toorop 4 Intended status: Standards Track NLnet Labs 5 Expires: 5 September 2022 R. Arends 6 ICANN 7 4 March 2022 9 dry-run DNSSEC 10 draft-yorgos-dnsop-dry-run-dnssec-00 12 Abstract 14 This document describes a method called "dry-run DNSSEC" that allows 15 for testing DNSSEC deployments without affecting the DNS service in 16 case of DNSSEC errors. It accomplishes that by introducing a new DS 17 Type Digest Algorithm that signals to validating resolvers that dry- 18 run DNSSEC is used for the zone. DNSSEC errors are then reported 19 with DNS Error Reporting, but the bogus response is withheld. 20 Instead resolvers fallback from dry-run DNSSEC and provide the 21 response that would have been answered without the presence of a dry- 22 run DS. A further option is presented for clients to opt-in for dry- 23 run DNSSEC errors and allow for end-to-end DNSSEC testing. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 5 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. The dry-run DS structure . . . . . . . . . . . . . . . . 4 62 3.2. DNSSEC Error Reporting . . . . . . . . . . . . . . . . . 4 63 3.3. Parent zone records . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. CDS and CDNSKEY Consideration . . . . . . . . . . . . 5 65 3.4. dry-run DS and real DS coexistence . . . . . . . . . . . 5 66 3.5. wet-run clients . . . . . . . . . . . . . . . . . . . . . 6 67 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. DRY-RUN DS Type Digest Algorithm . . . . . . . . . . . . 6 71 6.2. Wet-Run EDNS0 Option . . . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 74 9. Informative References . . . . . . . . . . . . . . . . . . . 7 75 Appendix A. Implementation Status . . . . . . . . . . . . . . . 8 76 Appendix B. Change History (to be removed before final 77 publication) . . . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 DNSSEC was introduced to provide DNS with data origin authentication 83 and data integrity. This introduced quite an amount of complexity 84 and fragility to the DNS which in turn still hinders general 85 adoption. When an operator decides to publish a newly signed zone 86 there is no way to realistically check that DNS will not break for 87 the zone. 89 This document describes a method called "dry-run DNSSEC" that gives 90 confidence to operators to adopt DNSSEC by introducing a new DS Type 91 Digest Algorithm. Resolvers that don't support the algorithm 92 continue to treat the delegation as insecure [RFC6840], Section 5.2. 93 Validating resolvers are signaled to treat the delegation as being in 94 an intermediate test step for DNSSEC. Valid answers yield authentic 95 data (AD) responses. Therefore, clients that expect the AD flag can 96 already profit from the transition. Invalid answers instead of 97 SERVFAIL yield the response that would have been answered when no 98 dry-run DS would have been present in the parent. For zones that had 99 only dry-run DS RRs in the parent, an invalid answer yields an 100 insecure response. This is of course not proper data integrity but 101 the delegation should not be considered DNSSEC signed at this point. 103 Based on DNS Error Reporting [DNS-ERROR-REPORTING], invalid answers 104 for dry-run DNSSEC errors generate reports in order to monitor 105 potential DNS breakage when changing the DNSSEC configuration for a 106 zone. This is also the main purpose of dry-run DNSSEC. 108 The signed zone is publicly deployed but DNSSEC configuration errors 109 cannot break DNS resolution yet. DNSSEC health feedback can pinpoint 110 potential issues back to the operator. When the operator is 111 confident that the DNSSEC adoption does not introduce DNS breakage, 112 the real DS record can be published on the parent zone and that 113 concludes the actual DNSSEC deployment. 115 Dry-run DNSSEC can further be used on already singed zones to test 116 key rollovers. In this case a dry-run DS record for the future key 117 is used next to the current DS record which itself needs to be also 118 presented in the dry-run format. Validating resolvers that 119 understand dry-run DNSSEC first try to validate with a dry-run DS 120 before falling back to real DSes. 122 For further end-to-end DNS testing, a new EDNS0 option code is 123 introduced that a client can send along with a query to a validating 124 resolver. This signals validating resolvers that the client has 125 opted-in to DNSSEC errors for dry-run delegations. The resolver 126 still uses DNS Error Reporting [DNS-ERROR-REPORTING] for dry-run 127 errors but instead of the insecure answer it provides the client with 128 the SERVFAIL answer, same as with actual DNSSEC. These clients are 129 called "wet-run clients". 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 dry-run DS The DS record with the special DS type digest algorithm 140 that signals dry-run DNSSEC for the delegation. 141 real DS The actual DS record for the delegation. Replaces the dry- 142 run DS to complete DNSSEC deployment. 144 dry-run zone A zone that is DNSSEC signed but uses a dry-run DS to 145 signal the use of the dry-run DNSSEC method. 146 wet-run client A client that has opted-in to receive the actual 147 DNSSEC errors from the upstream validating resolver instead of the 148 insecure answers. 150 3. Description 152 TODO 154 3.1. The dry-run DS structure 156 The dry-run DS record is a normal DS record with updated semantics to 157 allow for dry-run signaling to a validating resolver. The DS Type 158 Digest Algorithm value MUST be TBD (DRY-RUN). The first octet of the 159 DS Digest field contains the actual Type Digest Algorithm, followed 160 by the actual Digest: 162 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Key Tag | Algorithm | DRY-RUN | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Digest Type | / 168 +-+-+-+-+-+-+-+-+ Digest / 169 / / 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Validating resolvers encountering such a DS record will know to mark 173 this delegation as dry-run DNSSEC and extract the actual Type Digest 174 Algorithm and Digest from the dry-run DS Digest field. 176 Validating resolvers that have no knowledge for the DRY-RUN DS Type 177 Digest Algorithm MUST disregard the DS record as per [RFC6840], 178 Section 5.2. 180 3.2. DNSSEC Error Reporting 182 The main purpose of the dry-run DNSSEC proposal is to be able to 183 monitor potential DNS breakage when adopting DNSSEC for a zone. The 184 main tool to do that is DNS Error Reporting [DNS-ERROR-REPORTING]. 186 Operators that want to use dry-run DNSSEC SHOULD support DNSSEC Error 187 Reporting and have a reporting agent in place to receive the error 188 reports. 190 Implementations that support dry-run DNSSEC MUST also support DNSSEC 191 Error Reporting and report any DNSSEC errors for the dry-run zone to 192 the designated report agent. 194 3.3. Parent zone records 196 The only change that needs to happen for dry-run DNSSEC is for the 197 parent to be able to publish the dry-run DS record. If the parent 198 accepts DS records from the child, the child needs to provide the 199 dry-run DS record. If the parent does not accept DS records and 200 generates the DS records from the DNSKEY, support for generating the 201 dry-run DS record, when needed, should be added to the parent if dry- 202 run DNSSEC is a desirable feature. 204 When the child zone operator wants to complete the DNSSEC deployment, 205 the parent needs to be notified for the real DS record. 207 3.3.1. CDS and CDNSKEY Consideration 209 CDS works as expected by providing the dry-run DS content for the CDS 210 record. CDNSKEY cannot work by itself; it needs to be accompanied by 211 the aforementioned CDS to signal dry-run DNSSEC for the delegation. 212 Thus, parents that rely only on CDNSKEY need to add support for 213 checking the accompanying CDS record for the DRY-RUN DS Type Digest 214 Algorithm and generating a dry-run DS record. 216 Operators of a dry-run child zone are advised to publish both CDS and 217 CDNSKEY so that both cases above are covered. 219 3.4. dry-run DS and real DS coexistence 221 TODO tldr: for example testing key rollover. 223 * For ease of implementation and DoS prevention validators SHOULD 224 pick a DS and DNSKEY pair they understand from both the dry-run 225 and real pool of available DSes. 226 * If dry-run DSes are present, the validator MUST first consider 227 those. 228 * If real DS is picked by validator, carry on. 229 * If dry-run DS is picked, 230 - If everything OK, secure. 231 - If something not OK, should report and fallback to real DS. No 232 insecure answers for this one. It guarantees that the DNSSEC 233 of the zone is not altered. 234 - If going back to real DS, the real DS is now cached and no EDER 235 reports for the same dry-run DS should be generated. 237 3.5. wet-run clients 239 Wet-run clients are clients that send the EDNS0 option code TBD (Wet- 240 Run DNSSEC) when querying a validating resolver. These clients opt- 241 in to receive error responses in case of DNSSEC errors in a dry-run 242 zone. They allow for end-to-end DNSSEC testing in a controlled 243 environment. 245 Validating resolvers that recognise the option MUST respond with the 246 error that they would normally respond for a DNSSEC zone and MUST 247 attach the same EDNS0 option code TBD in the response to mark the 248 error response as coming from a dry-run zone. 250 Additional Extended DNS Errors can also be attached in the error 251 response by the validating resolver as per [RFC8914]. 253 4. Implementation Notes 255 TODO tldr; validating resolvers need to keep an additional DNSSEC 256 status for cached records that notes the DNSSEC status for the dry- 257 run part. Responses can then be provided based on the Wet-Run DNSSEC 258 EDNS0 option. 260 5. Security Considerations 262 Dry-run DNSSEC disables one of the fundamental guarantees of DNSSEC, 263 data integrity. Bogus answers for expired/invalid data will become 264 insecure answers providing the potentially wrong information back to 265 the requester. This is a feature of this proposal but it also allows 266 forged answers by third parties to still affect the zone. This 267 should be treated as a warning that dry-run DNSSEC is not an end 268 solution but rather a temporarily intermediate test step of a zone 269 going secure. 271 Parent zones that provide signed delegations to child zones should be 272 aware that by using dry-run DNSSEC (e.g., testing a key roll to a 273 stronger algorithm key) they risk the DNSSEC status of the child 274 zones. If the trust chain becomes invalid between parent and child 275 because of dry-run DNSSEC the child zone will be treated as insecure. 277 6. IANA Considerations 279 6.1. DRY-RUN DS Type Digest Algorithm 281 This document defines a new entry in the "Delegation Signer (DS) 282 Resource Record (RR) Type Digest Algorithms" registry: 284 +=======+=============+==========+=================+ 285 | Value | Digest Type | Status | Reference | 286 +=======+=============+==========+=================+ 287 | TBD | DRY-RUN | OPTIONAL | [this document] | 288 +-------+-------------+----------+-----------------+ 290 Table 1 292 6.2. Wet-Run EDNS0 Option 294 This document defines a new entry in the "DNS EDNS0 Option Codes 295 (OPT)" registry on the "Domain Name System (DNS) Parameters" page: 297 +=======+================+==========+=================+ 298 | Value | Name | Status | Reference | 299 +=======+================+==========+=================+ 300 | TBD | Wet-Run DNSSEC | Optional | [this document] | 301 +-------+----------------+----------+-----------------+ 303 Table 2 305 7. Acknowledgements 307 Martin Hoffmann contributed the idea of using the DS record of an 308 already signed zone also as a dry-run DS in order to facilitate 309 testing key rollovers. 311 8. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 319 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 320 May 2017, . 322 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 323 Lawrence, "Extended DNS Errors", RFC 8914, 324 DOI 10.17487/RFC8914, October 2020, 325 . 327 9. Informative References 329 [DNS-ERROR-REPORTING] 330 Arends, R. and M. Larson, "DNS Error Reporting", 331 . 334 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 335 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 336 DOI 10.17487/RFC6840, February 2013, 337 . 339 Appendix A. Implementation Status 341 *Note to the RFC Editor*: please remove this entire section before 342 publication. 344 In the following implementation status descriptions, "dry-run DNSSEC" 345 refers to dry-run DNSSEC as described in this document. 347 * TODO 349 Appendix B. Change History (to be removed before final publication) 351 * draft-yorgos-dnsop-dry-run-dnssec-00 353 | Initial public draft. 355 Authors' Addresses 357 Yorgos Thessalonikefs 358 NLnet Labs 359 Science Park 400 360 1098 XH Amsterdam 361 Netherlands 362 Email: george@nlnetlabs.nl 364 Willem Toorop 365 NLnet Labs 366 Science Park 400 367 1098 XH Amsterdam 368 Netherlands 369 Email: willem@nlnetlabs.nl 371 Roy Arends 372 ICANN 373 Email: roy.arends@icann.org