1 Internet Engineering Task Force (IETF) O. Kolkman
2 Request for Comments: 6781 W. Mekking
3 Obsoletes: 4641 NLnet Labs
4 Category: Informational R. Gieben
5 ISSN: 2070-1721 SIDN Labs
6 December 2012
7
8
9 DNSSEC Operational Practices, Version 2
10
11 Abstract
12
13 This document describes a set of practices for operating the DNS with
14 security extensions (DNSSEC). The target audience is zone
15 administrators deploying DNSSEC.
16
17 The document discusses operational aspects of using keys and
18 signatures in the DNS. It discusses issues of key generation, key
19 storage, signature generation, key rollover, and related policies.
20
21 This document obsoletes RFC 4641, as it covers more operational
22 ground and gives more up-to-date requirements with respect to key
23 sizes and the DNSSEC operations.
24
25 Status of This Memo
26
27 This document is not an Internet Standards Track specification; it is
28 published for informational purposes.
29
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Not all documents
34 approved by the IESG are a candidate for any level of Internet
35 Standard; see Section 2 of RFC 5741.
36
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 http://www.rfc-editor.org/info/rfc6781.
40
41
42
43
44
45
46
47
48
49
50
51
52 Kolkman, et al. Informational [Page 1]
53 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
54
55
56 Copyright Notice
57
58 Copyright (c) 2012 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
82
83 Table of Contents
84
85 1. Introduction ....................................................4
86 1.1. The Use of the Term 'key' ..................................5
87 1.2. Time Definitions ...........................................6
88 2. Keeping the Chain of Trust Intact ...............................6
89 3. Key Generation and Storage ......................................7
90 3.1. Operational Motivation for Zone Signing Keys and
91 Key Signing Keys ...........................................8
92 3.2. Practical Consequences of KSK and ZSK Separation ..........10
93 3.2.1. Rolling a KSK That Is Not a Trust Anchor ...........10
94 3.2.2. Rolling a KSK That Is a Trust Anchor ...............11
95 3.2.3. The Use of the SEP Flag ............................12
96 3.3. Key Effectivity Period ....................................12
97 3.4. Cryptographic Considerations ..............................14
98 3.4.1. Signature Algorithm ................................14
99 3.4.2. Key Sizes ..........................................14
100 3.4.3. Private Key Storage ................................16
101 3.4.4. Key Generation .....................................17
102 3.4.5. Differentiation for 'High-Level' Zones? ............17
103
104
105
106
107 Kolkman, et al. Informational [Page 2]
108 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
109
110
111 4. Signature Generation, Key Rollover, and Related Policies .......18
112 4.1. Key Rollovers .............................................18
113 4.1.1. Zone Signing Key Rollovers .........................18
114 4.1.1.1. Pre-Publish Zone Signing Key Rollover .....19
115 4.1.1.2. Double-Signature Zone Signing Key Rollover 21
116 4.1.1.3. Pros and Cons of the Schemes ..............23
117 4.1.2. Key Signing Key Rollovers ..........................23
118 4.1.2.1. Special Considerations for RFC 5011
119 KSK Rollover ..............................26
120 4.1.3. Single-Type Signing Scheme Key Rollover ............26
121 4.1.4. Algorithm Rollovers ................................28
122 4.1.4.1. Single-Type Signing Scheme
123 Algorithm Rollover ........................32
124 4.1.4.2. Algorithm Rollover, RFC 5011 Style ........32
125 4.1.4.3. Single Signing Type Algorithm
126 Rollover, RFC 5011 Style ..................33
127 4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover ..........34
128 4.1.5. Considerations for Automated Key Rollovers .........34
129 4.2. Planning for Emergency Key Rollover .......................35
130 4.2.1. KSK Compromise .....................................35
131 4.2.1.1. Emergency Key Rollover Keeping the
132 Chain of Trust Intact .....................36
133 4.2.1.2. Emergency Key Rollover Breaking
134 the Chain of Trust ........................37
135 4.2.2. ZSK Compromise .....................................37
136 4.2.3. Compromises of Keys Anchored in Resolvers ..........38
137 4.2.4. Stand-By Keys ......................................38
138 4.3. Parent Policies ...........................................39
139 4.3.1. Initial Key Exchanges and Parental Policies
140 Considerations .....................................39
141 4.3.2. Storing Keys or Hashes? ............................40
142 4.3.3. Security Lameness ..................................40
143 4.3.4. DS Signature Validity Period .......................41
144 4.3.5. Changing DNS Operators .............................42
145 4.3.5.1. Cooperating DNS Operators .................42
146 4.3.5.2. Non-Cooperating DNS Operators .............44
147 4.4. Time in DNSSEC ............................................46
148 4.4.1. Time Considerations ................................46
149 4.4.2. Signature Validity Periods .........................48
150 4.4.2.1. Maximum Value .............................48
151 4.4.2.2. Minimum Value .............................49
152 4.4.2.3. Differentiation between RRsets ............50
153
154
155
156
157
158
159
160
161
162 Kolkman, et al. Informational [Page 3]
163 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
164
165
166 5. "Next Record" Types ............................................51
167 5.1. Differences between NSEC and NSEC3 ........................51
168 5.2. NSEC or NSEC3 .............................................52
169 5.3. NSEC3 Parameters ..........................................53
170 5.3.1. NSEC3 Algorithm ....................................53
171 5.3.2. NSEC3 Iterations ...................................53
172 5.3.3. NSEC3 Salt .........................................54
173 5.3.4. Opt-Out ............................................54
174 6. Security Considerations ........................................54
175 7. Acknowledgments ................................................55
176 8. Contributors ...................................................55
177 9. References .....................................................56
178 9.1. Normative References ......................................56
179 9.2. Informative References ....................................56
180 Appendix A. Terminology ...........................................59
181 Appendix B. Typographic Conventions ...............................61
182 Appendix C. Transition Figures for Special Cases of Algorithm
183 Rollovers .............................................64
184 Appendix D. Transition Figure for Changing DNS Operators ..........68
185 Appendix E. Summary of Changes from RFC 4641 ......................70
186
187 1. Introduction
188
189 This document describes how to run a DNS Security (DNSSEC)-enabled
190 environment. It is intended for operators who have knowledge of the
191 DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to
192 deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035
193 [RFC4035], and RFC 5155 [RFC5155]). The focus of the document is on
194 serving authoritative DNS information and is aimed at zone owners,
195 name server operators, registries, registrars, and registrants. It
196 assumes that there is no direct relationship between those entities
197 and the operators of validating recursive name servers (validators).
198
199 During workshops and early operational deployment, operators and
200 system administrators have gained experience about operating the DNS
201 with security extensions (DNSSEC). This document translates these
202 experiences into a set of practices for zone administrators.
203 Although the DNS Root has been signed since July 15, 2010 and now
204 more than 80 secure delegations are provisioned in the root, at the
205 time of this writing there still exists relatively little experience
206 with DNSSEC in production environments below the Top-Level Domain
207 (TLD) level; this document should therefore explicitly not be seen as
208 representing 'Best Current Practices'. Instead, it describes the
209 decisions that should be made when deploying DNSSEC, gives the
210 choices available for each one, and provides some operational
211 guidelines. The document does not give strong recommendations. That
212 may be the subject for a future version of this document.
213
214
215
216
217 Kolkman, et al. Informational [Page 4]
218 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
219
220
221 The procedures herein are focused on the maintenance of signed zones
222 (i.e., signing and publishing zones on authoritative servers). It is
223 intended that maintenance of zones, such as re-signing or key
224 rollovers, be transparent to any verifying clients.
225
226 The structure of this document is as follows. In Section 2, we
227 discuss the importance of keeping the "chain of trust" intact.
228 Aspects of key generation and storage of keys are discussed in
229 Section 3; the focus in this section is mainly on the security of the
230 private part of the key(s). Section 4 describes considerations
231 concerning the public part of the keys. Sections 4.1 and 4.2 deal
232 with the rollover, or replacement, of keys. Section 4.3 discusses
233 considerations on how parents deal with their children's public keys
234 in order to maintain chains of trust. Section 4.4 covers all kinds
235 of timing issues around key publication. Section 5 covers the
236 considerations regarding selecting and using the NSEC or NSEC3
237 [RFC5155] Resource Record.
238
239 The typographic conventions used in this document are explained in
240 Appendix B.
241
242 Since we describe operational suggestions and there are no protocol
243 specifications, the RFC 2119 [RFC2119] language does not apply to
244 this document, though we do use quotes from other documents that do
245 include the RFC 2119 language.
246
247 This document obsoletes RFC 4641 [RFC4641].
248
249 1.1. The Use of the Term 'key'
250
251 It is assumed that the reader is familiar with the concept of
252 asymmetric cryptography, or public-key cryptography, on which DNSSEC
253 is based (see the definition of 'asymmetric cryptography' in RFC 4949
254 [RFC4949]). Therefore, this document will use the term 'key' rather
255 loosely. Where it is written that 'a key is used to sign data', it
256 is assumed that the reader understands that it is the private part of
257 the key pair that is used for signing. It is also assumed that the
258 reader understands that the public part of the key pair is published
259 in the DNSKEY Resource Record (DNSKEY RR) and that it is the public
260 part that is used in signature verification.
261
262
263
264
265
266
267
268
269
270
271
272 Kolkman, et al. Informational [Page 5]
273 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
274
275
276 1.2. Time Definitions
277
278 In this document, we will be using a number of time-related terms.
279 The following definitions apply:
280
281 Signature validity period: The period that a signature is valid. It
282 starts at the (absolute) time specified in the signature inception
283 field of the RRSIG RR and ends at the (absolute) time specified in
284 the expiration field of the RRSIG RR. The document sometimes also
285 uses the term 'validity period', which means the same.
286
287 Signature publication period: The period that a signature is
288 published. It starts at the time the signature is introduced in
289 the zone for the first time and ends at the time when the
290 signature is removed or replaced with a new signature. After one
291 stops publishing an RRSIG in a zone, it may take a while before
292 the RRSIG has expired from caches and has actually been removed
293 from the DNS.
294
295 Key effectivity period: The period during which a key pair is
296 expected to be effective. It is defined as the time between the
297 earliest inception time stamp and the last expiration date of any
298 signature made with this key, regardless of any discontinuity in
299 the use of the key. The key effectivity period can span multiple
300 signature validity periods.
301
302 Maximum/Minimum Zone Time to Live (TTL): The maximum or minimum
303 value of the TTLs from the complete set of RRs in a zone, that are
304 used by validators or resolvers. Note that the minimum TTL is not
305 the same as the MINIMUM field in the SOA RR. See RFC 2308
306 [RFC2308] for more information.
307
308 2. Keeping the Chain of Trust Intact
309
310 Maintaining a valid chain of trust is important because broken chains
311 of trust will result in data being marked as Bogus (as defined in
312 RFC 4033 [RFC4033] Section 5), which may cause entire (sub)domains to
313 become invisible to verifying clients. The administrators of secured
314 zones need to realize that, to verifying clients, their zone is part
315 of a chain of trust.
316
317 As mentioned in the introduction, the procedures herein are intended
318 to ensure that maintenance of zones, such as re-signing or key
319 rollovers, will be transparent to the verifying clients on the
320 Internet.
321
322
323
324
325
326
327 Kolkman, et al. Informational [Page 6]
328 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
329
330
331 Administrators of secured zones will need to keep in mind that data
332 published on an authoritative primary server will not be immediately
333 seen by verifying clients; it may take some time for the data to be
334 transferred to other (secondary) authoritative name servers and
335 clients may be fetching data from caching non-authoritative servers.
336 In this light, note that the time until the data is available on the
337 slave can be negligible when using NOTIFY [RFC1996] and Incremental
338 Zone Transfer (IXFR) [RFC1995]. It increases when Authoritative
339 (full) Zone Transfers (AXFRs) are used in combination with NOTIFY.
340 It increases even more if you rely on the full zone transfers being
341 based only on the SOA timing parameters for refresh.
342
343 For the verifying clients, it is important that data from secured
344 zones can be used to build chains of trust, regardless of whether the
345 data came directly from an authoritative server, a caching name
346 server, or some middle box. Only by carefully using the available
347 timing parameters can a zone administrator ensure that the data
348 necessary for verification can be obtained.
349
350 The responsibility for maintaining the chain of trust is shared by
351 administrators of secured zones in the chain of trust. This is most
352 obvious in the case of a 'key compromise' when a tradeoff must be
353 made between maintaining a valid chain of trust and replacing the
354 compromised keys as soon as possible. Then zone administrators will
355 have to decide between keeping the chain of trust intact -- thereby
356 allowing for attacks with the compromised key -- or deliberately
357 breaking the chain of trust and making secured subdomains invisible
358 to security-aware resolvers (also see Section 4.2).
359
360 3. Key Generation and Storage
361
362 This section describes a number of considerations with respect to the
363 use of keys. For the design of an operational procedure for key
364 generation and storage, a number of decisions need to be made:
365
366 o Does one differentiate between Zone Signing Keys and Key Signing
367 Keys or is the use of one type of key sufficient?
368
369 o Are Key Signing Keys (likely to be) in use as trust anchors
370 [RFC4033]?
371
372 o What are the timing parameters that are allowed by the operational
373 requirements?
374
375 o What are the cryptographic parameters that fit the operational
376 need?
377
378
379
380
381
382 Kolkman, et al. Informational [Page 7]
383 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
384
385
386 The following section discusses the considerations that need to be
387 taken into account when making those choices.
388
389 3.1. Operational Motivation for Zone Signing Keys and Key Signing Keys
390
391 The DNSSEC validation protocol does not distinguish between different
392 types of DNSKEYs. The motivations to differentiate between keys are
393 purely operational; validators will not make a distinction.
394
395 For operational reasons, described below, it is possible to designate
396 one or more keys to have the role of Key Signing Keys (KSKs). These
397 keys will only sign the apex DNSKEY RRset in a zone. Other keys can
398 be used to sign all the other RRsets in a zone that require
399 signatures. They are referred to as Zone Signing Keys (ZSKs). In
400 cases where the differentiation between the KSK and ZSK is not made,
401 i.e., where keys have the role of both KSK and ZSK, we talk about a
402 Single-Type Signing Scheme.
403
404 If the two functions are separated, then for almost any method of key
405 management and zone signing, the KSK is used less frequently than the
406 ZSK. Once a DNSKEY RRset is signed with the KSK, all the keys in the
407 RRset can be used as ZSKs. If there has been an event that increases
408 the risk that a ZSK is compromised, it can be simply replaced with a
409 ZSK rollover. The new RRset is then re-signed with the KSK.
410
411 Changing a key that is a Secure Entry Point (SEP) [RFC4034] for a
412 zone can be relatively expensive, as it involves interaction with
413 third parties: When a key is only pointed to by a Delegation Signer
414 (DS) [RFC4034] record in the parent zone, one needs to complete the
415 interaction with the parent and wait for the updated DS record to
416 appear in the DNS. In the case where a key is configured as a trust
417 anchor, one has to wait until one has sufficient confidence that all
418 trust anchors have been replaced. In fact, it may be that one is not
419 able to reach the complete user-base with information about the key
420 rollover.
421
422 Given the assumption that for KSKs the SEP flag is set, the KSK can
423 be distinguished from a ZSK by examining the flag field in the DNSKEY
424 RR: If the flag field is an odd number, it is a KSK; otherwise, it is
425 a ZSK.
426
427 There is also a risk that keys can be compromised through theft or
428 loss. For keys that are installed on file-systems of name servers
429 that are connected to the network (e.g., for dynamic updates), that
430 risk is relatively high. Where keys are stored on Hardware Security
431 Modules (HSMs) or stored off-line, such risk is relatively low.
432 However, storing keys off-line or with more limitations on access
433 control has a negative effect on the operational flexibility. By
434
435
436
437 Kolkman, et al. Informational [Page 8]
438 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
439
440
441 separating the KSK and ZSK functionality, these risks can be managed
442 while making the tradeoff against the involved costs. For example, a
443 KSK can be stored off-line or with more limitations on access control
444 than ZSKs, which need to be readily available for operational
445 purposes such as the addition or deletion of zone data. A KSK stored
446 on a smartcard that is kept in a safe, combined with a ZSK stored on
447 a file-system accessible by operators for daily routine use, may
448 provide better protection against key compromise without losing much
449 operational flexibility. It must be said that some HSMs give the
450 option to have your keys online, giving more protection and hardly
451 affecting the operational flexibility. In those cases, a KSK-ZSK
452 split is not more beneficial than the Single-Type Signing Scheme.
453
454 It is worth mentioning that there's not much point in obsessively
455 protecting the key if you don't protect the zone files, which also
456 live on the file-systems.
457
458 Finally, there is a risk of cryptanalysis of the key material. The
459 costs of such analysis are correlated to the length of the key.
460 However, cryptanalysis arguments provide no strong motivation for a
461 KSK/ZSK split. Suppose one differentiates between a KSK and a ZSK,
462 whereby the KSK effectivity period is X times the ZSK effectivity
463 period. Then, in order for the resistance to cryptanalysis to be the
464 same for the KSK and the ZSK, the KSK needs to be X times stronger
465 than the ZSK. Since for all practical purposes X will be somewhere
466 on the order of 10 to 100, the associated key sizes will vary only by
467 about a byte in size for symmetric keys. When translated to
468 asymmetric keys, the size difference is still too insignificant to
469 warrant a key-split; it only marginally affects the packet size and
470 signing speed.
471
472 The arguments for differentiation between the ZSK and KSK are weakest
473 when:
474
475 o the exposure to risk is low (e.g., when keys are stored on HSMs);
476
477 o one can be certain that a key is not used as a trust anchor;
478
479 o maintenance of the various keys cannot be performed through tools
480 (is prone to human error); and
481
482 o the interaction through the child-parent provisioning chain -- in
483 particular, the timely appearance of a new DS record in the parent
484 zone in emergency situations -- is predictable.
485
486
487
488
489
490
491
492 Kolkman, et al. Informational [Page 9]
493 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
494
495
496 If the above arguments hold, then the costs of the operational
497 complexity of a KSK-ZSK split may outweigh the costs of operational
498 flexibility, and choosing a Single-Type Signing Scheme is a
499 reasonable option. In other cases, we advise that the separation
500 between KSKs and ZSKs is made.
501
502 3.2. Practical Consequences of KSK and ZSK Separation
503
504 A key that acts only as a Zone Signing Key is used to sign all the
505 data except the DNSKEY RRset in a zone on a regular basis. When a
506 ZSK is to be rolled, no interaction with the parent is needed. This
507 allows for a relatively short key effectivity period.
508
509 A key with only the Key Signing Key role is to be used to sign the
510 DNSKEY RRs in a zone. If a KSK is to be rolled, there may be
511 interactions with other parties. These can include the
512 administrators of the parent zone or administrators of verifying
513 resolvers that have the particular key configured as secure entry
514 points. In the latter case, everyone relying on the trust anchor
515 needs to roll over to the new key, a process that may be subject to
516 stability costs if automated trust anchor rollover mechanisms (e.g.,
517 RFC 5011 [RFC5011]) are not in place. Hence, the key effectivity
518 period of these keys can and should be made much longer.
519
520 3.2.1. Rolling a KSK That Is Not a Trust Anchor
521
522 There are three schools of thought on rolling a KSK that is not a
523 trust anchor:
524
525 1. It should be done frequently and regularly (possibly every few
526 months), so that a key rollover remains an operational routine.
527
528 2. It should be done frequently but irregularly. "Frequently" means
529 every few months, again based on the argument that a rollover is
530 a practiced and common operational routine; "irregular" means
531 with a large jitter, so that third parties do not start to rely
532 on the key and will not be tempted to configure it as a trust
533 anchor.
534
535 3. It should only be done when it is known or strongly suspected
536 that the key can be or has been compromised, or in conjunction
537 with operator change policies and procedures, like when a new
538 algorithm or key storage is required.
539
540 There is no widespread agreement on which of these three schools of
541 thought is better for different deployments of DNSSEC. There is a
542 stability cost every time a non-anchor KSK is rolled over, but it is
543 possibly low if the communication between the child and the parent is
544
545
546
547 Kolkman, et al. Informational [Page 10]
548 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
549
550
551 good. On the other hand, the only completely effective way to tell
552 if the communication is good is to test it periodically. Thus,
553 rolling a KSK with a parent is only done for two reasons: to test and
554 verify the rolling system to prepare for an emergency, and in the
555 case of (preventing) an actual emergency.
556
557 Finally, in most cases a zone administrator cannot be fully certain
558 that the zone's KSK is not in use as a trust anchor somewhere. While
559 the configuration of trust anchors is not the responsibility of the
560 zone administrator, there may be stability costs for the validator
561 administrator that (wrongfully) configured the trust anchor when the
562 zone administrator rolls a KSK.
563
564 3.2.2. Rolling a KSK That Is a Trust Anchor
565
566 The same operational concerns apply to the rollover of KSKs that are
567 used as trust anchors: If a trust anchor replacement is done
568 incorrectly, the entire domain that the trust anchor covers will
569 become Bogus until the trust anchor is corrected.
570
571 In a large number of cases, it will be safe to work from the
572 assumption that one's keys are not in use as trust anchors. If a
573 zone administrator publishes a DNSSEC signing policy and/or a DNSSEC
574 practice statement [DNSSEC-DPS], that policy or statement should be
575 explicit regarding whether or not the existence of trust anchors will
576 be taken into account. There may be cases where local policies
577 enforce the configuration of trust anchors on zones that are mission
578 critical (e.g., in enterprises where the trust anchor for the
579 enterprise domain is configured in the enterprise's validator). It
580 is expected that the zone administrators are aware of such
581 circumstances.
582
583 One can argue that because of the difficulty of getting all users of
584 a trust anchor to replace an old trust anchor with a new one, a KSK
585 that is a trust anchor should never be rolled unless it is known or
586 strongly suspected that the key has been compromised. In other
587 words, the costs of a KSK rollover are prohibitively high because
588 some users cannot be reached.
589
590 However, the "operational habit" argument also applies to trust
591 anchor reconfiguration at the clients' validators. If a short key
592 effectivity period is used and the trust anchor configuration has to
593 be revisited on a regular basis, the odds that the configuration
594 tends to be forgotten are smaller. In fact, the costs for those
595 users can be minimized by automating the rollover with RFC 5011
596 [RFC5011] and by rolling the key regularly (and advertising such) so
597
598
599
600
601
602 Kolkman, et al. Informational [Page 11]
603 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
604
605
606 that the operators of validating resolvers will put the appropriate
607 mechanism in place to deal with these stability costs: In other
608 words, budget for these costs instead of incurring them unexpectedly.
609
610 It is therefore preferable to roll KSKs that are expected to be used
611 as trust anchors on a regular basis if and only if those rollovers
612 can be tracked using standardized (e.g., RFC 5011 [RFC5011])
613 mechanisms.
614
615 3.2.3. The Use of the SEP Flag
616
617 The so-called SEP [RFC4035] flag can be used to distinguish between
618 keys that are intended to be used as the secure entry point into the
619 zone when building chains of trust, i.e., they are (to be) pointed to
620 by parental DS RRs or configured as a trust anchor.
621
622 While the SEP flag does not play any role in validation, it is used
623 in practice for operational purposes such as for the rollover
624 mechanism described in RFC 5011 [RFC5011]. The common convention is
625 to set the SEP flag on any key that is used for key exchanges with
626 the parent and/or potentially used for configuration as a trust
627 anchor. Therefore, it is suggested that the SEP flag be set on keys
628 that are used as KSKs and not on keys that are used as ZSKs, while in
629 those cases where a distinction between a KSK and ZSK is not made
630 (i.e., for a Single-Type Signing Scheme), it is suggested that the
631 SEP flag be set on all keys.
632
633 Note: Some signing tools may assume a KSK/ZSK split and use the
634 (non-)presence of the SEP flag to determine which key is to be used
635 for signing zone data; these tools may get confused when a Single-
636 Type Signing Scheme is used.
637
638 3.3. Key Effectivity Period
639
640 In general, the available key length sets an upper limit on the key
641 effectivity period. For all practical purposes, it is sufficient to
642 define the key effectivity period based on purely operational
643 requirements and match the key length to that value. Ignoring the
644 operational perspective, a reasonable effectivity period for KSKs
645 that have corresponding DS records in the parent zone is on the order
646 of two decades or longer. That is, if one does not plan to test the
647 rollover procedure, the key should be effective essentially forever
648 and only rolled over in case of emergency.
649
650 When one opts for a regular key rollover, a reasonable key
651 effectivity period for KSKs that have a parent zone is one year,
652 meaning you have the intent to replace them after 12 months. The key
653 effectivity period is merely a policy parameter and should not be
654
655
656
657 Kolkman, et al. Informational [Page 12]
658 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
659
660
661 considered a constant value. For example, the real key effectivity
662 period may be a little bit longer than 12 months, because not all
663 actions needed to complete the rollover could be finished in time.
664
665 As argued above, this annual rollover gives an operational practice
666 of rollovers for both the zone and validator administrators.
667 Besides, in most environments a year is a time span that is easily
668 planned and communicated.
669
670 Where keys are stored online and the exposure to various threats of
671 compromise is fairly high, an intended key effectivity period of a
672 month is reasonable for Zone Signing Keys.
673
674 Although very short key effectivity periods are theoretically
675 possible, when replacing keys one has to take into account the
676 rollover considerations discussed in Sections 4.1 and 4.4. Key
677 replacement endures for a couple of Maximum Zone TTLs, depending on
678 the rollover scenario. Therefore, a multiple of Maximum Zone TTL
679 durations is a reasonable lower limit on the key effectivity period.
680 Forcing a shorter key effectivity period will result in an
681 unnecessary and inconveniently large DNSKEY RRset published in the
682 zone.
683
684 The motivation for having the ZSK's effectivity period shorter than
685 the KSK's effectivity period is rooted in the operational
686 consideration that it is more likely that operators have more
687 frequent read access to the ZSK than to the KSK. Thus, in cases
688 where the ZSK cannot be afforded the same level of protection as the
689 KSK (such as when zone keys are kept online), and where the risk of
690 unauthorized disclosure of the ZSK's private key is not negligible
691 (e.g., when HSMs are not in use), the ZSK's effectivity period should
692 be kept shorter than the KSK's effectivity period.
693
694 In fact, if the risk of loss, theft, or other compromise is the same
695 for a ZSK and a KSK, there is little reason to choose different
696 effectivity periods for ZSKs and KSKs. And when the split between
697 ZSKs and KSKs is not made, the argument is redundant.
698
699 There are certainly cases in which the use of a Single-Type Signing
700 Scheme with a long key effectivity period is a good choice, for
701 example, where the costs and risks of compromise, and the costs and
702 risks involved with having to perform an emergency roll, are low.
703
704
705
706
707
708
709
710
711
712 Kolkman, et al. Informational [Page 13]
713 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
714
715
716 3.4. Cryptographic Considerations
717
718 3.4.1. Signature Algorithm
719
720 At the time of this writing, there are three types of signature
721 algorithms that can be used in DNSSEC: RSA, Digital Signature
722 Algorithm (DSA), and GOST. Proposals for other algorithms are in the
723 making. All three are fully specified in many freely available
724 documents and are widely considered to be patent-free. The creation
725 of signatures with RSA and DSA takes roughly the same time, but DSA
726 is about ten times slower for signature verification. Also note
727 that, in the context of DNSSEC, DSA is limited to a maximum of
728 1024-bit keys.
729
730 We suggest the use of RSA/SHA-256 as the preferred signature
731 algorithm and RSA/SHA-1 as an alternative. Both have advantages and
732 disadvantages. RSA/SHA-1 has been deployed for many years, while
733 RSA/SHA-256 has only begun to be deployed. On the other hand, it is
734 expected that if effective attacks on either algorithm appear, they
735 will appear for RSA/SHA-1 first. RSA/MD5 should not be considered
736 for use because RSA/MD5 will very likely be the first common-use
737 signature algorithm to be targeted for an effective attack.
738
739 At the time of publication, it is known that the SHA-1 hash has
740 cryptanalysis issues, and work is in progress to address them. The
741 use of public-key algorithms based on hashes stronger than SHA-1
742 (e.g., SHA-256) is recommended, if these algorithms are available in
743 implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]).
744
745 Also, at the time of publication, digital signature algorithms based
746 on Elliptic Curve (EC) Cryptography with DNSSEC (GOST [RFC5933],
747 Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605]) are
748 being standardized and implemented. The use of EC has benefits in
749 terms of size. On the other hand, one has to balance that against
750 the amount of validating resolver implementations that will not
751 recognize EC signatures and thus treat the zone as insecure. Beyond
752 the observation of this tradeoff, we will not discuss this further.
753
754 3.4.2. Key Sizes
755
756 This section assumes RSA keys, as suggested in the previous section.
757
758 DNSSEC signing keys should be large enough to avoid all known
759 cryptographic attacks during the effectivity period of the key. To
760 date, despite huge efforts, no one has broken a regular 1024-bit key;
761 in fact, the best completed attack is estimated to be the equivalent
762 of a 700-bit key. An attacker breaking a 1024-bit signing key would
763 need to expend phenomenal amounts of networked computing power in a
764
765
766
767 Kolkman, et al. Informational [Page 14]
768 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
769
770
771 way that would not be detected in order to break a single key.
772 Because of this, it is estimated that most zones can safely use
773 1024-bit keys for at least the next ten years. (A 1024-bit
774 asymmetric key has an approximate equivalent strength of a symmetric
775 80-bit key.)
776
777 Depending on local policy (e.g., owners of keys that are used as
778 extremely high value trust anchors, or non-anchor keys that may be
779 difficult to roll over), it may be advisable to use lengths longer
780 than 1024 bits. Typically, the next larger key size used is
781 2048 bits, which has the approximate equivalent strength of a
782 symmetric 112-bit key (RFC 3766 [RFC3766]). Signing and verifying
783 with a 2048-bit key takes longer than with a 1024-bit key. The
784 increase depends on software and hardware implementations, but public
785 operations (such as verification) are about four times slower, while
786 private operations (such as signing) are about eight times slower.
787
788 Another way to decide on the size of a key to use is to remember that
789 the effort it takes for an attacker to break a 1024-bit key is the
790 same, regardless of how the key is used. If an attacker has the
791 capability of breaking a 1024-bit DNSSEC key, he also has the
792 capability of breaking one of the many 1024-bit Transport Layer
793 Security (TLS) [RFC5246] trust anchor keys that are currently
794 installed in web browsers. If the value of a DNSSEC key is lower to
795 the attacker than the value of a TLS trust anchor, the attacker will
796 use the resources to attack the latter.
797
798 It is possible that there will be an unexpected improvement in the
799 ability for attackers to break keys and that such an attack would
800 make it feasible to break 1024-bit keys but not 2048-bit keys. If
801 such an improvement happens, it is likely that there will be a huge
802 amount of publicity, particularly because of the large number of
803 1024-bit TLS trust anchors built into popular web browsers. At that
804 time, all 1024-bit keys (both ones with parent zones and ones that
805 are trust anchors) can be rolled over and replaced with larger keys.
806
807 Earlier documents (including the previous version of this document)
808 urged the use of longer keys in situations where a particular key was
809 "heavily used". That advice may have been true 15 years ago, but it
810 is not true today when using RSA algorithms and keys of 1024 bits or
811 higher.
812
813
814
815
816
817
818
819
820
821
822 Kolkman, et al. Informational [Page 15]
823 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
824
825
826 3.4.3. Private Key Storage
827
828 It is preferred that, where possible, zone private keys and the zone
829 file master copy that is to be signed be kept and used in off-line,
830 non-network-connected, physically secure machines only.
831 Periodically, an application can be run to add authentication to a
832 zone by adding RRSIG and NSEC/NSEC3 RRs. Then the augmented file can
833 be transferred to the master.
834
835 When relying on dynamic update [RFC3007] or any other update
836 mechanism that runs at a regular interval to manage a signed zone, be
837 aware that at least one private key of the zone will have to reside
838 on the master server or reside on an HSM to which the server has
839 access. This key is only as secure as the amount of exposure the
840 server receives to unknown clients and on the level of security of
841 the host. Although not mandatory, one could administer a zone using
842 a "hidden master" scheme to minimize the risk. In this arrangement,
843 the master name server that processes the updates is unavailable to
844 general hosts on the Internet; it is not listed in the NS RRset. The
845 name servers in the NS RRset are able to receive zone updates through
846 IXFR, AXFR, or an out-of-band distribution mechanism, possibly in
847 combination with NOTIFY or another mechanism to trigger zone
848 replication.
849
850 The ideal situation is to have a one-way information flow to the
851 network to avoid the possibility of tampering from the network.
852 Keeping the zone master on-line on the network and simply cycling it
853 through an off-line signer does not do this. The on-line version
854 could still be tampered with if the host it resides on is
855 compromised. For maximum security, the master copy of the zone file
856 should be off-net and should not be updated based on an unsecured
857 network-mediated communication.
858
859 The ideal situation may not be achievable because of economic
860 tradeoffs between risks and costs. For instance, keeping a zone file
861 off-line is not practical and will increase the costs of operating a
862 DNS zone. So, in practice, the machines on which zone files are
863 maintained will be connected to a network. Operators are advised to
864 take security measures to shield the master copy against unauthorized
865 access in order to prevent modification of DNS data before it is
866 signed.
867
868
869
870
871
872
873
874
875
876
877 Kolkman, et al. Informational [Page 16]
878 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
879
880
881 Similarly, the choice for storing a private key in an HSM will be
882 influenced by a tradeoff between various concerns:
883
884 o The risks that an unauthorized person has unnoticed read access to
885 the private key.
886
887 o The remaining window of opportunity for the attacker.
888
889 o The economic impact of the possible attacks (for a TLD, that
890 impact will typically be higher than for an individual user).
891
892 o The costs of rolling the (compromised) keys. (The cost of rolling
893 a ZSK is lowest, and the cost of rolling a KSK that is in wide use
894 as a trust anchor is highest.)
895
896 o The costs of buying and maintaining an HSM.
897
898 For dynamically updated secured zones [RFC3007], both the master copy
899 and the private key that is used to update signatures on updated RRs
900 will need to be on-line.
901
902 3.4.4. Key Generation
903
904 Careful generation of all keys is a sometimes overlooked but
905 absolutely essential element in any cryptographically secure system.
906 The strongest algorithms used with the longest keys are still of no
907 use if an adversary can guess enough to lower the size of the likely
908 key space so that it can be exhaustively searched. Technical
909 suggestions for the generation of random keys will be found in
910 RFC 4086 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A]. In
911 particular, one should carefully assess whether the random number
912 generator used during key generation adheres to these suggestions.
913 Typically, HSMs tend to provide a good facility for key generation.
914
915 Keys with a long effectivity period are particularly sensitive, as
916 they will represent a more valuable target and be subject to attack
917 for a longer time than short-period keys. It is preferred that long-
918 term key generation occur off-line in a manner isolated from the
919 network via an air gap or, at a minimum, high-level secure hardware.
920
921 3.4.5. Differentiation for 'High-Level' Zones?
922
923 An earlier version of this document (RFC 4641 [RFC4641]) made a
924 differentiation between key lengths for KSKs used for zones that are
925 high in the DNS hierarchy and those for KSKs used lower down in the
926 hierarchy.
927
928
929
930
931
932 Kolkman, et al. Informational [Page 17]
933 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
934
935
936 This distinction is now considered irrelevant. Longer key lengths
937 for keys higher in the hierarchy are not useful because the
938 cryptographic guidance is that everyone should use keys that no one
939 can break. Also, it is impossible to judge which zones are more or
940 less valuable to an attacker. An attack can only take place if the
941 key compromise goes unnoticed and the attacker can act as a man-in-
942 the-middle (MITM). For example, if example.com is compromised, and
943 the attacker forges answers for somebank.example.com. and sends them
944 out during an MITM, when the attack is discovered it will be simple
945 to prove that example.com has been compromised, and the KSK will be
946 rolled.
947
948 4. Signature Generation, Key Rollover, and Related Policies
949
950 4.1. Key Rollovers
951
952 Regardless of whether a zone uses periodic key rollovers or only
953 rolls keys in case of an irregular event, key rollovers are a fact of
954 life when using DNSSEC. Zone administrators who are in the process
955 of rolling their keys have to take into account the fact that data
956 published in previous versions of their zone still lives in caches.
957 When deploying DNSSEC, this becomes an important consideration;
958 ignoring data that may be in caches may lead to loss of service for
959 clients.
960
961 The most pressing example of this occurs when zone material signed
962 with an old key is being validated by a resolver that does not have
963 the old zone key cached. If the old key is no longer present in the
964 current zone, this validation fails, marking the data Bogus.
965 Alternatively, an attempt could be made to validate data that is
966 signed with a new key against an old key that lives in a local cache,
967 also resulting in data being marked Bogus.
968
969 The typographic conventions used in the diagrams below are explained
970 in Appendix B.
971
972 4.1.1. Zone Signing Key Rollovers
973
974 If the choice for splitting ZSKs and KSKs has been made, then those
975 two types of keys can be rolled separately, and ZSKs can be rolled
976 without taking into account DS records from the parent or the
977 configuration of such a key as the trust anchor.
978
979 For "Zone Signing Key rollovers", there are two ways to make sure
980 that during the rollover data still cached can be verified with the
981 new key sets or newly generated signatures can be verified with the
982 keys still in caches. One scheme, described in Section 4.1.1.1, uses
983
984
985
986
987 Kolkman, et al. Informational [Page 18]
988 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
989
990
991 key pre-publication; the other uses double signatures, as described
992 in Section 4.1.1.2. The pros and cons are described in
993 Section 4.1.1.3.
994
995 4.1.1.1. Pre-Publish Zone Signing Key Rollover
996
997 This section shows how to perform a ZSK rollover without the need to
998 sign all the data in a zone twice -- the "Pre-Publish key rollover".
999 This method has advantages in the case of a key compromise. If the
1000 old key is compromised, the new key has already been distributed in
1001 the DNS. The zone administrator is then able to quickly switch to
1002 the new key and remove the compromised key from the zone. Another
1003 major advantage is that the zone size does not double, as is the case
1004 with the Double-Signature ZSK rollover.
1005
1006 Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves
1007 four stages as follows:
1008
1009 ------------------------------------------------------------
1010 initial new DNSKEY new RRSIGs
1011 ------------------------------------------------------------
1012 SOA_0 SOA_1 SOA_2
1013 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
1014
1015 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1016 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
1017 DNSKEY_Z_11 DNSKEY_Z_11
1018 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1019 ------------------------------------------------------------
1020
1021 ------------------------------------------------------------
1022 DNSKEY removal
1023 ------------------------------------------------------------
1024 SOA_3
1025 RRSIG_Z_11(SOA)
1026
1027 DNSKEY_K_1
1028 DNSKEY_Z_11
1029
1030 RRSIG_K_1(DNSKEY)
1031 ------------------------------------------------------------
1032
1033 Figure 1: Pre-Publish Key Rollover
1034
1035
1036
1037
1038
1039
1040
1041
1042 Kolkman, et al. Informational [Page 19]
1043 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1044
1045
1046 initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing
1047 Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e.,
1048 it is the Zone Signing Key.
1049
1050 new DNSKEY: DNSKEY_Z_11 is introduced into the key set (note that no
1051 signatures are generated with this key yet, but this does not
1052 secure against brute force attacks on its public key). The
1053 minimum duration of this pre-roll phase is the time it takes for
1054 the data to propagate to the authoritative servers, plus the TTL
1055 value of the key set.
1056
1057 new RRSIGs: At the "new RRSIGs" stage, DNSKEY_Z_11 is used to sign
1058 the data in the zone exclusively (i.e., all the signatures from
1059 DNSKEY_Z_10 are removed from the zone). DNSKEY_Z_10 remains
1060 published in the key set. This way, data that was loaded into
1061 caches from the zone in the "new DNSKEY" step can still be
1062 verified with key sets fetched from this version of the zone. The
1063 minimum time that the key set including DNSKEY_Z_10 is to be
1064 published is the time that it takes for zone data from the
1065 previous version of the zone to expire from old caches, i.e., the
1066 time it takes for this zone to propagate to all authoritative
1067 servers, plus the Maximum Zone TTL value of any of the data in the
1068 previous version of the zone.
1069
1070 DNSKEY removal: DNSKEY_Z_10 is removed from the zone. The key set,
1071 now only containing DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with
1072 DNSKEY_K_1.
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097 Kolkman, et al. Informational [Page 20]
1098 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1099
1100
1101 The above scheme can be simplified by always publishing the "future"
1102 key immediately after the rollover. The scheme would look as
1103 follows (we show two rollovers); the future key is introduced in "new
1104 DNSKEY" as DNSKEY_Z_12 and again a newer one, numbered 13, in "new
1105 DNSKEY (II)":
1106
1107 initial new RRSIGs new DNSKEY
1108 -----------------------------------------------------------------
1109 SOA_0 SOA_1 SOA_2
1110 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1111
1112 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1113 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11
1114 DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12
1115 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1116 ----------------------------------------------------------------
1117
1118 ----------------------------------------------------------------
1119 new RRSIGs (II) new DNSKEY (II)
1120 ----------------------------------------------------------------
1121 SOA_3 SOA_4
1122 RRSIG_Z_12(SOA) RRSIG_Z_12(SOA)
1123
1124 DNSKEY_K_1 DNSKEY_K_1
1125 DNSKEY_Z_11 DNSKEY_Z_12
1126 DNSKEY_Z_12 DNSKEY_Z_13
1127 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1128 ----------------------------------------------------------------
1129
1130 Figure 2: Pre-Publish Zone Signing Key Rollover,
1131 Showing Two Rollovers
1132
1133 Note that the key introduced in the "new DNSKEY" phase is not used
1134 for production yet; the private key can thus be stored in a
1135 physically secure manner and does not need to be 'fetched' every time
1136 a zone needs to be signed.
1137
1138 4.1.1.2. Double-Signature Zone Signing Key Rollover
1139
1140 This section shows how to perform a ZSK rollover using the double
1141 zone data signature scheme, aptly named "Double-Signature rollover".
1142
1143 During the "new DNSKEY" stage, the new version of the zone file will
1144 need to propagate to all authoritative servers and the data that
1145 exists in (distant) caches will need to expire, requiring at least
1146 the propagation delay plus the Maximum Zone TTL of previous versions
1147 of the zone.
1148
1149
1150
1151
1152 Kolkman, et al. Informational [Page 21]
1153 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1154
1155
1156 Double-Signature ZSK rollover involves three stages as follows:
1157
1158 ----------------------------------------------------------------
1159 initial new DNSKEY DNSKEY removal
1160 ----------------------------------------------------------------
1161 SOA_0 SOA_1 SOA_2
1162 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
1163 RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1164 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1165 DNSKEY_Z_10 DNSKEY_Z_10
1166 DNSKEY_Z_11 DNSKEY_Z_11
1167 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1168 ----------------------------------------------------------------
1169
1170 Figure 3: Double-Signature Zone Signing Key Rollover
1171
1172 initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing
1173 Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e.,
1174 it is the Zone Signing Key.
1175
1176 new DNSKEY: At the "new DNSKEY" stage, DNSKEY_Z_11 is introduced
1177 into the key set and all the data in the zone is signed with
1178 DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need to
1179 continue until all data from version 0 (i.e., the version of the
1180 zone data containing SOA_0) of the zone has been replaced in all
1181 secondary servers and then has expired from remote caches. This
1182 will take at least the propagation delay plus the Maximum Zone TTL
1183 of version 0 of the zone.
1184
1185 DNSKEY removal: DNSKEY_Z_10 is removed from the zone, as are all
1186 signatures created with it. The key set, now only containing
1187 DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11.
1188
1189 At every instance, RRSIGs from the previous version of the zone can
1190 be verified with the DNSKEY RRset from the current version and vice
1191 versa. The duration of the "new DNSKEY" phase and the period between
1192 rollovers should be at least the propagation delay to secondary
1193 servers plus the Maximum Zone TTL of the previous version of the
1194 zone.
1195
1196 Note that in this example we assumed for simplicity that the zone was
1197 not modified during the rollover. In fact, new data can be
1198 introduced at any time during this period, as long as it is signed
1199 with both keys.
1200
1201
1202
1203
1204
1205
1206
1207 Kolkman, et al. Informational [Page 22]
1208 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1209
1210
1211 4.1.1.3. Pros and Cons of the Schemes
1212
1213 Pre-Publish key rollover: This rollover does not involve signing the
1214 zone data twice. Instead, before the actual rollover, the new key
1215 is published in the key set and thus is available for
1216 cryptanalysis attacks. A small disadvantage is that this process
1217 requires four stages. Also, the Pre-Publish scheme involves more
1218 parental work when used for KSK rollovers, as explained in
1219 Section 4.1.2.
1220
1221 Double-Signature ZSK rollover: The drawback of this approach is that
1222 during the rollover the number of signatures in your zone doubles;
1223 this may be prohibitive if you have very big zones. An advantage
1224 is that it only requires three stages.
1225
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.
1226 4.1.2. Key Signing Key Rollovers
1227
1228 For the rollover of a Key Signing Key, the same considerations as for
1229 the rollover of a Zone Signing Key apply. However, we can use a
1230 Double-Signature scheme to guarantee that old data (only the apex key
1231 set) in caches can be verified with a new key set and vice versa.
1232 Since only the key set is signed with a KSK, zone size considerations
1233 do not apply.
1234
1235 Note that KSK rollovers and ZSK rollovers are different in the sense
1236 that a KSK rollover requires interaction with the parent (and
1237 possibly replacing trust anchors) and the ensuing delay while waiting
1238 for it.
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262 Kolkman, et al. Informational [Page 23]
1263 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1264
1265
1266 ---------------------------------------------------------------------
1267 initial new DNSKEY DS change DNSKEY removal
1268 ---------------------------------------------------------------------
1269 Parent:
1270 SOA_0 -----------------------------> SOA_1 ------------------------>
1271 RRSIG_par(SOA) --------------------> RRSIG_par(SOA) --------------->
1272 DS_K_1 ----------------------------> DS_K_2 ----------------------->
1273 RRSIG_par(DS) ---------------------> RRSIG_par(DS) ---------------->
1274
1275 Child:
1276 SOA_0 SOA_1 -----------------------> SOA_2
1277 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA)
1278
1279 DNSKEY_K_1 DNSKEY_K_1 ------------------>
1280 DNSKEY_K_2 ------------------> DNSKEY_K_2
1281 DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10
1282 RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ---------->
1283 RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY)
1284 ---------------------------------------------------------------------
1285
1286 Figure 4: Stages of Deployment for a Double-Signature
1287 Key Signing Key Rollover
1288
1289 initial: Initial version of the zone. The parental DS points to
1290 DNSKEY_K_1. Before the rollover starts, the child will have to
1291 verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
1292 it is needed during the rollover, and we refer to the value as
1293 TTL_DS.
1294
1295 new DNSKEY: During the "new DNSKEY" phase, the zone administrator
1296 generates a second KSK, DNSKEY_K_2. The key is provided to the
1297 parent, and the child will have to wait until a new DS RR has been
1298 generated that points to DNSKEY_K_2. After that DS RR has been
1299 published on all servers authoritative for the parent's zone, the
1300 zone administrator has to wait at least TTL_DS to make sure that
1301 the old DS RR has expired from caches.
1302
1303 DS change: The parent replaces DS_K_1 with DS_K_2.
1304
1305 DNSKEY removal: DNSKEY_K_1 has been removed.
1306
1307 The scenario above puts the responsibility for maintaining a valid
1308 chain of trust with the child. It also is based on the premise that
1309 the parent only has one DS RR (per algorithm) per zone. An
1310 alternative mechanism has been considered. Using an established
1311 trust relationship, the interaction can be performed in-band, and the
1312 removal of the keys by the child can possibly be signaled by the
1313 parent. In this mechanism, there are periods where there are two DS
1314
1315
1316
1317 Kolkman, et al. Informational [Page 24]
1318 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1319
1320
1321 RRs at the parent. This is known as a KSK Double-DS rollover and is
1322 shown in Figure 5. This method has some drawbacks for KSKs. We
1323 first describe the rollover scheme and then indicate these drawbacks.
1324
1325 --------------------------------------------------------------------
1326 initial new DS new DNSKEY DS removal
1327 --------------------------------------------------------------------
1328 Parent:
1329 SOA_0 SOA_1 ------------------------> SOA_2
1330 RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA)
1331 DS_K_1 DS_K_1 ----------------------->
1332 DS_K_2 -----------------------> DS_K_2
1333 RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS)
1334
1335 Child:
1336 SOA_0 -----------------------> SOA_1 ---------------------------->
1337 RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------>
1338
1339 DNSKEY_K_1 ------------------> DNSKEY_K_2 ----------------------->
1340 DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ---------------------->
1341 RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) --------------->
1342 --------------------------------------------------------------------
1343
1344 Figure 5: Stages of Deployment for a Double-DS
1345 Key Signing Key Rollover
1346
1347 When the child zone wants to roll, it notifies the parent during the
1348 "new DS" phase and submits the new key (or the corresponding DS) to
1349 the parent. The parent publishes DS_K_1 and DS_K_2, pointing to
1350 DNSKEY_K_1 and DNSKEY_K_2, respectively. During the rollover ("new
1351 DNSKEY" phase), which can take place as soon as the new DS set
1352 propagated through the DNS, the child replaces DNSKEY_K_1 with
1353 DNSKEY_K_2. If the old key has expired from caches, at the "DS
1354 removal" phase the parent can be notified that the old DS record can
1355 be deleted.
1356
1357 The drawbacks of this scheme are that during the "new DS" phase, the
1358 parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2
1359 using the DNS, as DNSKEY_K_2 is not yet published. Besides, we
1360 introduce a "security lame" key (see Section 4.3.3). Finally, the
1361 child-parent interaction consists of two steps. The "Double
1362 Signature" method only needs one interaction.
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372 Kolkman, et al. Informational [Page 25]
1373 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1374
1375
1376 4.1.2.1. Special Considerations for RFC 5011 KSK Rollover
1377
1378 The scenario sketched above assumes that the KSK is not in use as a
1379 trust anchor but that validating name servers exclusively depend on
1380 the parental DS record to establish the zone's security. If it is
1381 known that validating name servers have configured trust anchors,
1382 then that needs to be taken into account. Here, we assume that zone
1383 administrators will deploy RFC 5011 [RFC5011] style rollovers.
1384
1385 RFC 5011 style rollovers increase the duration of key rollovers: The
1386 key to be removed must first be revoked. Thus, before the DNSKEY_K_1
1387 removal phase, DNSKEY_K_1 must be published for one more Maximum Zone
1388 TTL with the REVOKE bit set. The revoked key must be self-signed, so
1389 in this phase the DNSKEY RRset must also be signed with DNSKEY_K_1.
1390
1391 4.1.3. Single-Type Signing Scheme Key Rollover
1392
1393 The rollover of a key when a Single-Type Signing Scheme is used is
1394 subject to the same requirement as the rollover of a KSK or ZSK:
1395 During any stage of the rollover, the chain of trust needs to
1396 continue to validate for any combination of data in the zone as well
1397 as data that may still live in distant caches.
1398
1399 There are two variants for this rollover. Since the choice for a
1400 Single-Type Signing Scheme is motivated by operational simplicity, we
1401 describe the most straightforward rollover scheme first.
1402
1403 -------------------------------------------------------------------
1404 initial new DNSKEY DS change DNSKEY removal
1405 -------------------------------------------------------------------
1406 Parent:
1407 SOA_0 --------------------------> SOA_1 ---------------------->
1408 RRSIG_par(SOA) -----------------> RRSIG_par(SOA) ------------->
1409 DS_S_1 -------------------------> DS_S_2 --------------------->
1410 RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ---------->
1411
1412 Child:
1413 SOA_0 SOA_1 ----------------------> SOA_2
1414 RRSIG_S_1(SOA) RRSIG_S_1(SOA) ------------->
1415 RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA)
1416 DNSKEY_S_1 DNSKEY_S_1 ----------------->
1417 DNSKEY_S_2 -----------------> DNSKEY_S_2
1418 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ---------->
1419 RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY)
1420 -------------------------------------------------------------------
1421
1422 Figure 6: Stages of the Straightforward Rollover
1423 in a Single-Type Signing Scheme
1424
1425
1426
1427 Kolkman, et al. Informational [Page 26]
1428 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1429
1430
1431 initial: Parental DS points to DNSKEY_S_1. All RRsets in the zone
1432 are signed with DNSKEY_S_1.
1433
1434 new DNSKEY: A new key (DNSKEY_S_2) is introduced, and all the RRsets
1435 are signed with both DNSKEY_S_1 and DNSKEY_S_2.
1436
1437 DS change: After the DNSKEY RRset with the two keys had time to
1438 propagate into distant caches (that is, the key set exclusively
1439 containing DNSKEY_S_1 has been expired), the parental DS record
1440 can be changed.
1441
1442 DNSKEY removal: After the DS RRset containing DS_S_1 has expired
1443 from distant caches, DNSKEY_S_1 can be removed from the DNSKEY
1444 RRset.
1445
1446 In this first variant, the new signatures and new public key are
1447 added to the zone. Once they are propagated, the DS at the parent is
1448 switched. If the old DS has expired from the caches, the old
1449 signatures and old public key can be removed from the zone.
1450
1451 This rollover has the drawback that it introduces double signatures
1452 over all data of the zone. Taking these zone size considerations
1453 into account, it is possible to not introduce the signatures made
1454 with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of
1455 DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an
1456 additional stage between the "DS change" and "DNSKEY removal" step:
1457 After the DS RRset containing DS_S_1 has expired from distant caches,
1458 the signatures can be swapped. Only after the new signatures made
1459 with DNSKEY_S_2 have been propagated can the old public key
1460 DNSKEY_S_1 be removed from the DNSKEY RRset.
1461
1462 The second variant of the Single-Type Signing Scheme Key rollover is
1463 the Double-DS rollover. In this variant, one introduces a new DNSKEY
1464 into the key set and submits the new DS to the parent. The new key
1465 is not yet used to sign RRsets. The signatures made with DNSKEY_S_1
1466 are replaced with signatures made with DNSKEY_S_2 at the moment that
1467 DNSKEY_S_2 and DS_S_2 have been propagated.
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482 Kolkman, et al. Informational [Page 27]
1483 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1484
1485
1486 -----------------------------------------------------------------------
1487 initial new DS new RRSIG DS removal
1488 -----------------------------------------------------------------------
1489 Parent:
1490 SOA_0 SOA_1 -------------------------> SOA_2
1491 RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA)
1492 DS_S_1 DS_S_1 ------------------------>
1493 DS_S_2 ------------------------> DS_S_2
1494 RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS)
1495
1496 Child:
1497 SOA_0 SOA_1 SOA_2 SOA_3
1498 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA)
1499
1500 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
1501 DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2
1502 RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
1503 -----------------------------------------------------------------------
1504
1505 Figure 7: Stages of Deployment for a Double-DS Rollover in a
1506 Single-Type Signing Scheme
1507
1508 4.1.4. Algorithm Rollovers
1509
1510 A special class of key rollovers is the one needed for a change of
1511 signature algorithms (either adding a new algorithm, removing an old
1512 algorithm, or both). Additional steps are needed to retain integrity
1513 during this rollover. We first describe the generic case; special
1514 considerations for rollovers that involve trust anchors and single-
1515 type keys are discussed later.
1516
1517 There exist both a conservative and a liberal approach for algorithm
1518 rollover. This has to do with Section 2.2 of RFC 4035 [RFC4035]:
1519
1520 There MUST be an RRSIG for each RRset using at least one DNSKEY
1521 of each algorithm in the zone apex DNSKEY RRset. The apex
1522 DNSKEY RRset itself MUST be signed by each algorithm appearing
1523 in the DS RRset located at the delegating parent (if any).
1524
1525 The conservative approach interprets this section very strictly,
1526 meaning that it expects that every RRset has a valid signature for
1527 every algorithm signaled by the zone apex DNSKEY RRset, including
1528 RRsets in caches. The liberal approach uses a more loose
1529 interpretation of the section and limits the rule to RRsets in the
1530 zone at the authoritative name servers. There is a reasonable
1531 argument for saying that this is valid, because the specific section
1532 is a subsection of Section 2 ("Zone Signing") of RFC 4035.
1533
1534
1535
1536
1537 Kolkman, et al. Informational [Page 28]
1538 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1539
1540
1541 When following the more liberal approach, algorithm rollover is just
1542 as easy as a regular Double-Signature KSK rollover (Section 4.1.2).
1543 Note that the Double-DS KSK rollover method cannot be used, since
1544 that would introduce a parental DS of which the apex DNSKEY RRset has
1545 not been signed with the introduced algorithm.
1546
1547 However, there are implementations of validators known to follow the
1548 more conservative approach. Performing a Double-Signature KSK
1549 algorithm rollover will temporarily make your zone appear as Bogus by
1550 such validators during the rollover. Therefore, the rollover
1551 described in this section will explain the stages of deployment and
1552 will assume that the conservative approach is used.
1553
1554 When adding a new algorithm, the signatures should be added first.
1555 After the TTL of RRSIGs has expired and caches have dropped the old
1556 data covered by those signatures, the DNSKEY with the new algorithm
1557 can be added.
1558
1559 After the new algorithm has been added, the DS record can be
1560 exchanged using Double-Signature KSK rollover.
1561
1562 When removing an old algorithm, the DS for the algorithm should be
1563 removed from the parent zone first, followed by the DNSKEY and the
1564 signatures (in the child zone).
1565
1566 Figure 8 describes the steps.
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592 Kolkman, et al. Informational [Page 29]
1593 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1594
1595
1596 ----------------------------------------------------------------
1597 initial new RRSIGs new DNSKEY
1598 ----------------------------------------------------------------
1599 Parent:
1600 SOA_0 -------------------------------------------------------->
1601 RRSIG_par(SOA) ----------------------------------------------->
1602 DS_K_1 ------------------------------------------------------->
1603 RRSIG_par(DS_K_1) -------------------------------------------->
1604
1605 Child:
1606 SOA_0 SOA_1 SOA_2
1607 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
1608 RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1609
1610 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1611 DNSKEY_K_2
1612 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
1613 DNSKEY_Z_11
1614 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1615 RRSIG_K_2(DNSKEY)
1616
initial: Initial version of the zone. The parental DS points to
DNSKEY_K_1. Before the rollover starts, the child will have to
verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
it is needed during the rollover, and we refer to the value as
TTL_DS.
new DNSKEY: During the "new DNSKEY" phase, the zone administrator
generates a second KSK, DNSKEY_K_2. The key is provided to the
parent, and the child will have to wait until a new DS RR has been
generated that points to DNSKEY_K_2. After that DS RR has been
published on all servers authoritative for the parent's zone, the
zone administrator has to wait at least TTL_DS to make sure that
the old DS RR has expired from caches.
DS change: The parent replaces DS_K_1 with DS_K_2.
initial: Initial version of the zone. The parental DS points to
DNSKEY_K_1. Before the rollover starts, the child will have to
verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
it is needed during the rollover, and we refer to the value as
TTL_DS. Also, we refer to the TTL value of the DNSKEY_K_1 RR as
TTL_DNSKEY.
new DNSKEY: During the "new DNSKEY" phase, the zone administrator
generates a second KSK, DNSKEY_K_2. The new DNSKEY RRSet that
includes DNSKEY_K_2 is published at the child. After waiting at
least TTL_DNSKEY, DNSKEY_K_2 (or the DS RR generated from it, that
is DS_K_2) is provided to the parent.
DS change: The parent replaces DS_K_1 with DS_K_2. After that DS RR
has been published on all servers authoritative for the parent's
zone, the zone administrator has to wait at least TTL_DS to make
sure that the old DS RR has expired from caches.
1617 ----------------------------------------------------------------
1618 new DS DNSKEY removal RRSIGs removal
1619 ----------------------------------------------------------------
1620 Parent:
1621 SOA_1 ------------------------------------------------------->
1622 RRSIG_par(SOA) ---------------------------------------------->
1623 DS_K_2 ------------------------------------------------------>
1624 RRSIG_par(DS_K_2) ------------------------------------------->
1625
1626 Child:
1627 -------------------> SOA_3 SOA_4
1628 -------------------> RRSIG_Z_10(SOA)
1629 -------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1630
1631 ------------------->
1632 -------------------> DNSKEY_K_2 DNSKEY_K_2
1633 ------------------->
1634 -------------------> DNSKEY_Z_11 DNSKEY_Z_11
1635 ------------------->
1636 -------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
1637 ----------------------------------------------------------------
1638
1639 Figure 8: Stages of Deployment during an Algorithm Rollover
1640
1641
1642
1643
1644
1645
1646
1647 Kolkman, et al. Informational [Page 30]
1648 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1649
1650
1651 initial: Describes the state of the zone before any transition is
1652 done. The number of the keys may vary, but all keys (in DNSKEY
1653 records) for the zone use the same algorithm.
1654
1655 new RRSIGs: The signatures made with the new key over all records in
1656 the zone are added, but the key itself is not. This step is
1657 needed to propagate the signatures created with the new algorithm
1658 to the caches. If this is not done, it is possible for a resolver
1659 to retrieve the new DNSKEY RRset (containing the new algorithm)
1660 but to have RRsets in its cache with signatures created by the old
1661 DNSKEY RRset (i.e., without the new algorithm).
1662
1663 The RRSIG for the DNSKEY RRset does not need to be pre-published
1664 (since these records will travel together) and does not need
1665 special processing in order to keep them synchronized.
1666
1667 new DNSKEY: After the old data has expired from caches, the new key
1668 can be added to the zone.
1669
1670 new DS: After the cache data for the old DNSKEY RRset has expired,
1671 the DS record for the new key can be added to the parent zone and
1672 the DS record for the old key can be removed in the same step.
1673
1674 DNSKEY removal: After the cache data for the old DS RRset has
1675 expired, the old algorithm can be removed. This time, the old key
1676 needs to be removed first, before removing the old signatures.
1677
1678 RRSIGs removal: After the cache data for the old DNSKEY RRset has
1679 expired, the old signatures can also be removed during this step.
1680
1681 Below, we deal with a few special cases of algorithm rollovers:
1682
1683 1: Single-Type Signing Scheme Algorithm rollover: when there is no
1684 differentiation between ZSKs and KSKs (Section 4.1.4.1).
1685
1686 2: RFC 5011 Algorithm rollover: when trust anchors can track the
1687 roll via RFC 5011 style rollover (Section 4.1.4.2).
1688
1689 3: 1 and 2 combined: when a Single-Type Signing Scheme Algorithm
1690 rollover is performed RFC 5011 style (Section 4.1.4.3).
1691
1692 In addition to the narrative below, these special cases are
1693 represented in Figures 12, 13, and 14 in Appendix C.
1694
1695
1696
1697
1698
1699
1700
1701
1702 Kolkman, et al. Informational [Page 31]
1703 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1704
1705
1706 4.1.4.1. Single-Type Signing Scheme Algorithm Rollover
1707
1708 If one key is used that acts as both ZSK and KSK, the same scheme and
1709 figure as above (Figure 8 in Section 4.1.4) applies, whereby all
1710 DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are
1711 replaced with RRSIG_S_*. All DNSKEY_K_* records are replaced with
1712 DNSKEY_S_*, and all RRSIG_K_* records are replaced with RRSIG_S_*.
1713 The requirement to sign with both algorithms and make sure that old
1714 RRSIGs have the opportunity to expire from distant caches before
1715 introducing the new algorithm in the DNSKEY RRset is still valid.
1716
1717 This is shown in Figure 12 in Appendix C.
1718
1719 4.1.4.2. Algorithm Rollover, RFC 5011 Style
1720
1721 Trust anchor algorithm rollover is almost as simple as a regular
1722 RFC 5011-based rollover. However, the old trust anchor must be
1723 revoked before it is removed from the zone.
1724
1725 The timeline (see Figure 13 in Appendix C) is similar to that of
1726 Figure 8 above, but after the "new DS" step, an additional step is
1727 required where the DNSKEY is revoked. The details of this step
1728 ("revoke DNSKEY") are shown in Figure 9 below.
1729
1730 ---------------------------------
1731 revoke DNSKEY
1732 ---------------------------------
1733 Parent:
1734 ----------------------------->
1735 ----------------------------->
1736 ----------------------------->
1737 ----------------------------->
1738
1739 Child:
1740 SOA_3
1741 RRSIG_Z_10(SOA)
1742 RRSIG_Z_11(SOA)
1743
1744 DNSKEY_K_1_REVOKED
1745 DNSKEY_K_2
1746
1747 DNSKEY_Z_11
1748 RRSIG_K_1(DNSKEY)
1749 RRSIG_K_2(DNSKEY)
1750 ---------------------------------
1751
1752 Figure 9: The Revoke DNSKEY State That Is Added to an Algorithm
1753 Rollover when RFC 5011 Is in Use
1754
1755
1756
1757 Kolkman, et al. Informational [Page 32]
1758 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1759
1760
1761 There is one exception to the requirement from RFC 4035 quoted in
1762 Section 4.1.4 above: While all zone data must be signed with an
1763 unrevoked key, it is permissible to sign the key set with a revoked
1764 key. The somewhat esoteric argument is as follows:
1765
1766 Resolvers that do not understand the RFC 5011 REVOKE flag will handle
1767 DNSKEY_K_1_REVOKED the same as if it were DNSKEY_K_1. In other
1768 words, they will handle the revoked key as a normal key, and thus
1769 RRsets signed with this key will validate. As a result, the
1770 signature matches the algorithm listed in the DNSKEY RRset.
1771
1772 Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from the
1773 set of trust anchors. That is okay, since they have already added
1774 DNSKEY_K_2 as the new trust anchor. Thus, algorithm 2 is the only
1775 signaled algorithm by now. That is, we only need RRSIG_K_2(DNSKEY)
1776 to authenticate the DNSKEY RRset, and we are still compliant with
1777 Section 2.2 of RFC 4035: There must be an RRSIG for each RRset using
1778 at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
1779
1780 4.1.4.3. Single Signing Type Algorithm Rollover, RFC 5011 Style
1781
1782 If a decision is made to perform an RFC 5011 style rollover with a
1783 Single Signing Scheme key, it should be noted that Section 2.1 of
1784 RFC 5011 states:
1785
1786 Once the resolver sees the REVOKE bit, it MUST NOT use this key
1787 as a trust anchor or for any other purpose except to validate
1788 the RRSIG it signed over the DNSKEY RRset specifically for the
1789 purpose of validating the revocation.
1790
1791 This means that once DNSKEY_S_1 is revoked, it cannot be used to
1792 validate its signatures over non-DNSKEY RRsets. Thus, those RRsets
1793 should be signed with a shadow key, DNSKEY_Z_10, during the algorithm
1794 rollover. The shadow key can be removed at the same time the revoked
1795 DNSKEY_S_1 is removed from the zone. In other words, the zone must
1796 temporarily fall back to a KSK/ZSK split model during the rollover.
1797
1798 In other words, the rule that at every RRset there must be at least
1799 one signature for each algorithm used in the DNSKEY RRset still
1800 applies. This means that a different key with the same algorithm,
1801 other than the revoked key, must sign the entire zone. Thus, more
1802 operations are needed if the Single-Type Signing Scheme is used.
1803 Before rolling the algorithm, a new key must be introduced with the
1804 same algorithm as the key that is a candidate for revocation. That
1805 key can than temporarily act as a ZSK during the algorithm rollover.
1806
1807
1808
1809
1810
1811
1812 Kolkman, et al. Informational [Page 33]
1813 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1814
1815
1816 As with algorithm rollover RFC 5011 style, while all zone data must
1817 be signed with an unrevoked key, it is permissible to sign the key
1818 set with a revoked key using the same esoteric argument given in
1819 Section 4.1.4.2.
1820
1821 The lesson of all of this is that a Single-Type Signing Scheme
1822 algorithm rollover using RFC 5011 is as complicated as the name of
1823 the rollover implies: Reverting to a split-key scheme for the
1824 duration of the rollover may be preferable.
1825
1826 4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover
1827
1828 A special case is the rollover from an NSEC signed zone to an NSEC3
1829 signed zone. In this case, algorithm numbers are used to signal
1830 support for NSEC3 but they do not mandate the use of NSEC3.
1831 Therefore, NSEC records should remain in the zone until the rollover
1832 to a new algorithm has completed and the new DNSKEY RRset has
1833 populated distant caches, at the end of the "new DNSKEY" stage. At
1834 that point, the validators that have not implemented NSEC3 will treat
1835 the zone as unsecured as soon as they follow the chain of trust to
1836 the DS that points to a DNSKEY of the new algorithm, while validators
1837 that support NSEC3 will happily validate using NSEC. Turning on
1838 NSEC3 can then be done during the "new DS" step: increasing the
1839 serial number, introducing the NSEC3PARAM record to signal that
1840 NSEC3-authenticated data related to denial of existence should be
1841 served, and re-signing the zone.
1842
1843 In summary, an NSEC-to-NSEC3 rollover is an ordinary algorithm
1844 rollover whereby NSEC is used all the time and only after that
1845 rollover finished NSEC3 needs to be deployed. The procedures are
1846 also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155].
1847
1848 4.1.5. Considerations for Automated Key Rollovers
1849
1850 As keys must be renewed periodically, there is some motivation to
1851 automate the rollover process. Consider the following:
1852
1853 o ZSK rollovers are easy to automate, as only the child zone is
1854 involved.
1855
1856 o A KSK rollover needs interaction between the parent and child.
1857 Data exchange is needed to provide the new keys to the parent;
1858 consequently, this data must be authenticated, and integrity must
1859 be guaranteed in order to avoid attacks on the rollover.
1860
1861
1862
1863
1864
1865
1866
1867 Kolkman, et al. Informational [Page 34]
1868 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1869
1870
1871 4.2. Planning for Emergency Key Rollover
1872
1873 This section deals with preparation for a possible key compromise.
1874 It is advisable to have a documented procedure ready for those times
1875 when a key compromise is suspected or confirmed.
1876
1877 When the private material of one of a zone's keys is compromised, it
1878 can be used by an attacker for as long as a valid trust chain exists.
1879 A trust chain remains intact for
1880
1881 o as long as a signature over the compromised key in the trust chain
1882 is valid, and
1883
1884 o as long as the DS RR in the parent zone points to the
1885 (compromised) key signing the DNSKEY RRset, and
1886
1887 o as long as the (compromised) key is anchored in a resolver and is
1888 used as a starting point for validation (this is generally the
1889 hardest to update).
1890
1891 While a trust chain to a zone's compromised key exists, your
1892 namespace is vulnerable to abuse by anyone who has obtained
1893 illegitimate possession of the key. Zone administrators have to make
1894 a decision as to whether the abuse of the compromised key is worse
1895 than having data in caches that cannot be validated. If the zone
1896 administrator chooses to break the trust chain to the compromised
1897 key, data in caches signed with this key cannot be validated.
1898 However, if the zone administrator chooses to take the path of a
1899 regular rollover, during the rollover the malicious key holder can
1900 continue to spoof data so that it appears to be valid.
1901
1902 4.2.1. KSK Compromise
1903
1904 A compromised KSK can be used to sign the key set of an attacker's
1905 version of the zone. That zone could be used to poison the DNS.
1906
1907 A zone containing a DNSKEY RRset with a compromised KSK is vulnerable
1908 as long as the compromised KSK is configured as the trust anchor or a
1909 DS record in the parent zone points to it.
1910
1911 Therefore, when the KSK has been compromised, the trust anchor or the
1912 parent DS record should be replaced as soon as possible. It is local
1913 policy whether to break the trust chain during the emergency
1914 rollover. The trust chain would be broken when the compromised KSK
1915 is removed from the child's zone while the parent still has a DS
1916 record pointing to the compromised KSK. The assumption is that there
1917
1918
1919
1920
1921
1922 Kolkman, et al. Informational [Page 35]
1923 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1924
1925
1926 is only one DS record at the parent. If there are multiple DS
1927 records, this does not apply, although the chain of trust of this
1928 particular key is broken.
1929
1930 Note that an attacker's version of the zone still uses the
1931 compromised KSK, and the presence of the corresponding DS record in
1932 the parent would cause the data in this zone to appear as valid.
1933 Removing the compromised key would cause the attacker's version of
1934 the zone to appear as valid and the original zone as Bogus.
1935 Therefore, we advise administrators not to remove the KSK before the
1936 parent has a DS record for the new KSK in place.
1937
1938 4.2.1.1. Emergency Key Rollover Keeping the Chain of Trust Intact
1939
1940 If it is desired to perform an emergency key rollover in a manner
1941 that keeps the chain of trust intact, the timing of the replacement
1942 of the KSK is somewhat critical. The goal is to remove the
1943 compromised KSK as soon as the new DS RR is available at the parent.
1944 This means ensuring that the signature made with a new KSK over the
1945 key set that contains the compromised KSK expires just after the new
1946 DS appears at the parent. Expiration of that signature will cause
1947 expiration of that key set from the caches.
1948
1949 The procedure is as follows:
1950
1951 1. Introduce a new KSK into the key set; keep the compromised KSK in
1952 the key set. Lower the TTL for DNSKEYs so that the DNSKEY RRset
1953 will expire from caches sooner.
1954
1955 2. Sign the key set, with a short validity period. The validity
1956 period should expire shortly after the DS is expected to appear
1957 in the parent and the old DSs have expired from caches. This
1958 provides an upper limit on how long the compromised KSK can be
1959 used in a replay attack.
1960
1961 3. Upload the DS for this new key to the parent.
1962
1963 4. Follow the procedure of the regular KSK rollover: Wait for the DS
1964 to appear at the authoritative servers, and then wait as long as
1965 the TTL of the old DS RRs. If necessary, re-sign the DNSKEY
1966 RRset and modify/extend the expiration time.
1967
1968 5. Remove the compromised DNSKEY RR from the zone, and re-sign the
1969 key set using your "normal" TTL and signature validity period.
1970
1971
1972
1973
1974
1975
1976
1977 Kolkman, et al. Informational [Page 36]
1978 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1979
1980
1981 An additional danger of a key compromise is that the compromised key
1982 could be used to facilitate a legitimate-looking DNSKEY/DS rollover
1983 and/or name server changes at the parent. When that happens, the
1984 domain may be in dispute. An authenticated out-of-band and secure
1985 notify mechanism to contact a parent is needed in this case.
1986
1987 Note that this is only a problem when the DNSKEY and/or DS records
1988 are used to authenticate communication with the parent.
1989
1990 4.2.1.2. Emergency Key Rollover Breaking the Chain of Trust
1991
1992 There are two methods to perform an emergency key rollover in a
1993 manner that breaks the chain of trust. The first method causes the
1994 child zone to appear Bogus to validating resolvers. The other causes
1995 the child zone to appear Insecure. These are described below.
1996
1997 In the method that causes the child zone to appear Bogus to
1998 validating resolvers, the child zone replaces the current KSK with a
1999 new one and re-signs the key set. Next, it sends the DS of the new
2000 key to the parent. Only after the parent has placed the new DS in
2001 the zone is the child's chain of trust repaired. Note that until
2002 that time, the child zone is still vulnerable to spoofing: The
2003 attacker is still in possession of the compromised key that the DS
2004 points to.
2005
2006 An alternative method of breaking the chain of trust is by removing
2007 the DS RRs from the parent zone altogether. As a result, the child
2008 zone would become Insecure. After the DS has expired from distant
2009 caches, the keys and signatures are removed from the child zone, new
2010 keys and signatures are introduced, and finally, a new DS is
2011 submitted to the parent.
2012
2013 4.2.2. ZSK Compromise
2014
2015 Primarily because there is no interaction with the parent required
2016 when a ZSK is compromised, the situation is less severe than with a
2017 KSK compromise. The zone must still be re-signed with a new ZSK as
2018 soon as possible. As this is a local operation and requires no
2019 communication between the parent and child, this can be achieved
2020 fairly quickly. However, one has to take into account that -- just
2021 as with a normal rollover -- the immediate disappearance of the old
2022 compromised key may lead to verification problems. Also note that
2023 until the RRSIG over the compromised ZSK has expired, the zone may
2024 still be at risk.
2025
2026
2027
2028
2029
2030
2031
2032 Kolkman, et al. Informational [Page 37]
2033 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2034
2035
2036 4.2.3. Compromises of Keys Anchored in Resolvers
2037
2038 A key can also be pre-configured in resolvers as a trust anchor. If
2039 trust anchor keys are compromised, the administrators of resolvers
2040 using these keys should be notified of this fact. Zone
2041 administrators may consider setting up a mailing list to communicate
2042 the fact that a SEP key is about to be rolled over. This
2043 communication will of course need to be authenticated by some means,
2044 e.g., by using digital signatures.
2045
2046 End-users faced with the task of updating an anchored key should
2047 always verify the new key. New keys should be authenticated out-of-
2048 band, for example, through the use of an announcement website that is
2049 secured using Transport Layer Security (TLS) [RFC5246].
2050
2051 4.2.4. Stand-By Keys
2052
2053 Stand-by keys are keys that are published in your zone but are not
2054 used to sign RRsets. There are two reasons why someone would want to
2055 use stand-by keys. One is to speed up the emergency key rollover.
2056 The other is to recover from a disaster that leaves your production
2057 private keys inaccessible.
2058
2059 The way to deal with stand-by keys differs for ZSKs and KSKs. To
2060 make a stand-by ZSK, you need to publish its DNSKEY RR. To make a
2061 stand-by KSK, you need to get its DS RR published at the parent.
2062
2063 Assuming you have your normal DNS operation, to prepare stand-by keys
2064 you need to:
2065
2066 o Generate a stand-by ZSK and KSK. Store them safely in a location
2067 different than the place where the currently used ZSK and KSK are
2068 held.
2069
2070 o Pre-publish the DNSKEY RR of the stand-by ZSK in the zone.
2071
2072 o Pre-publish the DS of the stand-by KSK in the parent zone.
2073
2074 Now suppose a disaster occurs and disables access to the currently
2075 used keys. To recover from that situation, follow these procedures:
2076
2077 o Set up your DNS operations and introduce the stand-by KSK into the
2078 zone.
2079
2080 o Post-publish the disabled ZSK and sign the zone with the stand-by
2081 keys.
2082
2083
2084
2085
2086
2087 Kolkman, et al. Informational [Page 38]
2088 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2089
2090
2091 o After some time, when the new signatures have been propagated, the
2092 old keys, old signatures, and the old DS can be removed.
2093
2094 o Generate a new stand-by key set at a different location and
2095 continue "normal" operation.
2096
2097 4.3. Parent Policies
2098
2099 4.3.1. Initial Key Exchanges and Parental Policies Considerations
2100
2101 The initial key exchange is always subject to the policies set by the
2102 parent. It is specifically important in a registry-registrar-
2103 registrant model where a registry maintains the parent zone, and the
2104 registrant (the user of the child-domain name) deals with the
2105 registry through an intermediary called a registrar (see [RFC3375]
2106 for a comprehensive definition). The key material is to be passed
2107 from the DNS operator to the parent via a registrar, where both the
2108 DNS operator and registrar are selected by the registrant and might
2109 be different organizations. When designing a key exchange policy,
2110 one should take into account that the authentication and
2111 authorization mechanisms used during a key exchange should be as
2112 strong as the authentication and authorization mechanisms used for
2113 the exchange of delegation information between the parent and child.
2114 That is, there is no implicit need in DNSSEC to make the
2115 authentication process stronger than it is for regular DNS.
2116
2117 Using the DNS itself as the source for the actual DNSKEY material has
2118 the benefit that it reduces the chances of user error. A DNSKEY
2119 query tool can make use of the SEP bit [RFC4035] to select the proper
2120 key(s) from a DNSSEC key set, thereby reducing the chance that the
2121 wrong DNSKEY is sent. It can validate the self-signature over a key,
2122 thereby verifying the ownership of the private key material.
2123 Fetching the DNSKEY from the DNS ensures that the chain of trust
2124 remains intact once the parent publishes the DS RR indicating that
2125 the child is secure.
2126
2127 Note: Out-of-band verification is still needed when the key material
2128 is fetched for the first time, even via DNS. The parent can never be
2129 sure whether or not the DNSKEY RRs have been spoofed.
2130
2131 With some types of key rollovers, the DNSKEY is not pre-published,
2132 and a DNSKEY query tool is not able to retrieve the successor key.
2133 In this case, the out-of-band method is required. This also allows
2134 the child to determine the digest algorithm of the DS record.
2135
2136
2137
2138
2139
2140
2141
2142 Kolkman, et al. Informational [Page 39]
2143 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2144
2145
2146 4.3.2. Storing Keys or Hashes?
2147
2148 When designing a registry system, one should consider whether to
2149 store the DNSKEYs and/or the corresponding DSs. Since a child zone
2150 might wish to have a DS published using a message digest algorithm
2151 not yet understood by the registry, the registry can't count on being
2152 able to generate the DS record from a raw DNSKEY. Thus, we suggest
2153 that registry systems should be able to store DS RRs, even if they
2154 also store DNSKEYs (see also "DNSSEC Trust Anchor Configuration and
2155 Maintenance" [DNSSEC-TRUST-ANCHOR]).
2156
2157 The storage considerations also relate to the design of the customer
2158 interface and the method by which data is transferred between the
2159 registrant and registry: Will the child-zone administrator be able to
2160 upload DS RRs with unknown hash algorithms, or does the interface
2161 only allow DNSKEYs? When registries support the Extensible
2162 Provisioning Protocol (EPP) [RFC5910], that can be used for
2163 registrar-registry interactions, since that protocol allows the
2164 transfer of both DS and, optionally, DNSKEY RRs. There is no
2165 standardized way to move the data between the customer and the
2166 registrar. Different registrars have different mechanisms, ranging
2167 from simple web interfaces to various APIs. In some cases, the use
2168 of the DNSSEC extensions to EPP may be applicable.
2169
2170 Having an out-of-band mechanism such as a registry directory (e.g.,
2171 Whois) to find out which keys are used to generate DS Resource
2172 Records for specific owners and/or zones may also help with
2173 troubleshooting.
2174
2175 4.3.3. Security Lameness
2176
2177 Security lameness is defined as the state whereby the parent has a DS
2178 RR pointing to a nonexistent DNSKEY RR. Security lameness may occur
2179 temporarily during a Double-DS rollover scheme. However, care should
2180 be taken that not all DS RRs are pointing to a nonexistent DNSKEY RR,
2181 which will cause the child's zone to be marked Bogus by verifying DNS
2182 clients.
2183
2184 As part of a comprehensive delegation check, the parent could, at key
2185 exchange time, verify that the child's key is actually configured in
2186 the DNS. However, if a parent does not understand the hashing
2187 algorithm used by the child, the parental checks are limited to only
2188 comparing the key id.
2189
2190
2191
2192
2193
2194
2195
2196
2197 Kolkman, et al. Informational [Page 40]
2198 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2199
2200
2201 Child zones should be very careful in removing DNSKEY material --
2202 specifically, SEP keys -- for which a DS RR exists.
2203
2204 Once a zone is "security lame", a fix (e.g., removing a DS RR) will
2205 take time to propagate through the DNS.
2206
2207 4.3.4. DS Signature Validity Period
2208
2209 Since the DS can be replayed as long as it has a valid signature, a
2210 short signature validity period for the DS RRSIG minimizes the time
2211 that a child is vulnerable in the case of a compromise of the child's
2212 KSK(s). A signature validity period that is too short introduces the
2213 possibility that a zone is marked Bogus in the case of a
2214 configuration error in the signer. There may not be enough time to
2215 fix the problems before signatures expire (this is a generic
2216 argument; also see Section 4.4.2). Something as mundane as zone
2217 administrator unavailability during weekends shows the need for DS
2218 signature validity periods longer than two days. Just like any
2219 signature validity period, we suggest an absolute minimum for the DS
2220 signature validity period of a few days.
2221
2222 The maximum signature validity period of the DS record depends on how
2223 long child zones are willing to be vulnerable after a key compromise.
2224 On the other hand, shortening the DS signature validity period
2225 increases the operational risk for the parent. Therefore, the parent
2226 may have a policy to use a signature validity period that is
2227 considerably longer than the child would hope for.
2228
2229 A compromise between the policy/operational constraints of the parent
2230 and minimizing damage for the child may result in a DS signature
2231 validity period somewhere between a week and several months.
2232
2233 In addition to the signature validity period, which sets a lower
2234 bound on the number of times the zone administrator will need to sign
2235 the zone data and an upper bound on the time that a child is
2236 vulnerable after key compromise, there is the TTL value on the DS
2237 RRs. Shortening the TTL reduces the damage of a successful replay
2238 attack. It does mean that the authoritative servers will see more
2239 queries. But on the other hand, a short TTL lowers the persistence
2240 of DS RRsets in caches, thereby increasing the speed with which
2241 updated DS RRsets propagate through the DNS.
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252 Kolkman, et al. Informational [Page 41]
2253 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2254
2255
2256 4.3.5. Changing DNS Operators
2257
2258 The parent-child relationship is often described in terms of a
2259 registry-registrar-registrant model, where a registry maintains the
2260 parent zone and the registrant (the user of the child-domain name)
2261 deals with the registry through an intermediary called a registrar
2262 [RFC3375]. Registrants may outsource the maintenance of their DNS
2263 system, including the maintenance of DNSSEC key material, to the
2264 registrar or to another third party, referred to here as the DNS
2265 operator.
2266
2267 For various reasons, a registrant may want to move between DNS
2268 operators. How easy this move will be depends principally on the DNS
2269 operator from which the registrant is moving (the losing operator),
2270 as the losing operator has control over the DNS zone and its keys.
2271 The following sections describe the two cases: where the losing
2272 operator cooperates with the new operator (the gaining operator), and
2273 where the two do not cooperate.
2274
2275 4.3.5.1. Cooperating DNS Operators
2276
2277 In this scenario, it is assumed that the losing operator will not
2278 pass any private key material to the gaining operator (that would
2279 constitute a trivial case) but is otherwise fully cooperative.
2280
2281 In this environment, the change could be made with a Pre-Publish ZSK
2282 rollover, whereby the losing operator pre-publishes the ZSK of the
2283 gaining operator, combined with a Double-Signature KSK rollover where
2284 the two registrars exchange public keys and independently generate a
2285 signature over those key sets that they combine and both publish in
2286 their copy of the zone. Once that is done, they can use their own
2287 private keys to sign any of their zone content during the transfer.
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307 Kolkman, et al. Informational [Page 42]
2308 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2309
2310
2311 ------------------------------------------------------------
2312 initial | pre-publish |
2313 ------------------------------------------------------------
2314 Parent:
2315 NS_A NS_A
2316 DS_A DS_A
2317 ------------------------------------------------------------
2318 Child at A: Child at A: Child at B:
2319 SOA_A0 SOA_A1 SOA_B0
2320 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
2321
2322 NS_A NS_A NS_B
2323 RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
2324 RRSIG_Z_A(NS)
2325
2326 DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
2327 DNSKEY_Z_B DNSKEY_Z_B
2328 DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A
2329 DNSKEY_K_B DNSKEY_K_B
2330 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
2331 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
2332 ------------------------------------------------------------
2333
2334 ------------------------------------------------------------
2335 re-delegation | post-migration |
2336 ------------------------------------------------------------
2337 Parent:
2338 NS_B NS_B
2339 DS_B DS_B
2340 ------------------------------------------------------------
2341 Child at A: Child at B: Child at B:
2342
2343 SOA_A1 SOA_B0 SOA_B1
2344 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
2345
2346 NS_A NS_B NS_B
2347 NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS)
2348 RRSIG_Z_A(NS)
2349
2350 DNSKEY_Z_A DNSKEY_Z_A
2351 DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
2352 DNSKEY_K_A DNSKEY_K_A
2353 DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B
2354 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
2355 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
2356 ------------------------------------------------------------
2357
2358 Figure 10: Rollover for Cooperating Operators
2359
2360
2361
2362 Kolkman, et al. Informational [Page 43]
2363 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2364
2365
2366 In this figure, A denotes the losing operator and B the gaining
2367 operator. RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is
2368 produced with a KSK, and the appended A or B indicates the producers
2369 of the key pair. "Child at A" is how the zone content is represented
2370 by the losing DNS operator, and "Child at B" is how the zone content
2371 is represented by the gaining DNS operator.
2372
2373 The zone is initially delegated from the parent to the name servers
2374 of operator A. Operator A uses his own ZSK and KSK to sign the zone.
2375 The cooperating operator A will pre-publish the new NS record and the
2376 ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset
2377 generated by the KSK of operator B. Operator B needs to publish the
2378 same DNSKEY RRset. When that DNSKEY RRset has populated the caches,
2379 the re-delegation can be made, which involves adjusting the NS and DS
2380 records in the parent zone to point to operator B. And after all
2381 DNSSEC records related to operator A have expired from the caches,
2382 operator B can stop publishing the keys and signatures belonging to
2383 operator A, and vice versa.
2384
2385 The requirement to exchange signatures has a couple of drawbacks. It
2386 requires more operational overhead, because not only do the operators
2387 have to exchange public keys but they also have to exchange the
2388 signatures of the new DNSKEY RRset. This drawback does not exist if
2389 the Double-Signature KSK rollover is replaced with a Double-DS KSK
2390 rollover. See Figure 15 in Appendix D for the diagram.
2391
2392 Thus, if the registry and registrars allow DS records to be published
2393 that do not point to a published DNSKEY in the child zone, the
2394 Double-DS KSK rollover is preferred (see Figure 5), in combination
2395 with the Pre-Publish ZSK rollover. This does not require sharing the
2396 KSK signatures between the operators, but both operators still have
2397 to publish each other's ZSKs.
2398
2399 4.3.5.2. Non-Cooperating DNS Operators
2400
2401 In the non-cooperating case, matters are more complicated. The
2402 losing operator may not cooperate and leave the data in the DNS as
2403 is. In extreme cases, the losing operator may become obstructive and
2404 publish a DNSKEY RR with a high TTL and corresponding signature
2405 validity period so that registrar A's DNSKEY could end up in caches
2406 for (in theory at least) decades.
2407
2408 The problem arises when a validator tries to validate with the losing
2409 operator's key and there is no signature material produced with the
2410 losing operator available in the delegation path after re-delegation
2411 from the losing operator to the gaining operator has taken place.
2412 One could imagine a rollover scenario where the gaining operator
2413 takes a copy of all RRSIGs created by the losing operator and
2414
2415
2416
2417 Kolkman, et al. Informational [Page 44]
2418 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2419
2420
2421 publishes those in conjunction with its own signatures, but that
2422 would not allow any changes in the zone content. Since a
2423 re-delegation took place, the NS RRset has by definition changed, so
2424 such a rollover scenario will not work. Besides, if zone transfers
2425 are not allowed by the losing operator and NSEC3 is deployed in the
2426 losing operator's zone, then the gaining operator's zone will not
2427 have certainty that all of the losing operator's RRSIGs have been
2428 copied.
2429
2430 The only viable operation for the registrant is to have his zone go
2431 Insecure for the duration of the change. The registry should be
2432 asked to remove the DS RR pointing to the losing operator's DNSKEY
2433 and to change the NS RRset to point to the gaining operator. Once
2434 this has propagated through the DNS, the registry should be asked to
2435 insert the DS record pointing to the (newly signed) zone at
2436 operator B.
2437
2438 Note that some behaviors of resolver implementations may aid in the
2439 process of changing DNS operators:
2440
2441 o TTL sanity checking, as described in RFC 2308 [RFC2308], will
2442 limit the impact of the actions of an obstructive losing operator.
2443 Resolvers that implement TTL sanity checking will use an upper
2444 limit for TTLs on RRsets in responses.
2445
2446 o If RRsets at the zone cut (are about to) expire, the resolver
2447 restarts its search above the zone cut. Otherwise, the resolver
2448 risks continuing to use a name server that might be un-delegated
2449 by the parent.
2450
2451 o Limiting the time that DNSKEYs that seem to be unable to validate
2452 signatures are cached and/or trying to recover from cases where
2453 DNSKEYs do not seem to be able to validate data also reduce the
2454 effects of the problem of non-cooperating registrars.
2455
2456 However, there is no operational methodology to work around this
2457 business issue, and proper contractual relationships between all
2458 involved parties seem to be the only solution to cope with these
2459 problems. It should be noted that in many cases, the problem with
2460 temporary broken delegations already exists when a zone changes from
2461 one DNS operator to another. Besides, it is often the case that when
2462 operators are changed, the services that are referenced by that zone
2463 also change operators, possibly involving some downtime.
2464
2465 In any case, to minimize such problems, the classic configuration is
2466 to have relatively short TTLs on all involved Resource Records. That
2467 will solve many of the problems regarding changes to a zone,
2468 regardless of whether DNSSEC is used.
2469
2470
2471
2472 Kolkman, et al. Informational [Page 45]
2473 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2474
2475
2476 4.4. Time in DNSSEC
2477
2478 Without DNSSEC, all times in the DNS are relative. The SOA fields
2479 REFRESH, RETRY, and EXPIRATION are timers used to determine the time
2480 that has elapsed after a slave server synchronized with a master
2481 server. The TTL value and the SOA RR minimum TTL parameter [RFC2308]
2482 are used to determine how long a forwarder should cache data (or
2483 negative responses) after it has been fetched from an authoritative
2484 server. By using a signature validity period, DNSSEC introduces the
2485 notion of an absolute time in the DNS. Signatures in DNSSEC have an
2486 expiration date after which the signature is marked as invalid and
2487 the signed data is to be considered Bogus.
2488
2489 The considerations in this section are all qualitative and focused on
2490 the operational and managerial issues. A more thorough quantitative
2491 analysis of rollover timing parameters can be found in "DNSSEC Key
2492 Timing Considerations" [DNSSEC-KEY-TIMING].
2493
2494 4.4.1. Time Considerations
2495
2496 Because of the expiration of signatures, one should consider the
2497 following:
2498
2499 o We suggest that the Maximum Zone TTL value of your zone data be
2500 smaller than your signature validity period.
2501
2502 If the TTL duration was similar to that of the signature
2503 validity period, then all RRsets fetched during the validity
2504 period would be cached until the signature expiration time.
2505 Section 8.1 of RFC 4033 [RFC4033] suggests that "the resolver
2506 may use the time remaining before expiration of the signature
2507 validity period of a signed RRset as an upper bound for the
2508 TTL". As a result, the query load on authoritative servers
2509 would peak at the signature expiration time, as this is also
2510 the time at which records simultaneously expire from caches.
2511
2512 Having a TTL that is at least a few times smaller than your
2513 signature validity period avoids query load peaks.
2514
2515 o We suggest that the signature publication period end at least one
2516 Maximum Zone TTL duration (but preferably a minimum of a few days)
2517 before the end of the signature validity period.
2518
2519 Re-signing a zone shortly before the end of the signature
2520 validity period may cause the simultaneous expiration of data
2521 from caches. This in turn may lead to peaks in the load on
2522 authoritative servers. To avoid this, schemes are deployed
2523
2524
2525
2526
2527 Kolkman, et al. Informational [Page 46]
2528 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2529
2530
2531 whereby the zone is periodically visited for a re-signing
2532 operation, and those signatures that are within a so-called
2533 Refresh Period from signature expiration are recreated. Also
2534 see Section 4.4.2 below.
2535
2536 In the case of an operational error, you would have one Maximum
2537 Zone TTL duration to resolve the problem. Re-signing a zone a
2538 few days before the end of the signature validity period
2539 ensures that the signatures will survive at least a (long)
2540 weekend in case of such operational havoc. This is called the
2541 Refresh Period (see Section 4.4.2).
2542
2543 o We suggest that the Minimum Zone TTL be long enough to both fetch
2544 and verify all the RRs in the trust chain. In workshop
2545 environments, it has been demonstrated [NIST-Workshop] that a low
2546 TTL (under 5 to 10 minutes) caused disruptions because of the
2547 following two problems:
2548
2549 1. During validation, some data may expire before the validation
2550 is complete. The validator should be able to keep all data
2551 until it is completed. This applies to all RRs needed to
2552 complete the chain of trust: DS, DNSKEY, RRSIG, and the final
2553 answers, i.e., the RRset that is returned for the initial
2554 query.
2555
2556 2. Frequent verification causes load on recursive name servers.
2557 Data at delegation points, DS, DNSKEY, and RRSIG RRs benefits
2558 from caching. The TTL on those should be relatively long.
2559 Data at the leaves in the DNS tree has less impact on
2560 recursive name servers.
2561
2562 o Slave servers will need to be able to fetch newly signed zones
2563 well before the RRSIGs in the zone served by the slave server pass
2564 their signature expiration time.
2565
2566 When a slave server is out of synchronization with its master
2567 and data in a zone is signed by expired signatures, it may be
2568 better for the slave server not to give out any answer.
2569
2570 Normally, a slave server that is not able to contact a master
2571 server for an extended period will expire a zone. When that
2572 happens, the server will respond differently to queries for
2573 that zone. Some servers issue SERVFAIL, whereas others turn
2574 off the AA bit in the answers. The time of expiration is set
2575 in the SOA record and is relative to the last successful
2576 refresh between the master and the slave servers. There exists
2577 no coupling between the signature expiration of RRSIGs in the
2578 zone and the expire parameter in the SOA.
2579
2580
2581
2582 Kolkman, et al. Informational [Page 47]
2583 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2584
2585
2586 If the server serves a DNSSEC-secured zone, then it may happen
2587 that the signatures expire well before the SOA expiration timer
2588 counts down to zero. It is not possible to completely prevent
2589 this by modifying the SOA parameters.
2590
2591 However, the effects can be minimized where the SOA expiration
2592 time is equal to or shorter than the Refresh Period (see
2593 Section 4.4.2).
2594
2595 The consequence of an authoritative server not being able to
2596 update a zone for an extended period of time is that signatures
2597 may expire. In this case, non-secure resolvers will continue
2598 to be able to resolve data served by the particular slave
2599 servers, while security-aware resolvers will experience
2600 problems because of answers being marked as Bogus.
2601
2602 We suggest that the SOA expiration timer be approximately one
2603 third or a quarter of the signature validity period. It will
2604 allow problems with transfers from the master server to be
2605 noticed before signatures time out.
2606
2607 We also suggest that operators of name servers that supply
2608 secondary services develop systems to identify upcoming
2609 signature expirations in zones they slave and take appropriate
2610 action where such an event is detected.
2611
2612 When determining the value for the expiration parameter, one
2613 has to take the following into account: What are the chances
2614 that all secondaries expire the zone? How quickly can the
2615 administrators of the secondary servers be reached to load a
2616 valid zone? These questions are not DNSSEC-specific but may
2617 influence the choice of your signature validity periods.
2618
2619 4.4.2. Signature Validity Periods
2620
2621 4.4.2.1. Maximum Value
2622
2623 The first consideration for choosing a maximum signature validity
2624 period is the risk of a replay attack. For low-value, long-term
2625 stable resources, the risks may be minimal, and the signature
2626 validity period may be several months. Although signature validity
2627 periods of many years are allowed, the same "operational habit"
2628 arguments as those given in Section 3.2.2 play a role: When a zone is
2629 re-signed with some regularity, then zone administrators remain
2630 conscious of the operational necessity of re-signing.
2631
2632
2633
2634
2635
2636
2637 Kolkman, et al. Informational [Page 48]
2638 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2639
2640
2641 4.4.2.2. Minimum Value
2642
2643 The minimum value of the signature validity period is set for the
2644 time by which one would like to survive operational failure in
2645 provisioning: At what time will a failure be noticed, and at what
2646 time is action expected to be taken? By answering these questions,
2647 availability of zone administrators during (long) weekends or time
2648 taken to access backup media can be taken into account. The result
2649 could easily suggest a minimum signature validity period of a few
2650 days.
2651
2652 Note, however, that the argument above is assuming that zone data has
2653 just been signed and published when the problem occurred. In
2654 practice, it may be that a zone is signed according to a frequency
2655 set by the Re-Sign Period, whereby the signer visits the zone content
2656 and only refreshes signatures that are within a given amount of time
2657 (the Refresh Period) of expiration. The Re-Sign Period must be
2658 smaller than the Refresh Period in order for zone data to be signed
2659 in a timely fashion.
2660
2661 If an operational problem occurs during re-signing, then the
2662 signatures in the zone to expire first are the ones that have been
2663 generated longest ago. In the worst case, these signatures are the
2664 Refresh Period minus the Re-Sign Period away from signature
2665 expiration.
2666
2667 To make matters slightly more complicated, some signers vary the
2668 signature validity period over a small range (the jitter interval) so
2669 that not all signatures expire at the same time.
2670
2671 In other words, the minimum signature validity period is set by first
2672 choosing the Refresh Period (usually a few days), then defining the
2673 Re-Sign Period in such a way that the Refresh Period minus the
2674 Re-Sign Period, minus the maximum jitter sets the time in which
2675 operational havoc can be resolved.
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692 Kolkman, et al. Informational [Page 49]
2693 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2694
2695
2696 The relationship between signature times is illustrated in Figure 11.
2697
2698 Inception Signing Expiration
2699 time time time
2700 | | | | |
2701 |------------------|---------------------------------|.....|.....|
2702 | | | | |
2703 +/-jitter
2704
2705 | Inception offset | |
2706 |<---------------->| Validity Period |
2707 | |<---------------------------------------->|
2708
2709
2710 Inception Signing Reuse Reuse Reuse New Expiration
2711 time time RRSIG time
2712 | | | | | | |
2713 |------------------|-------------------------------|-------|
2714 | | | | | | |
2715 <-----> <-----> <-----> <----->
2716 Re-Sign Period
2717
2718 | Refresh |
2719 |<----------->|
2720 | Period |
2721
2722 Figure 11: Signature Timing Parameters
2723
2724 Note that in the figure the validity of the signature starts shortly
2725 before the signing time. That is done to deal with validators that
2726 might have some clock skew. This is called the inception offset, and
2727 it should be chosen so that false negatives are minimized to a
2728 reasonable level.
2729
2730 4.4.2.3. Differentiation between RRsets
2731
2732 It is possible to vary signature validity periods between signatures
2733 over different RRsets in the zone. In practice, this could be done
2734 when zones contain highly volatile data (which may be the case in
2735 dynamic-update environments). Note, however, that the risk of replay
2736 (e.g., by stale secondary servers) should be the leading factor in
2737 determining the signature validity period, since the TTLs on the data
2738 itself are still the primary parameter for cache expiry.
2739
2740 In some cases, the risk of replaying existing data might be different
2741 from the risk of replaying the denial of data. In those cases, the
2742 signature validity period on NSEC or NSEC3 records may be tweaked
2743 accordingly.
2744
2745
2746
2747 Kolkman, et al. Informational [Page 50]
2748 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2749
2750
2751 When a zone contains secure delegations, then a relatively short
2752 signature validity period protects the child against replay attacks
2753 in the case where the child's key is compromised (see Section 4.3.4).
2754 Since there is a higher operational risk for the parent registry when
2755 choosing a short validity period and a higher operational risk for
2756 the child when choosing a long validity period, some (price)
2757 differentiation may occur for validity periods between individual DS
2758 RRs in a single zone.
2759
2760 There seem to be no other arguments for differentiation in validity
2761 periods.
2762
2763 5. "Next Record" Types
2764
2765 One of the design tradeoffs made during the development of DNSSEC was
2766 to separate the signing and serving operations instead of performing
2767 cryptographic operations as DNS requests are being serviced. It is
2768 therefore necessary to create records that cover the very large
2769 number of nonexistent names that lie between the names that do exist.
2770
2771 There are two mechanisms to provide authenticated proof of
2772 nonexistence of domain names in DNSSEC: a clear-text one and an
2773 obfuscated-data one. Each mechanism:
2774
2775 o includes a list of all the RRTYPEs present, which can be used to
2776 prove the nonexistence of RRTYPEs at a certain name;
2777
2778 o stores only the name for which the zone is authoritative (that is,
2779 glue in the zone is omitted); and
2780
2781 o uses a specific RRTYPE to store information about the RRTYPEs
2782 present at the name: The clear-text mechanism uses NSEC, and the
2783 obfuscated-data mechanism uses NSEC3.
2784
2785 5.1. Differences between NSEC and NSEC3
2786
2787 The clear-text mechanism (NSEC) is implemented using a sorted linked
2788 list of names in the zone. The obfuscated-data mechanism (NSEC3) is
2789 similar but first hashes the names using a one-way hash function,
2790 before creating a sorted linked list of the resulting (hashed)
2791 strings.
2792
2793 The NSEC record requires no cryptographic operations aside from the
2794 validation of its associated signature record. It is human readable
2795 and can be used in manual queries to determine correct operation.
2796 The disadvantage is that it allows for "zone walking", where one can
2797 request all the entries of a zone by following the linked list of
2798 NSEC RRs via the "Next Domain Name" field. Though all agree that DNS
2799
2800
2801
2802 Kolkman, et al. Informational [Page 51]
2803 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2804
2805
2806 data is accessible through query mechanisms, for some zone
2807 administrators this behavior is undesirable for policy, regulatory,
2808 or other reasons.
2809
2810 Furthermore, NSEC requires a signature over every RR in the zone
2811 file, thereby ensuring that any denial of existence is
2812 cryptographically signed. However, in a large zone file containing
2813 many delegations, very few of which are to signed zones, this may
2814 produce unacceptable additional overhead, especially where insecure
2815 delegations are subject to frequent updates (a typical example might
2816 be a TLD operator with few registrants using secure delegations).
2817 NSEC3 allows intervals between two secure delegations to "opt out",
2818 in which case they may contain one or more insecure delegations, thus
2819 reducing the size and cryptographic complexity of the zone at the
2820 expense of the ability to cryptographically deny the existence of
2821 names in a specific span.
2822
2823 The NSEC3 record uses a hashing method of the requested name. To
2824 increase the workload required to guess entries in the zone, the
2825 number of hashing iterations can be specified in the NSEC3 record.
2826 Additionally, a salt can be specified that also modifies the hashes.
2827 Note that NSEC3 does not give full protection against information
2828 leakage from the zone (you can still derive the size of the zone,
2829 which RRTYPEs are in there, etc.).
2830
2831 5.2. NSEC or NSEC3
2832
2833 The first motivation to deploy NSEC3 -- prevention of zone
2834 enumeration -- only makes sense when zone content is not highly
2835 structured or trivially guessable. Highly structured zones, such as
2836 in-addr.arpa., ip6.arpa., and e164.arpa., can be trivially enumerated
2837 using ordinary DNS properties, while for small zones that only
2838 contain records in the apex of the zone and a few common names such
2839 as "www" or "mail", guessing zone content and proving completeness is
2840 also trivial when using NSEC3. In these cases, the use of NSEC is
2841 preferred to ease the work required by signers and validating
2842 resolvers.
2843
2844 For large zones where there is an implication of "not readily
2845 available" names, such as those where one has to sign a
2846 non-disclosure agreement before obtaining it, NSEC3 is preferred.
2847 The second reason to consider NSEC3 is "Opt-Out", which can reduce
2848 the number of NSEC3 records required. This is discussed further
2849 below (Section 5.3.4).
2850
2851
2852
2853
2854
2855
2856
2857 Kolkman, et al. Informational [Page 52]
2858 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2859
2860
2861 5.3. NSEC3 Parameters
2862
2863 NSEC3 is controlled by a number of parameters, some of which can be
2864 varied: This section discusses the choice of those parameters.
2865
2866 5.3.1. NSEC3 Algorithm
2867
2868 The NSEC3 hashing algorithm is performed on the Fully Qualified
2869 Domain Name (FQDN) in its uncompressed form. This ensures that brute
2870 force work done by an attacker for one FQDN cannot be reused for
2871 another FQDN attack, as these entries are by definition unique.
2872
2873 At the time of this writing, there is only one NSEC3 hash algorithm
2874 defined. [RFC5155] specifically states: "When specifying a new hash
2875 algorithm for use with NSEC3, a transition mechanism MUST also be
2876 defined". Therefore, this document does not consider NSEC3 hash
2877 algorithm transition.
2878
2879 5.3.2. NSEC3 Iterations
2880
2881 One of the concerns with NSEC3 is that a pre-calculated dictionary
2882 attack could be performed in order to assess whether or not certain
2883 domain names exist within a zone. Two mechanisms are introduced in
2884 the NSEC3 specification to increase the costs of such dictionary
2885 attacks: iterations and salt.
2886
2887 The iterations parameter defines the number of additional times the
2888 hash function has been performed. A higher value results in greater
2889 resiliency against dictionary attacks, at a higher computational cost
2890 for both the server and resolver.
2891
2892 RFC 5155 Section 10.3 [RFC5155] considers the tradeoffs between
2893 incurring cost during the signing process and imposing costs to the
2894 validating name server, while still providing a reasonable barrier
2895 against dictionary attacks. It provides useful limits of iterations
2896 for a given RSA key size. These are 150 iterations for 1024-bit
2897 keys, 500 iterations for 2048-bit keys, and 2,500 iterations for
2898 4096-bit keys. Choosing a value of 100 iterations is deemed to be a
2899 sufficiently costly, yet not excessive, value: In the worst-case
2900 scenario, the performance of name servers would be halved, regardless
2901 of key size [NSEC3-HASH-PERF].
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912 Kolkman, et al. Informational [Page 53]
2913 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2914
2915
2916 5.3.3. NSEC3 Salt
2917
2918 While the NSEC3 iterations parameter increases the cost of hashing a
2919 dictionary word, the NSEC3 salt reduces the lifetime for which that
2920 calculated hash can be used. A change of the salt value by the zone
2921 administrator would cause an attacker to lose all pre-calculated work
2922 for that zone.
2923
2924 There must be a complete NSEC3 chain using the same salt value, that
2925 matches the salt value in the NSEC3PARAM record. NSEC3 salt changes
2926 do not need special rollover procedures. Since changing the salt
2927 requires that all the NSEC3 records be regenerated and thus requires
2928 generating new RRSIGs over these NSEC3 records, it makes sense to
2929 align the change of the salt with a change of the Zone Signing Key,
2930 as that process in itself already usually requires that all RRSIGs be
2931 regenerated. If there is no critical dependency on incremental
2932 signing and the zone can be signed with little effort, there is no
2933 need for such alignment.
2934
2935 5.3.4. Opt-Out
2936
2937 The Opt-Out mechanism was introduced to allow for a gradual
2938 introduction of signed records in zones that contain mostly
2939 delegation records. The use of the Opt-Out flag changes the meaning
2940 of the NSEC3 span from authoritative denial of the existence of names
2941 within the span to proof that DNSSEC is not available for the
2942 delegations within the span. This allows for the addition or removal
2943 of the delegations covered by the span without recalculating or
2944 re-signing RRs in the NSEC3 RR chain.
2945
2946 Opt-Out is specified to be used only over delegation points and will
2947 therefore only bring relief to zones with a large number of insecure
2948 delegations. This consideration typically holds for large TLDs and
2949 similar zones; in most other circumstances, Opt-Out should not be
2950 deployed. Further considerations can be found in Section 12.2 of
2951 RFC 5155 [RFC5155].
2952
2953 6. Security Considerations
2954
2955 DNSSEC adds data origin authentication and data integrity to the DNS,
2956 using digital signatures over Resource Record sets. DNSSEC does not
2957 protect against denial-of-service attacks, nor does it provide
2958 confidentiality. For more general security considerations related to
2959 DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034], and
2960 RFC 4035 [RFC4035].
2961
2962
2963
2964
2965
2966
2967 Kolkman, et al. Informational [Page 54]
2968 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2969
2970
2971 This document tries to assess the operational considerations to
2972 maintain a stable and secure DNSSEC service. When performing key
2973 rollovers, it is important to keep in mind that it takes time for the
2974 data to be propagated to the verifying clients. It is also important
2975 to note that this data may be cached. Not taking into account the
2976 'data propagation' properties in the DNS may cause validation
2977 failures, because cached data may mismatch data fetched from the
2978 authoritative servers; this will make secured zones unavailable to
2979 security-aware resolvers.
2980
2981 7. Acknowledgments
2982
2983 Significant parts of the text of this document are copied from
2984 RFC 4641 [RFC4641]. That document was edited by Olaf Kolkman and
2985 Miek Gieben. Other people that contributed or were otherwise
2986 involved in that work were, in random order: Rip Loomis, Olafur
2987 Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van
2988 Rein, Tim McGinnis, Gilles Guette, Olivier Courtay, Sam Weiler, Jelte
2989 Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman,
2990 Marcos Sanz, Peter Koch, Mike StJohns, Emma Bretherick, Adrian
2991 Bedford, Lindy Foster, and O. Courtay.
2992
2993 For this version of the document, we would like to acknowledge people
2994 who were actively involved in the compilation of the document. In
2995 random order: Mark Andrews, Patrik Faltstrom, Tony Finch, Alfred
2996 Hoenes, Bill Manning, Scott Rose, Wouter Wijngaards, Antoin
2997 Verschuren, Marc Lampo, George Barwood, Sebastian Castro, Suresh
2998 Krishnaswamy, Eric Rescorla, Stephen Morris, Olafur Gudmundsson,
2999 Ondrej Sury, and Rickard Bellgrim.
3000
3001 8. Contributors
3002
3003 Significant contributions to this document were from:
3004
3005 Paul Hoffman, who contributed on the choice of cryptographic
3006 parameters and addressing some of the trust anchor issues;
3007
3008 Jelte Jansen, who provided the initial text in Section 4.1.4;
3009
3010 Paul Wouters, who provided the initial text for Section 5, and
3011 Alex Bligh, who improved it.
3012
3013 The figure in Section 4.4.2 was adapted from the OpenDNSSEC user
3014 documentation.
3015
3016
3017
3018
3019
3020
3021
3022 Kolkman, et al. Informational [Page 55]
3023 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3024
3025
3026 9. References
3027
3028 9.1. Normative References
3029
3030 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
3031 STD 13, RFC 1034, November 1987.
3032
3033 [RFC1035] Mockapetris, P., "Domain names - implementation and
3034 specification", STD 13, RFC 1035, November 1987.
3035
3036 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3037 Rose, "DNS Security Introduction and Requirements",
3038 RFC 4033, March 2005.
3039
3040 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3041 Rose, "Resource Records for the DNS Security Extensions",
3042 RFC 4034, March 2005.
3043
3044 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3045 Rose, "Protocol Modifications for the DNS Security
3046 Extensions", RFC 4035, March 2005.
3047
3048 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
3049 (DS) Resource Records (RRs)", RFC 4509, May 2006.
3050
3051 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
3052 Security (DNSSEC) Hashed Authenticated Denial of
3053 Existence", RFC 5155, March 2008.
3054
3055 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
3056 and RRSIG Resource Records for DNSSEC", RFC 5702,
3057 October 2009.
3058
3059 9.2. Informative References
3060
3061 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
3062 August 1996.
3063
3064 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
3065 Changes (DNS NOTIFY)", RFC 1996, August 1996.
3066
3067 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3068 Requirement Levels", BCP 14, RFC 2119, March 1997.
3069
3070 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
3071 NCACHE)", RFC 2308, March 1998.
3072
3073
3074
3075
3076
3077 Kolkman, et al. Informational [Page 56]
3078 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3079
3080
3081 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
3082 Update", RFC 3007, November 2000.
3083
3084 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol
3085 Requirements", RFC 3375, September 2002.
3086
3087 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
3088 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
3089 RFC 3766, April 2004.
3090
3091 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
3092 Requirements for Security", BCP 106, RFC 4086, June 2005.
3093
3094 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
3095 RFC 4641, September 2006.
3096
3097 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
3098 RFC 4949, August 2007.
3099
3100 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
3101 Trust Anchors", RFC 5011, September 2007.
3102
3103 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
3104 Security Extensions Mapping for the Extensible
3105 Provisioning Protocol (EPP)", RFC 5910, May 2010.
3106
3107 [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST
3108 Signature Algorithms in DNSKEY and RRSIG Resource Records
3109 for DNSSEC", RFC 5933, July 2010.
3110
3111 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
3112 Signature Algorithm (DSA) for DNSSEC", RFC 6605,
3113 April 2012.
3114
3115 [NIST-Workshop]
3116 Rose, S., "NIST DNSSEC workshop notes", July 2001,
3117 <http://www.ietf.org/mail-archive/web/dnsop/current/
3118 msg01020.html>.
3119
3120 [NIST-SP-800-90A]
3121 Barker, E. and J. Kelsey, "Recommendation for Random
3122 Number Generation Using Deterministic Random Bit
3123 Generators", NIST Special Publication 800-90A,
3124 January 2012.
3125
3126 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
3127 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
3128
3129
3130
3131
3132 Kolkman, et al. Informational [Page 57]
3133 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3134
3135
3136 [DNSSEC-KEY-TIMING]
3137 Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
3138 Timing Considerations", Work in Progress, July 2012.
3139
3140 [DNSSEC-DPS]
3141 Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
3142 Framework for DNSSEC Policies and DNSSEC Practice
3143 Statements", Work in Progress, November 2012.
3144
3145 [DNSSEC-TRUST-ANCHOR]
3146 Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor
3147 Configuration and Maintenance", Work in Progress,
3148 October 2010.
3149
3150 [NSEC3-HASH-PERF]
3151 Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs
3152 document 2010-002, March 2010.
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187 Kolkman, et al. Informational [Page 58]
3188 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3189
3190
3191 Appendix A. Terminology
3192
3193 In this document, there is some jargon used that is defined in other
3194 documents. In most cases, we have not copied the text from the
3195 documents defining the terms but have given a more elaborate
3196 explanation of the meaning. Note that these explanations should not
3197 be seen as authoritative.
3198
3199 Anchored key: A DNSKEY configured in resolvers around the globe.
3200 This key is hard to update, hence the term 'anchored'.
3201
3202 Bogus: Also see Section 5 of RFC 4033 [RFC4033]. An RRset in DNSSEC
3203 is marked "Bogus" when a signature of an RRset does not validate
3204 against a DNSKEY.
3205
3206 Key rollover: A key rollover (also called key supercession in some
3207 environments) is the act of replacing one key pair with another at
3208 the end of a key effectivity period.
3209
3210 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is
3211 used exclusively for signing the apex key set. The fact that a
3212 key is a KSK is only relevant to the signing tool.
3213
3214 Key size: The term 'key size' can be substituted by 'modulus size'
3215 throughout the document for RSA keys. It is mathematically more
3216 correct to use modulus size for RSA keys, but as this is a
3217 document directed at operators we feel more at ease with the term
3218 'key size'.
3219
3220 Private and public keys: DNSSEC secures the DNS through the use of
3221 public-key cryptography. Public-key cryptography is based on the
3222 existence of two (mathematically related) keys, a public key and a
3223 private key. The public keys are published in the DNS by the use
3224 of the DNSKEY Resource Record (DNSKEY RR). Private keys should
3225 remain private.
3226
3227 Refresh Period: The period before the expiration time of the
3228 signature, during which the signature is refreshed by the signer.
3229
3230 Re-Sign Period: This refers to the frequency with which a signing
3231 pass on the zone is performed. The Re-Sign Period defines when
3232 the zone is exposed to the signer. And on the signer, not all
3233 signatures in the zone have to be regenerated: That depends on the
3234 Refresh Period.
3235
3236
3237
3238
3239
3240
3241
3242 Kolkman, et al. Informational [Page 59]
3243 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3244
3245
3246 Secure Entry Point (SEP) key: A KSK that has a DS record in the
3247 parent zone pointing to it or that is configured as a trust
3248 anchor. Although not required by the protocol, we suggest that
3249 the SEP flag [RFC4034] be set on these keys.
3250
3251 Self-signature: This only applies to signatures over DNSKEYs; a
3252 signature made with DNSKEY x over DNSKEY x is called a self-
3253 signature. Note: Without further information, self-signatures
3254 convey no trust. They are useful to check the authenticity of the
3255 DNSKEY, i.e., they can be used as a hash.
3256
3257 Signing jitter: A random variation in the signature validity period
3258 of RRSIGs in a zone to prevent all of them from expiring at the
3259 same time.
3260
3261 Signer: The system that has access to the private key material and
3262 signs the Resource Record sets in a zone. A signer may be
3263 configured to sign only parts of the zone, e.g., only those RRsets
3264 for which existing signatures are about to expire.
3265
3266 Singing the zone file: The term used for the event where an
3267 administrator joyfully signs its zone file while producing melodic
3268 sound patterns.
3269
3270 Single-Type Signing Scheme: A signing scheme whereby the distinction
3271 between Zone Signing Keys and Key Signing Keys is not made.
3272
3273 Zone administrator: The 'role' that is responsible for signing a
3274 zone and publishing it on the primary authoritative server.
3275
3276 Zone Signing Key (ZSK): A key that is used for signing all data in a
3277 zone (except, perhaps, the DNSKEY RRset). The fact that a key is
3278 a ZSK is only relevant to the signing tool.
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297 Kolkman, et al. Informational [Page 60]
3298 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3299
3300
3301 Appendix B. Typographic Conventions
3302
3303 The following typographic conventions are used in this document:
3304
3305 Key notation: A key is denoted by DNSKEY_x_y, where x is an
3306 identifier for the type of key: K for Key Signing Key, Z for Zone
3307 Signing Key, and S when there is no distinction made between KSKs
3308 and ZSKs but the key is used as a secure entry point. The 'y'
3309 denotes a number or an identifier; y could be thought of as the
3310 key id.
3311
3312 RRsets ignored: If the signatures of non-DNSKEY RRsets have the same
3313 parameters as the SOA, then those are not mentioned; e.g., in the
3314 example below, the SOA is signed with the same parameters as the
3315 foo.example.com A RRset and the latter is therefore ignored in the
3316 abbreviated notation.
3317
3318 RRset notations: RRs are only denoted by the type. All other
3319 information -- owner, class, rdata, and TTL -- is left out. Thus:
3320 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRsets are a
3321 list of RRs. An example of this would be "A1, A2", specifying the
3322 RRset containing two "A" records. This could again be abbreviated
3323 to just "A".
3324
3325 Signature notation: Signatures are denoted as RRSIG_x_y(type), which
3326 means that the RRset with the specific RRTYPE 'type' is signed
3327 with DNSKEY_x_y. Signatures in the parent zone are denoted as
3328 RRSIG_par(type).
3329
3330 SOA representation: SOAs are represented as SOA_x, where x is the
3331 serial number.
3332
3333 DS representation: DSs are represented as DS_x_y, where x and y are
3334 identifiers similar to the key notation: x is an identifier for
3335 the type of key the DS record refers to; y is the 'key id' of the
3336 key it refers to.
3337
3338 Zone representation: Using the above notation we have simplified the
3339 representation of a signed zone by leaving out all unnecessary
3340 details, such as the names, and by representing all data by
3341 "SOA_x".
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352 Kolkman, et al. Informational [Page 61]
3353 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3354
3355
3356 Using this notation, the following signed zone:
3357
3358 example.com. 3600 IN SOA ns1.example.com. olaf.example.net. (
3359 2005092303 ; serial
3360 450 ; refresh (7 minutes 30 seconds)
3361 600 ; retry (10 minutes)
3362 345600 ; expire (4 days)
3363 300 ; minimum (5 minutes)
3364 )
3365 3600 RRSIG SOA 5 2 3600 20120824013000 (
3366 20100424013000 14 example.com.
3367 NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo
3368 ...
3369 OMY3rTMA2qorupQXjQ== )
3370 3600 NS ns1.example.com.
3371 3600 NS ns2.example.com.
3372 3600 NS ns3.example.com.
3373 3600 RRSIG NS 5 2 3600 20120824013000 (
3374 20100424013000 14 example.com.
3375 p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz
3376 ...
3377 +SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4
3378 zAgaJM/MeG08KpeHhg== )
3379 3600 TXT "Net::DNS domain"
3380 3600 RRSIG TXT 5 2 3600 20120824013000 (
3381 20100424013000 14 example.com.
3382 o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp
3383 ...
3384 BcQ1o99vwn+IS4+J1g== )
3385 300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY
3386 300 RRSIG NSEC 5 2 300 20120824013000 (
3387 20100424013000 14 example.com.
3388 JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+
3389 ...
3390 PkXNI/Vgf4t3xZaIyw== )
3391 3600 DNSKEY 256 3 5 (
3392 AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX
3393 ...
3394 sAuryjQ/HFa5r4mrbhkJ
3395 ) ; key id = 14
3396 3600 DNSKEY 257 3 5 (
3397 AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO
3398 ...
3399 oy88Nh+u2c9HF1tw0naH
3400 ) ; key id = 15
3401
3402
3403
3404
3405
3406
3407 Kolkman, et al. Informational [Page 62]
3408 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3409
3410
3411 3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
3412 20100424013000 14 example.com.
3413 HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U
3414 ...
3415 QhhmMwV3tIxJk2eDRQ== )
3416 3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
3417 20100424013000 15 example.com.
3418 P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE
3419 ...
3420 JWL70YiUnUG3m9OL9w== )
3421 foo.example.com. 3600 IN A 192.0.2.2
3422 3600 RRSIG A 5 3 3600 20120824013000 (
3423 20100424013000 14 example.com.
3424 xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO
3425 ...
3426 JPV/SA4BkoFxIcPrDQ== )
3427 300 NSEC example.com. A RRSIG NSEC
3428 300 RRSIG NSEC 5 3 300 20120824013000 (
3429 20100424013000 14 example.com.
3430 Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF
3431 ...
3432 Qe000JyzObxx27pY8A== )
3433
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
------------------->
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_11 DNSKEY_Z_11
------------------->
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 8: Stages of Deployment during an Algorithm Rollover
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
------------------->
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_11 DNSKEY_Z_11
-------------------> RRSIG_K_1(DNSKEY)
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 8: Stages of Deployment during an Algorithm Rollover
3434 is reduced to the following representation:
3435
3436 SOA_2005092303
3437 RRSIG_Z_14(SOA_2005092303)
3438 DNSKEY_K_14
3439 DNSKEY_Z_15
3440 RRSIG_K_14(DNSKEY)
3441 RRSIG_Z_15(DNSKEY)
3442
3443 The rest of the zone data has the same signature as the SOA record,
3444 i.e., an RRSIG created with DNSKEY_K_14.
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462 Kolkman, et al. Informational [Page 63]
3463 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3464
3465
3466 Appendix C. Transition Figures for Special Cases of Algorithm Rollovers
3467
3468 The figures in this appendix complement and illustrate the special
3469 cases of algorithm rollovers as described in Section 4.1.4.
3470
3471 ----------------------------------------------------------------
3472 initial new RRSIGs new DNSKEY
3473 ----------------------------------------------------------------
3474 Parent:
3475 SOA_0 -------------------------------------------------------->
3476 RRSIG_par(SOA) ----------------------------------------------->
3477 DS_S_1 ------------------------------------------------------->
3478 RRSIG_par(DS_S_1) -------------------------------------------->
3479
3480 Child:
3481 SOA_0 SOA_1 SOA_2
3482 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA)
3483 RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3484
3485 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
3486 DNSKEY_S_2
3487 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
3488 RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3489
3490 ----------------------------------------------------------------
3491 new DS DNSKEY removal RRSIGs removal
3492 ----------------------------------------------------------------
3493 Parent:
3494 SOA_1 ------------------------------------------------------->
3495 RRSIG_par(SOA) ---------------------------------------------->
3496 DS_S_2 ------------------------------------------------------>
3497 RRSIG_par(DS_S_2) ------------------------------------------->
3498
3499 Child:
3500 -------------------> SOA_3 SOA_4
3501 -------------------> RRSIG_S_1(SOA)
3502 -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3503
3504 ------------------->
3505 -------------------> DNSKEY_S_2 DNSKEY_S_2
3506 -------------------> RRSIG_S_1(DNSKEY)
3507 -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3508 ----------------------------------------------------------------
3509
3510 Figure 12: Single-Type Signing Scheme Algorithm Roll
3511
3512 Also see Section 4.1.4.1.
3513
3514
3515
3516
3517 Kolkman, et al. Informational [Page 64]
3518 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3519
3520
3521 ----------------------------------------------------------------
3522 initial new RRSIGs new DNSKEY
3523 ----------------------------------------------------------------
3524 Parent:
3525 SOA_0 -------------------------------------------------------->
3526 RRSIG_par(SOA) ----------------------------------------------->
3527 DS_K_1 ------------------------------------------------------->
3528 RRSIG_par(DS_K_1) -------------------------------------------->
3529
3530 Child:
3531 SOA_0 SOA_1 SOA_2
3532 RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
3533 RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
3534
3535 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
3536 DNSKEY_K_2
3537 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1
3538 DNSKEY_Z_2
3539 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
3540 RRSIG_K_2(DNSKEY)
3541
3542 ----------------------------------------------------------------
3543 new DS revoke DNSKEY DNSKEY removal
3544 ----------------------------------------------------------------
3545 Parent:
3546 SOA_1 ------------------------------------------------------->
3547 RRSIG_par(SOA) ---------------------------------------------->
3548 DS_K_2 ------------------------------------------------------>
3549 RRSIG_par(DS_K_2) ------------------------------------------->
3550
3551 Child:
3552 -------------------> SOA_3 SOA_4
3553 -------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
3554 -------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
3555
3556 -------------------> DNSKEY_K_1_REVOKED
3557 -------------------> DNSKEY_K_2 DNSKEY_K_2
3558 ------------------->
3559 -------------------> DNSKEY_Z_2 DNSKEY_Z_2
3560 -------------------> RRSIG_K_1(DNSKEY)
3561 -------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572 Kolkman, et al. Informational [Page 65]
3573 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3574
3575
3576 ----------------------------------------------------------------
3577 RRSIGs removal
3578 ----------------------------------------------------------------
3579 Parent:
3580 ------------------------------------->
3581 ------------------------------------->
3582 ------------------------------------->
3583 ------------------------------------->
3584
3585 Child:
3586 SOA_5
3587 RRSIG_Z_2(SOA)
3588
3589 DNSKEY_K_2
3590
3591 DNSKEY_Z_2
3592
3593 RRSIG_K_2(DNSKEY)
3594 ----------------------------------------------------------------
3595
3596 Figure 13: RFC 5011 Style Algorithm Roll
3597
3598 Also see Section 4.1.4.2.
3599
3600
3601 ----------------------------------------------------------------
3602 initial new RRSIGs new DNSKEY
3603 ----------------------------------------------------------------
3604 Parent:
3605 SOA_0 -------------------------------------------------------->
3606 RRSIG_par(SOA) ----------------------------------------------->
3607 DS_S_1 ------------------------------------------------------->
3608 RRSIG_par(DS_S_1) -------------------------------------------->
3609
3610 Child:
3611 SOA_0 SOA_1 SOA_2
3612 RRSIG_S_1(SOA)
3613 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
3614 RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3615
3616 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
3617 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
3618 DNSKEY_S_2
3619 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
3620 RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3621
3622
3623
3624
3625
3626
3627 Kolkman, et al. Informational [Page 66]
3628 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3629
3630
3631 ----------------------------------------------------------------
3632 new DS revoke DNSKEY DNSKEY removal
3633 ----------------------------------------------------------------
3634 Parent:
3635 SOA_1 ------------------------------------------------------->
3636 RRSIG_par(SOA) ---------------------------------------------->
3637 DS_S_2 ------------------------------------------------------>
3638 RRSIG_par(DS_S_2) ------------------------------------------->
3639
3640 Child:
3641 -------------------> SOA_3 SOA_4
3642
3643 -------------------> RRSIG_Z_10(SOA)
3644 -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3645
3646 -------------------> DNSKEY_S_1_REVOKED
3647 -------------------> DNSKEY_Z_10
3648 -------------------> DNSKEY_S_2 DNSKEY_S_2
3649 -------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
3650 -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3651
3652 ----------------------------------------------------------------
3653 RRSIGs removal
3654 ----------------------------------------------------------------
3655 Parent:
3656 ------------------------------------->
3657 ------------------------------------->
3658 ------------------------------------->
3659 ------------------------------------->
3660
3661 Child:
3662 SOA_5
3663
3664
3665 RRSIG_S_2(SOA)
3666
3667
3668
3669 DNSKEY_S_2
3670
3671 RRSIG_S_2(DNSKEY)
3672 ----------------------------------------------------------------
3673
3674 Figure 14: RFC 5011 Algorithm Roll in a Single-Type
3675 Signing Scheme Environment
3676
3677 Also see Section 4.1.4.3.
3678
3679
3680
3681
3682 Kolkman, et al. Informational [Page 67]
3683 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3684
3685
3686 Appendix D. Transition Figure for Changing DNS Operators
3687
3688 The figure in this Appendix complements and illustrates the special
3689 case of changing DNS operators as described in Section 4.3.5.1.
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737 Kolkman, et al. Informational [Page 68]
3738 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3739
3740
is reduced to the following representation:
SOA_2005092303
RRSIG_Z_14(SOA_2005092303)
DNSKEY_K_14
DNSKEY_Z_15
RRSIG_K_14(DNSKEY)
RRSIG_Z_15(DNSKEY)
The rest of the zone data has the same signature as the SOA record,
i.e., an RRSIG created with DNSKEY_K_14.
is reduced to the following representation:
SOA_2005092303
RRSIG_Z_14(SOA_2005092303)
DNSKEY_KZ_14
DNSKEY_ZK_15
RRSIG_KZ_14(DNSKEY)
RRSIG_ZK_15(DNSKEY)
The rest of the zone data has the same signature as the SOA record,
i.e., an RRSIG created with DNSKEY_K_145.
3741 ------------------------------------------------------------
3742 new DS | pre-publish |
3743 ------------------------------------------------------------
3744 Parent:
3745 NS_A NS_A
3746 DS_A DS_B DS_A DS_B
3747 ------------------------------------------------------------
3748 Child at A: Child at A: Child at B:
3749 SOA_A0 SOA_A1 SOA_B0
3750 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
3751
3752 NS_A NS_A NS_B
3753 RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
3754 RRSIG_Z_A(NS)
3755
3756 DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
3757 DNSKEY_Z_B DNSKEY_Z_B
3758 DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
3759 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
3760 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
3761 ------------------------------------------------------------
3762
3763 ------------------------------------------------------------
3764 re-delegation | post-migration |
3765 ------------------------------------------------------------
3766 Parent:
3767 NS_B NS_B
3768 DS_A DS_B DS_B
3769 ------------------------------------------------------------
3770 Child at A: Child at B: Child at B:
3771
3772 SOA_A1 SOA_B0 SOA_B1
3773 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
3774
3775 NS_A NS_B NS_B
3776 NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS)
3777 RRSIG_Z_A(NS)
3778
3779 DNSKEY_Z_A DNSKEY_Z_A
3780 DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
3781 DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B
3782 RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
3783 ------------------------------------------------------------
3784
3785 Figure 15: An Alternative Rollover Approach for Cooperating Operators
3786
3787
3788
3789
3790
3791
3792 Kolkman, et al. Informational [Page 69]
3793 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3794
3795
3796 Appendix E. Summary of Changes from RFC 4641
3797
3798 This document differs from RFC 4641 [RFC4641] in the following ways:
3799
3800 o Addressed the errata listed on
3801 <http://www.rfc-editor.org/errata_search.php./rfc4641>.
3802
3803 o Recommended RSA/SHA-256 in addition to RSA/SHA-1.
3804
3805 o Did a complete rewrite of Section 3.5 of RFC 4641 (Section 3.4.2
3806 of this document), removing the table and suggesting a key size of
3807 1024 for keys in use for less than 8 years, issued up to at least
3808 2015.
3809
3810 o Removed the KSK for high-level zones consideration.
3811
3812 o Added text on algorithm rollover.
3813
3814 o Added text on changing (non-cooperating) DNS registrars.
3815
3816 o Did a significant rewrite of Section 3, whereby the argument is
3817 made that the timescales for rollovers are made purely on
3818 operational arguments.
3819
3820 o Added Section 5.
3821
3822 o Introduced Single-Type Signing Scheme terminology and made the
3823 arguments for the choice of a Single-Type Signing Scheme more
3824 explicit.
3825
3826 o Added a section about stand-by keys.
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847 Kolkman, et al. Informational [Page 70]
3848 RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3849
3850
3851 Authors' Addresses
3852
3853 Olaf M. Kolkman
3854 NLnet Labs
3855 Science Park 400
3856 Amsterdam 1098 XH
3857 The Netherlands
3858
3859 EMail: olaf@nlnetlabs.nl
3860 URI: http://www.nlnetlabs.nl
3861
3862
3863 W. (Matthijs) Mekking
3864 NLnet Labs
3865 Science Park 400
3866 Amsterdam 1098 XH
3867 The Netherlands
3868
3869 EMail: matthijs@nlnetlabs.nl
3870 URI: http://www.nlnetlabs.nl
3871
3872
3873 R. (Miek) Gieben
3874 SIDN Labs
3875 Meander 501
3876 Arnhem 6825 MD
3877 The Netherlands
3878
3879 EMail: miek.gieben@sidn.nl
3880 URI: http://www.sidn.nl
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902 Kolkman, et al. Informational [Page 71]
3903
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B
RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B
RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------