idnits 2.17.1 draft-ietf-dnsop-dnssec-bcp-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 : ---------------------------------------------------------------------------- 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 (14 April 2022) is 736 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Best Current Practice 14 April 2022 5 Expires: 16 October 2022 7 DNS Security Extensions (DNSSEC) 8 draft-ietf-dnsop-dnssec-bcp-01 10 Abstract 12 This document describes the DNS security extensions (commonly called 13 "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of 14 others. One purpose is to introduce all of the RFCs in one place so 15 that the reader can understand the many aspects of DNSSEC. This 16 document does not update any of those RFCs. Another purpose is to 17 move DNSSEC to Best Current Practice status. 19 This document is currently maintained at 20 https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and 21 pull requests are welcomed. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 16 October 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. DNSSEC as a Best Current Practice . . . . . . . . . . . . 2 58 1.2. Implementing DNSSEC . . . . . . . . . . . . . . . . . . . 3 59 2. DNSSEC Core Documents . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Addition to the DNSSEC Core . . . . . . . . . . . . . . . 4 61 3. Additional Cryptographic Algorithms and DNSSEC . . . . . . . 4 62 4. Extensions to DNSSEC . . . . . . . . . . . . . . . . . . . . 5 63 5. Additional Documents of Interest . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The core specification for what we know as DNSSEC (the combination of 75 [RFC4033], [RFC4034], and [RFC4035]) describes a set of protocols 76 that provide origin authentication to data in the DNS. [RFC6840] 77 updates and extends those core RFCs, but does not fundamentally 78 change the way that DNSSEC works. 80 This document lists many (but not all) of the RFCs that should be 81 considered by someone creating an implementation of, or someone 82 deploying, modern DNSSEC. It uses terminology from those documents 83 without defining that terminology. It also points to the relevant 84 IANA registries that relate to DNSSEC. It does not, however, point 85 to standards that rely on zones needing to be signed by DNSSEC. 87 1.1. DNSSEC as a Best Current Practice 89 The DNSSEC set of protocols is widely considered the best current 90 practice for adding origin authentication of data in the DNS. To 91 date, no standards-track RFCs offer any other method for such origin 92 authentication of data in the DNS. 94 Some observers note that, more than 15 years after the DNSSEC 95 specification was published, it is still not widely deployed. Recent 96 estimates are that fewer than 10% of the domain names used for web 97 sites are signed, and only around a third of queries to recursive 98 resolvers are validated. However, this low level of implementation 99 does not affect whether DNSSEC is a best current practice; it just 100 indicates that the value of deploying DNSSEC is often considered 101 lower than the cost. Nonetheless, the significant deployment of 102 DNSSEC within some top-level domains (TLDs), and the near-universal 103 deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable 104 for implementation by both ordinary and highly sophisticated domain 105 owners. 107 1.2. Implementing DNSSEC 109 Developers of validating resolvers and authoritative servers, as well 110 as operators of operators of validating resolvers and authoritative 111 servers, need to know the parts of the DNSSEC protocol that would 112 affect them. They should read the DNSSEC core documents, and 113 probably at least be familiar with the extensions. Developers will 114 probably need to be very familiar with the algorithm documents as 115 well. 117 As a side note, some of the DNSSEC-related RFCs have significant 118 errata, so reading the RFCs should also include looking for the 119 related errata. 121 2. DNSSEC Core Documents 123 What we today call "DNSSEC" is formally version 3 of the DNSSEC 124 specification. However, earlier versions of DNSSEC were thinly 125 deployed and significantly less visible than the current DNSSEC 126 specification. Throughout this document, "DNSSEC" means the version 127 of the protocol initially defined in [RFC4033], [RFC4034], and 128 [RFC4035]. 130 The three initial core documents generally cover different topics: 132 * [RFC4033] is an overview of DNSSEC, including how it might change 133 the resolution of DNS queries. 135 * [RFC4034] specifies the DNS resource records used in DNSSEC. It 136 obsoletes many RFCs for earlier versions of DNSSEC. 138 * [RFC4035] covers the modifications to the DNS protocol incurred by 139 DNSSEC. These include signing zones, serving signed zones, 140 resolving in light of DNSSEC, and authenticating DNSSEC-signed 141 data. 143 At the time this set of core documents was published, someone could 144 create a DNSSEC implementation of signing software, of an DNSSEC- 145 aware authoritative server, and/or a DNSSEC-aware recursive resolver 146 from the three core documents plus a few older RFCs specifying the 147 cryptography used. Those two older documents are: 149 * [RFC2536] defines how to use the DSA signature algorithm (although 150 refers to other documents for the details). DSA was thinly 151 implemented and can safely be ignored by DNSSEC implementations 153 * [RFC3110] defines how to use the RSA signature algorithm (although 154 refers to other documents for the details). RSA is still the most 155 popular signing algorithm for DNSSEC. 157 2.1. Addition to the DNSSEC Core 159 As with any major protocol, developers and operators discovered 160 issues with the original core documents over the years. [RFC6840] is 161 an omnibus update to the original core documents and thus itself has 162 become a core document. In addition to covering new requirements 163 from new DNSSEC RFCs, it describes many important security and 164 interoperability issues that arose during the deployment of the 165 initial specifications, particularly after the DNS root was signed in 166 2010. It also lists some errors in the examples of the core 167 specifications. 169 [RFC6840] brings a few additions into the core of DNSSEC. It makes 170 NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is. It also makes 171 the SHA-2 hash function defined in [RFC4509] and [RFC5702] part of 172 the core as well. 174 3. Additional Cryptographic Algorithms and DNSSEC 176 Cryptography improves over time, and new algorithms get adopted by 177 various Internet protocols. Two new signing algorithms have been 178 adopted by the DNSSEC community: ECDSA [RFC6605] and EdDSA [RFC8080]. 179 The GOST signing algorithm [RFC5933] was also adopted, but has seen 180 very limited use, likely because it is a national algorithm specific 181 to a very small number of countries. 183 Implementation developers who want to know which algorithms to 184 implement in DNSSEC software should refer to [RFC8624]. Note that 185 this specification is only about what algorithms should and should 186 not be included in implementations: it is not advice for which 187 algorithms that zone operators should and should not sign with, nor 188 which algorithms recursive resolver operators should or should not 189 validate. 191 4. Extensions to DNSSEC 193 The DNSSEC community has extended the DNSSEC core and the 194 cryptographic algorithms both in terms of describing good operational 195 practices and in new protocols. Some of the RFCs that describe these 196 extensions include: 198 * [RFC5011] explains how recursive resolvers and the DNS root can 199 work together to automate the rollover of the root's key signing 200 key (KSK). 202 * [RFC6781] is a compendium of operational practices that may not be 203 obvious from reading just the core specifications. 205 * [RFC7344] describes using the CDS and CDNSKEY resource records to 206 help automate the creation of DS records in the parents of signed 207 zones. 209 * [RFC8078] extends [RFC7344] by showing how to do initial setup of 210 trusted relationships between signed parent and child zones. 212 * [RFC8198] describes how a validating resolver can emit fewer 213 queries in signed zones that use NSEC for negative caching. 215 * [RFC9077] updates [RFC8198] with respect to the time-to-live (TTL) 216 fields in signed records. 218 5. Additional Documents of Interest 220 The documents listed above constitute the core of DNSSEC, the 221 additional cryptographic algorithms, and the major extensions to 222 DNSSEC. This section lists some additional documents that someone 223 interested in implementing or operating DNSSEC might find of value. 225 * [RFC4470] "describes how to construct DNSSEC NSEC resource records 226 that cover a smaller range of names than called for by [RFC4034]". 228 * [RFC6975] "specifies a way for validating end-system resolvers to 229 signal to a server which digital signature and hash algorithms 230 they support". 232 * [RFC7129] "provides additional background commentary and some 233 context for the NSEC and NSEC3 mechanisms used by DNSSEC to 234 provide authenticated denial-of-existence responses". 236 * [RFC7583] "describes the issues surrounding the timing of events 237 in the rolling of a key in a DNSSEC-secured zone". 239 * [RFC7646] "defines Negative Trust Anchors (NTAs), which can be 240 used to mitigate DNSSEC validation failures by disabling DNSSEC 241 validation at specified domains". 243 * [RFC7958] "describes the format and publication mechanisms IANA 244 has used to distribute the DNSSEC trust anchors". 246 * [RFC8027] "describes problems that a Validating DNS resolver, 247 stub-resolver, or application might run into within a non- 248 compliant infrastructure". 250 * [RFC8145] "specifies two different ways for validating resolvers 251 to signal to a server which keys are referenced in their chain of 252 trust". 254 * [RFC8499] is a list of terminology used when talking about the 255 DNS; sections 10 and 11 cover DNSSEC. 257 * [RFC8509] "specifies a mechanism that will allow an end user and 258 third parties to determine the trusted key state for the root key 259 of the resolvers that handle that user's DNS queries". 261 * [RFC8901] "presents deployment models that accommodate this 262 scenario [when each DNS provider independently signs zone data 263 with their own keys] and describes these key-management 264 requirements". 266 There will certainly be other RFCs related to DNSSEC that are 267 published after this one. 269 6. IANA Considerations 271 IANA already has three registries that relate to DNSSEC: 273 * DNSSEC algorithm numbers (https://www.iana.org/assignments/dns- 274 sec-alg-numbers) 276 * DNSSEC NSEC3 parameters (https://www.iana.org/assignments/dnssec- 277 nsec3-parameters) 279 * DNSSEC DS RRtype digest algorithms 280 (https://www.iana.org/assignments/ds-rr-types) 282 The rules for the DNSSEC algorithm registry were set in the core RFCs 283 and updated by [RFC6014], [RFC6725], and [RFC9157]. 285 This document does not update or create any registries. 287 7. Security Considerations 289 All of the security considerations from all of the RFCs referenced in 290 this document apply here. 292 8. References 294 8.1. Normative References 296 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the 297 Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, 298 May 2001, . 300 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 301 Rose, "DNS Security Introduction and Requirements", 302 RFC 4033, DOI 10.17487/RFC4033, March 2005, 303 . 305 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 306 Rose, "Resource Records for the DNS Security Extensions", 307 RFC 4034, DOI 10.17487/RFC4034, March 2005, 308 . 310 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 311 Rose, "Protocol Modifications for the DNS Security 312 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 313 . 315 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 316 (DS) Resource Records (RRs)", RFC 4509, 317 DOI 10.17487/RFC4509, May 2006, 318 . 320 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 321 Security (DNSSEC) Hashed Authenticated Denial of 322 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 323 . 325 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 326 and RRSIG Resource Records for DNSSEC", RFC 5702, 327 DOI 10.17487/RFC5702, October 2009, 328 . 330 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 331 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 332 DOI 10.17487/RFC6840, February 2013, 333 . 335 8.2. Informative References 337 [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name 338 System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999, 339 . 341 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records 342 and DNSSEC On-line Signing", RFC 4470, 343 DOI 10.17487/RFC4470, April 2006, 344 . 346 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 347 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 348 September 2007, . 350 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 351 GOST Signature Algorithms in DNSKEY and RRSIG Resource 352 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 353 2010, . 355 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 356 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 357 November 2010, . 359 [RFC6605] Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital 360 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 361 DOI 10.17487/RFC6605, April 2012, 362 . 364 [RFC6725] Rose, S., "DNS Security (DNSSEC) DNSKEY Algorithm IANA 365 Registry Updates", RFC 6725, DOI 10.17487/RFC6725, August 366 2012, . 368 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 369 Operational Practices, Version 2", RFC 6781, 370 DOI 10.17487/RFC6781, December 2012, 371 . 373 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 374 Algorithm Understanding in DNS Security Extensions 375 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 376 . 378 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 379 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 380 February 2014, . 382 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 383 DNSSEC Delegation Trust Maintenance", RFC 7344, 384 DOI 10.17487/RFC7344, September 2014, 385 . 387 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 388 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 389 DOI 10.17487/RFC7583, October 2015, 390 . 392 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 393 and R. Weber, "Definition and Use of DNSSEC Negative Trust 394 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 395 . 397 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 398 "DNSSEC Trust Anchor Publication for the Root Zone", 399 RFC 7958, DOI 10.17487/RFC7958, August 2016, 400 . 402 [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, 403 "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, 404 DOI 10.17487/RFC8027, November 2016, 405 . 407 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 408 the Parent via CDS/CDNSKEY", RFC 8078, 409 DOI 10.17487/RFC8078, March 2017, 410 . 412 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 413 Algorithm (EdDSA) for DNSSEC", RFC 8080, 414 DOI 10.17487/RFC8080, February 2017, 415 . 417 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 418 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 419 RFC 8145, DOI 10.17487/RFC8145, April 2017, 420 . 422 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 423 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 424 July 2017, . 426 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 427 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 428 January 2019, . 430 [RFC8509] Huston, G., Damas, J., and W. Kumari, "A Root Key Trust 431 Anchor Sentinel for DNSSEC", RFC 8509, 432 DOI 10.17487/RFC8509, December 2018, 433 . 435 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 436 Requirements and Usage Guidance for DNSSEC", RFC 8624, 437 DOI 10.17487/RFC8624, June 2019, 438 . 440 [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. 441 Blacka, "Multi-Signer DNSSEC Models", RFC 8901, 442 DOI 10.17487/RFC8901, September 2020, 443 . 445 [RFC9077] van Dijk, P., "NSEC and NSEC3: TTLs and Aggressive Use", 446 RFC 9077, DOI 10.17487/RFC9077, July 2021, 447 . 449 [RFC9157] Hoffman, P., "Revised IANA Considerations for DNSSEC", 450 RFC 9157, DOI 10.17487/RFC9157, December 2021, 451 . 453 Appendix A. Acknowledgements 455 The DNS world owes a depth of gratitude to the authors and other 456 contributors to the core DNSSEC documents, and to the notable DNSSEC 457 extensions. 459 In addition, the following people made significant contributions to 460 early versions of this document: Ben Schwartz and Duane Wessels. 462 Author's Address 464 Paul Hoffman 465 ICANN 466 Email: paul.hoffman@icann.org