1 Internet Engineering Task Force (IETF) P. Hoffman
2 Request for Comments: 9364 ICANN
3 BCP: 237 February 2023
4 Category: Best Current Practice
5 ISSN: 2070-1721
6
7
8 DNS Security Extensions (DNSSEC)
9
10 Abstract
11
12 This document describes the DNS Security Extensions (commonly called
13 "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as
14 a handful of others. One purpose is to introduce all of the RFCs in
15 one place so that the reader can understand the many aspects of
16 DNSSEC. This document does not update any of those RFCs. A second
17 purpose is to state that using DNSSEC for origin authentication of
18 DNS data is the best current practice. A third purpose is to provide
19 a single reference for other documents that want to refer to DNSSEC.
20
21 Status of This Memo
22
23 This memo documents an Internet Best Current Practice.
24
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Further information on
29 BCPs is available in Section 2 of RFC 7841.
30
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 https://www.rfc-editor.org/info/rfc9364.
34
35 Copyright Notice
36
37 Copyright (c) 2023 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
39
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (https://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Revised BSD License text as described in Section 4.e of the
47 Trust Legal Provisions and are provided without warranty as described
48 in the Revised BSD License.
49
50 Table of Contents
51
52 1. Introduction
53 1.1. DNSSEC as a Best Current Practice
54 1.2. Implementing DNSSEC
55 2. DNSSEC Core Documents
56 2.1. Addition to the DNSSEC Core
57 3. Additional Cryptographic Algorithms and DNSSEC
58 4. Extensions to DNSSEC
59 5. Additional Documents of Interest
60 6. IANA Considerations
61 7. Security Considerations
62 8. References
63 8.1. Normative References
64 8.2. Informative References
65 Acknowledgements
66 Author's Address
67
68 1. Introduction
69
70 The core specification for what we know as DNSSEC (the combination of
71 [RFC4033], [RFC4034], and [RFC4035]) describes a set of protocols
72 that provide origin authentication of DNS data. [RFC6840] updates
73 and extends those core RFCs but does not fundamentally change the way
74 that DNSSEC works.
75
76 This document lists RFCs that should be considered by someone
77 creating an implementation of, or someone deploying, DNSSEC as it is
78 currently standardized. Although an effort was made to be thorough,
79 the reader should not assume this list is comprehensive. It uses
80 terminology from those documents without defining that terminology.
81 It also points to the relevant IANA registry groups that relate to
82 DNSSEC. It does not, however, point to standards that rely on zones
83 needing to be signed by DNSSEC, such as DNS-Based Authentication of
84 Named Entities (DANE) [RFC6698].
85
86 1.1. DNSSEC as a Best Current Practice
87
88 Using the DNSSEC set of protocols is the best current practice for
89 adding origin authentication of DNS data. To date, no Standards
90 Track RFCs offer any other method for such origin authentication of
91 data in the DNS.
92
93 More than 15 years after the DNSSEC specification was published, it
94 is still not widely deployed. Recent estimates are that fewer than
95 10% of the domain names used for websites are signed, and only around
96 a third of queries to recursive resolvers are validated. However,
97 this low level of deployment does not affect whether using DNSSEC is
98 a best current practice; it just indicates that the value of
99 deploying DNSSEC is often considered lower than the cost.
100 Nonetheless, the significant deployment of DNSSEC beneath some top-
101 level domains (TLDs) and the near-universal deployment of DNSSEC for
102 the TLDs in the DNS root zone demonstrate that DNSSEC is applicable
103 for implementation by both ordinary and highly sophisticated domain
104 owners.
105
106 1.2. Implementing DNSSEC
107
108 Developers of validating resolvers and authoritative servers, as well
109 as operators of validating resolvers and authoritative servers, need
110 to know the parts of the DNSSEC protocol that would affect them.
111 They should read the DNSSEC core documents and probably at least be
112 familiar with the extensions. Developers will probably need to be
113 very familiar with the algorithm documents as well.
114
115 As a side note, some of the DNSSEC-related RFCs have significant
116 errata, so reading the RFCs should also include looking for the
117 related errata.
118
119 2. DNSSEC Core Documents
120
121 What we refer to as "DNSSEC" is the third iteration of the DNSSEC
122 specification; [RFC2065] was the first, and [RFC2535] was the second.
123 Earlier iterations have not been deployed on a significant scale.
124 Throughout this document, "DNSSEC" means the protocol initially
125 defined in [RFC4033], [RFC4034], and [RFC4035].
126
127 The three initial core documents generally cover different topics:
128
129 * [RFC4033] is an overview of DNSSEC, including how it might change
130 the resolution of DNS queries.
131
132 * [RFC4034] specifies the DNS resource records used in DNSSEC. It
133 obsoletes many RFCs about earlier versions of DNSSEC.
134
135 * [RFC4035] covers the modifications to the DNS protocol incurred by
136 DNSSEC. These include signing zones, serving signed zones,
137 resolving in light of DNSSEC, and authenticating DNSSEC-signed
138 data.
139
140 At the time this set of core documents was published, someone could
141 create a DNSSEC implementation of signing software, of a DNSSEC-aware
142 authoritative server, and/or of a DNSSEC-aware recursive resolver
143 from the three core documents, plus a few older RFCs specifying the
144 cryptography used. Those two older documents are the following:
145
146 * [RFC2536] defines how to use the DSA signature algorithm (although
147 it refers to other documents for the details). DSA was thinly
148 implemented and can safely be ignored by DNSSEC implementations.
149
150 * [RFC3110] defines how to use the RSA signature algorithm (although
151 refers to other documents for the details). RSA is still among
152 the most popular signing algorithms for DNSSEC.
153
154 It is important to note that later RFCs update the core documents.
155 As just one example, [RFC9077] changes how TTL values are calculated
156 in DNSSEC processing.
157
158 2.1. Addition to the DNSSEC Core
159
160 As with any major protocol, developers and operators discovered
161 issues with the original core documents over the years. [RFC6840] is
162 an omnibus update to the original core documents and thus itself has
163 become a core document. In addition to covering new requirements
164 from new DNSSEC RFCs, it describes many important security and
165 interoperability issues that arose during the deployment of the
166 initial specifications, particularly after the DNS root was signed in
167 2010. It also lists some errors in the examples of the core
168 specifications.
169
170 [RFC6840] brings a few additions into the core of DNSSEC. It makes
171 NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is. It also makes
172 the SHA-256 and SHA-512 hash functions defined in [RFC4509] and
173 [RFC5702] part of the core.
174
175 3. Additional Cryptographic Algorithms and DNSSEC
176
177 Current cryptographic algorithms typically weaken over time as
178 computing power improves and new cryptoanalysis emerges. Two new
179 signing algorithms have been adopted by the DNSSEC community:
180 Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605] and
181 Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8080]. ECDSA
182 and EdDSA have become very popular signing algorithms in recent
183 years. The GOST signing algorithm [GOST-SIGN] was also adopted but
184 has seen very limited use, likely because it is a national algorithm
185 specific to a very small number of countries.
186
187 Implementation developers who want to know which algorithms to
188 implement in DNSSEC software should refer to [RFC8624]. Note that
189 this specification is only about what algorithms should and should
190 not be included in implementations, i.e., it is not advice about
191 which algorithms zone operators should or should not use for signing,
192 nor which algorithms recursive resolver operators should or should
193 not use for validation.
194
195 4. Extensions to DNSSEC
196
197 The DNSSEC community has extended the DNSSEC core and the
198 cryptographic algorithms, both in terms of describing good
199 operational practices and in new protocols. Some of the RFCs that
200 describe these extensions include the following:
201
202 * [RFC5011] describes a method to help resolvers update their DNSSEC
203 trust anchors in an automated fashion. This method was used in
204 2018 to update the DNS root trust anchor.
205
206 * [RFC6781] is a compendium of operational practices that may not be
207 obvious from reading just the core specifications.
208
209 * [RFC7344] describes using the CDS and CDNSKEY resource records to
210 help automate the maintenance of DS records in the parents of
211 signed zones.
212
213 * [RFC8078] extends [RFC7344] by showing how to do initial setup of
214 trusted relationships between signed parent and child zones.
215
216 * [RFC8198] describes how a validating resolver can emit fewer
217 queries in signed zones that use NSEC and NSEC3 for negative
218 caching.
219
220 * [RFC9077] updates [RFC8198] with respect to the TTL fields in
221 signed records.
222
223 5. Additional Documents of Interest
224
225 The documents listed above constitute the core of DNSSEC, the
226 additional cryptographic algorithms, and the major extensions to
227 DNSSEC. This section lists some additional documents that someone
228 interested in implementing or operating DNSSEC might find of value:
229
230 * [RFC4470] "describes how to construct DNSSEC NSEC resource records
231 that cover a smaller range of names than called for by [RFC4034].
232 By generating and signing these records on demand, authoritative
233 name servers can effectively stop the disclosure of zone contents
234 otherwise made possible by walking the chain of NSEC records in a
235 signed zone".
236
237 * [RFC6975] "specifies a way for validating end-system resolvers to
238 signal to a server which digital signature and hash algorithms
239 they support".
240
241 * [RFC7129] "provides additional background commentary and some
242 context for the NSEC and NSEC3 mechanisms used by DNSSEC to
243 provide authenticated denial-of-existence responses". This
244 background is particularly important for understanding NSEC and
245 NSEC3 usage.
246
247 * [RFC7583] "describes the issues surrounding the timing of events
248 in the rolling of a key in a DNSSEC-secured zone".
249
250 * [RFC7646] "defines Negative Trust Anchors (NTAs), which can be
251 used to mitigate DNSSEC validation failures by disabling DNSSEC
252 validation at specified domains".
253
254 * [RFC7958] "describes the format and publication mechanisms IANA
255 has used to distribute the DNSSEC trust anchors".
256
257 * [RFC8027] "describes problems that a Validating DNS resolver,
258 stub-resolver, or application might run into within a non-
259 compliant infrastructure".
260
261 * [RFC8145] "specifies two different ways for validating resolvers
262 to signal to a server which keys are referenced in their chain of
263 trust".
264
265 * [RFC8499] contains lists of terminology used when talking about
266 DNS; Sections 10 and 11 cover DNSSEC.
267
268 * [RFC8509] "specifies a mechanism that will allow an end user and
269 third parties to determine the trusted key state for the root key
270 of the resolvers that handle that user's DNS queries".
271
272 * [RFC8901] "presents deployment models that accommodate this
273 scenario [when each DNS provider independently signs zone data
274 with their own keys] and describes these key-management
275 requirements".
276
277 * [RFC9276] "provides guidance on setting NSEC3 parameters based on
278 recent operational deployment experience".
279
280 There will certainly be other RFCs related to DNSSEC that are
281 published after this one.
282
283 6. IANA Considerations
284
285 IANA already has three registry groups that relate to DNSSEC:
286
287 * DNSSEC algorithm numbers (https://www.iana.org/assignments/dns-
288 sec-alg-numbers)
289
290 * DNSSEC NSEC3 parameters (https://www.iana.org/assignments/dnssec-
291 nsec3-parameters)
292
293 * DNSSEC DS RRtype digest algorithms
294 (https://www.iana.org/assignments/ds-rr-types)
295
296 The rules for the DNSSEC algorithm registry were set in the core RFCs
297 and updated by [RFC6014], [RFC6725], and [RFC9157].
298
299 This document does not update or create any registry groups or
300 registries.
301
302 7. Security Considerations
303
304 All of the security considerations from all of the RFCs referenced in
305 this document apply here.
306
307 8. References
308
309 8.1. Normative References
310
311 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
312 Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110,
313 May 2001, <https://www.rfc-editor.org/info/rfc3110>.
314
315 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
316 Rose, "DNS Security Introduction and Requirements",
317 RFC 4033, DOI 10.17487/RFC4033, March 2005,
318 <https://www.rfc-editor.org/info/rfc4033>.
319
320 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
321 Rose, "Resource Records for the DNS Security Extensions",
322 RFC 4034, DOI 10.17487/RFC4034, March 2005,
323 <https://www.rfc-editor.org/info/rfc4034>.
324
325 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
326 Rose, "Protocol Modifications for the DNS Security
327 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
328 <https://www.rfc-editor.org/info/rfc4035>.
329
330 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
331 (DS) Resource Records (RRs)", RFC 4509,
332 DOI 10.17487/RFC4509, May 2006,
333 <https://www.rfc-editor.org/info/rfc4509>.
334
335 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
336 Security (DNSSEC) Hashed Authenticated Denial of
337 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
338 <https://www.rfc-editor.org/info/rfc5155>.
339
340 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
341 and RRSIG Resource Records for DNSSEC", RFC 5702,
342 DOI 10.17487/RFC5702, October 2009,
343 <https://www.rfc-editor.org/info/rfc5702>.
344
345 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
346 Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
347 DOI 10.17487/RFC6840, February 2013,
348 <https://www.rfc-editor.org/info/rfc6840>.
349
350 8.2. Informative References
351
352 [GOST-SIGN]
353 Belyavsky, D., Dolmatov, V., Ed., and B. Makarenko, Ed.,
354 "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG
355 Resource Records for DNSSEC", Work in Progress, Internet-
356 Draft, draft-ietf-dnsop-rfc5933-bis-13, 30 November 2022,
357 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
358 rfc5933-bis-13>.
359
360 [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System
361 Security Extensions", RFC 2065, DOI 10.17487/RFC2065,
362 January 1997, <https://www.rfc-editor.org/info/rfc2065>.
363
364 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
365 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
366 <https://www.rfc-editor.org/info/rfc2535>.
367
368 [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
369 System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999,
370 <https://www.rfc-editor.org/info/rfc2536>.
371
372 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
373 and DNSSEC On-line Signing", RFC 4470,
374 DOI 10.17487/RFC4470, April 2006,
375 <https://www.rfc-editor.org/info/rfc4470>.
376
377 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
378 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
379 September 2007, <https://www.rfc-editor.org/info/rfc5011>.
380
381 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
382 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
383 November 2010, <https://www.rfc-editor.org/info/rfc6014>.
384
385 [RFC6605] Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital
386 Signature Algorithm (DSA) for DNSSEC", RFC 6605,
387 DOI 10.17487/RFC6605, April 2012,
388 <https://www.rfc-editor.org/info/rfc6605>.
389
390 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
391 of Named Entities (DANE) Transport Layer Security (TLS)
392 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
393 2012, <https://www.rfc-editor.org/info/rfc6698>.
394
395 [RFC6725] Rose, S., "DNS Security (DNSSEC) DNSKEY Algorithm IANA
396 Registry Updates", RFC 6725, DOI 10.17487/RFC6725, August
397 2012, <https://www.rfc-editor.org/info/rfc6725>.
398
399 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
400 Operational Practices, Version 2", RFC 6781,
401 DOI 10.17487/RFC6781, December 2012,
402 <https://www.rfc-editor.org/info/rfc6781>.
403
404 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic
405 Algorithm Understanding in DNS Security Extensions
406 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
407 <https://www.rfc-editor.org/info/rfc6975>.
408
409 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
410 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
411 February 2014, <https://www.rfc-editor.org/info/rfc7129>.
412
413 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
414 DNSSEC Delegation Trust Maintenance", RFC 7344,
415 DOI 10.17487/RFC7344, September 2014,
416 <https://www.rfc-editor.org/info/rfc7344>.
417
418 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
419 "DNSSEC Key Rollover Timing Considerations", RFC 7583,
420 DOI 10.17487/RFC7583, October 2015,
421 <https://www.rfc-editor.org/info/rfc7583>.
422
423 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
424 and R. Weber, "Definition and Use of DNSSEC Negative Trust
425 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
426 <https://www.rfc-editor.org/info/rfc7646>.
427
428 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,
429 "DNSSEC Trust Anchor Publication for the Root Zone",
430 RFC 7958, DOI 10.17487/RFC7958, August 2016,
431 <https://www.rfc-editor.org/info/rfc7958>.
432
433 [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
434 "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
435 DOI 10.17487/RFC8027, November 2016,
436 <https://www.rfc-editor.org/info/rfc8027>.
437
438 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
439 the Parent via CDS/CDNSKEY", RFC 8078,
440 DOI 10.17487/RFC8078, March 2017,
441 <https://www.rfc-editor.org/info/rfc8078>.
442
443 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
444 Algorithm (EdDSA) for DNSSEC", RFC 8080,
445 DOI 10.17487/RFC8080, February 2017,
446 <https://www.rfc-editor.org/info/rfc8080>.
447
448 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
449 Anchor Knowledge in DNS Security Extensions (DNSSEC)",
450 RFC 8145, DOI 10.17487/RFC8145, April 2017,
451 <https://www.rfc-editor.org/info/rfc8145>.
452
453 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
454 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
455 July 2017, <https://www.rfc-editor.org/info/rfc8198>.
456
457 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
458 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
459 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
460
461 [RFC8509] Huston, G., Damas, J., and W. Kumari, "A Root Key Trust
462 Anchor Sentinel for DNSSEC", RFC 8509,
463 DOI 10.17487/RFC8509, December 2018,
464 <https://www.rfc-editor.org/info/rfc8509>.
465
466 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
467 Requirements and Usage Guidance for DNSSEC", RFC 8624,
468 DOI 10.17487/RFC8624, June 2019,
469 <https://www.rfc-editor.org/info/rfc8624>.
470
471 [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
472 Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
473 DOI 10.17487/RFC8901, September 2020,
474 <https://www.rfc-editor.org/info/rfc8901>.
475
476 [RFC9077] van Dijk, P., "NSEC and NSEC3: TTLs and Aggressive Use",
477 RFC 9077, DOI 10.17487/RFC9077, July 2021,
478 <https://www.rfc-editor.org/info/rfc9077>.
479
480 [RFC9157] Hoffman, P., "Revised IANA Considerations for DNSSEC",
481 RFC 9157, DOI 10.17487/RFC9157, December 2021,
482 <https://www.rfc-editor.org/info/rfc9157>.
483
484 [RFC9276] Hardaker, W. and V. Dukhovni, "Guidance for NSEC3
485 Parameter Settings", BCP 236, RFC 9276,
486 DOI 10.17487/RFC9276, August 2022,
487 <https://www.rfc-editor.org/info/rfc9276>.
488
489 Acknowledgements
490
491 The DNS world owes a depth of gratitude to the authors and other
492 contributors to the core DNSSEC documents and to the notable DNSSEC
493 extensions.
494
495 In addition, the following people made significant contributions to
496 early draft versions of this document: Ben Schwartz and Duane
497 Wessels.
498
499 Author's Address
500
501 Paul Hoffman
502 ICANN
503 Email: paul.hoffman@icann.org
504
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.