7Internet Engineering Task Force (IETF) O. Kolkman
8Request for Comments: 6781 W. Mekking
9Obsoletes: 4641 NLnet Labs
10Category: Informational R. Gieben
11ISSN: 2070-1721 SIDN Labs
15 DNSSEC Operational Practices, Version 2
19 This document describes a set of practices for operating the DNS with
20 security extensions (DNSSEC). The target audience is zone
21 administrators deploying DNSSEC.
23 The document discusses operational aspects of using keys and
24 signatures in the DNS. It discusses issues of key generation, key
25 storage, signature generation, key rollover, and related policies.
27 This document obsoletes RFC 4641, as it covers more operational
28 ground and gives more up-to-date requirements with respect to key
29 sizes and the DNSSEC operations.
33 This document is not an Internet Standards Track specification; it is
34 published for informational purposes.
36 This document is a product of the Internet Engineering Task Force
37 (IETF). It represents the consensus of the IETF community. It has
38 received public review and has been approved for publication by the
39 Internet Engineering Steering Group (IESG). Not all documents
40 approved by the IESG are a candidate for any level of Internet
41 Standard; see Section 2 of RFC 5741.
43 Information about the current status of this document, any errata,
44 and how to provide feedback on it may be obtained at
45 http://www.rfc-editor.org/info/rfc6781.
58Kolkman, et al. Informational [Page 1]
60RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
65 Copyright (c) 2012 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
92 1. Introduction ....................................................4
93 1.1. The Use of the Term 'key' ..................................5
94 1.2. Time Definitions ...........................................6
95 2. Keeping the Chain of Trust Intact ...............................6
96 3. Key Generation and Storage ......................................7
97 3.1. Operational Motivation for Zone Signing Keys and
98 Key Signing Keys ...........................................8
99 3.2. Practical Consequences of KSK and ZSK Separation ..........10
100 3.2.1. Rolling a KSK That Is Not a Trust Anchor ...........10
101 3.2.2. Rolling a KSK That Is a Trust Anchor ...............11
102 3.2.3. The Use of the SEP Flag ............................12
103 3.3. Key Effectivity Period ....................................12
104 3.4. Cryptographic Considerations ..............................14
105 3.4.1. Signature Algorithm ................................14
106 3.4.2. Key Sizes ..........................................14
107 3.4.3. Private Key Storage ................................16
108 3.4.4. Key Generation .....................................17
109 3.4.5. Differentiation for 'High-Level' Zones? ............17
114Kolkman, et al. Informational [Page 2]
116RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
119 4. Signature Generation, Key Rollover, and Related Policies .......18
120 4.1. Key Rollovers .............................................18
121 4.1.1. Zone Signing Key Rollovers .........................18
122 4.1.1.1. Pre-Publish Zone Signing Key Rollover .....19
123 4.1.1.2. Double-Signature Zone Signing Key Rollover 21
124 4.1.1.3. Pros and Cons of the Schemes ..............23
125 4.1.2. Key Signing Key Rollovers ..........................23
126 4.1.2.1. Special Considerations for RFC 5011
127 KSK Rollover ..............................26
128 4.1.3. Single-Type Signing Scheme Key Rollover ............26
129 4.1.4. Algorithm Rollovers ................................28
130 4.1.4.1. Single-Type Signing Scheme
131 Algorithm Rollover ........................32
132 4.1.4.2. Algorithm Rollover, RFC 5011 Style ........32
133 4.1.4.3. Single Signing Type Algorithm
134 Rollover, RFC 5011 Style ..................33
135 4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover ..........34
136 4.1.5. Considerations for Automated Key Rollovers .........34
137 4.2. Planning for Emergency Key Rollover .......................35
138 4.2.1. KSK Compromise .....................................35
139 4.2.1.1. Emergency Key Rollover Keeping the
140 Chain of Trust Intact .....................36
141 4.2.1.2. Emergency Key Rollover Breaking
142 the Chain of Trust ........................37
143 4.2.2. ZSK Compromise .....................................37
144 4.2.3. Compromises of Keys Anchored in Resolvers ..........38
145 4.2.4. Stand-By Keys ......................................38
146 4.3. Parent Policies ...........................................39
147 4.3.1. Initial Key Exchanges and Parental Policies
148 Considerations .....................................39
149 4.3.2. Storing Keys or Hashes? ............................40
150 4.3.3. Security Lameness ..................................40
151 4.3.4. DS Signature Validity Period .......................41
152 4.3.5. Changing DNS Operators .............................42
153 4.3.5.1. Cooperating DNS Operators .................42
154 4.3.5.2. Non-Cooperating DNS Operators .............44
155 4.4. Time in DNSSEC ............................................46
156 4.4.1. Time Considerations ................................46
157 4.4.2. Signature Validity Periods .........................48
158 4.4.2.1. Maximum Value .............................48
159 4.4.2.2. Minimum Value .............................49
160 4.4.2.3. Differentiation between RRsets ............50
170Kolkman, et al. Informational [Page 3]
172RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
175 5. "Next Record" Types ............................................51
176 5.1. Differences between NSEC and NSEC3 ........................51
177 5.2. NSEC or NSEC3 .............................................52
178 5.3. NSEC3 Parameters ..........................................53
179 5.3.1. NSEC3 Algorithm ....................................53
180 5.3.2. NSEC3 Iterations ...................................53
181 5.3.3. NSEC3 Salt .........................................54
182 5.3.4. Opt-Out ............................................54
183 6. Security Considerations ........................................54
184 7. Acknowledgments ................................................55
185 8. Contributors ...................................................55
186 9. References .....................................................56
187 9.1. Normative References ......................................56
188 9.2. Informative References ....................................56
189 Appendix A. Terminology ...........................................59
190 Appendix B. Typographic Conventions ...............................61
191 Appendix C. Transition Figures for Special Cases of Algorithm
192 Rollovers .............................................64
193 Appendix D. Transition Figure for Changing DNS Operators ..........68
194 Appendix E. Summary of Changes from RFC 4641 ......................70
198 This document describes how to run a DNS Security (DNSSEC)-enabled
199 environment. It is intended for operators who have knowledge of the
200 DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to
201 deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035
202 [RFC4035], and RFC 5155 [RFC5155]). The focus of the document is on
203 serving authoritative DNS information and is aimed at zone owners,
204 name server operators, registries, registrars, and registrants. It
205 assumes that there is no direct relationship between those entities
206 and the operators of validating recursive name servers (validators).
208 During workshops and early operational deployment, operators and
209 system administrators have gained experience about operating the DNS
210 with security extensions (DNSSEC). This document translates these
211 experiences into a set of practices for zone administrators.
212 Although the DNS Root has been signed since July 15, 2010 and now
213 more than 80 secure delegations are provisioned in the root, at the
214 time of this writing there still exists relatively little experience
215 with DNSSEC in production environments below the Top-Level Domain
216 (TLD) level; this document should therefore explicitly not be seen as
217 representing 'Best Current Practices'. Instead, it describes the
218 decisions that should be made when deploying DNSSEC, gives the
219 choices available for each one, and provides some operational
220 guidelines. The document does not give strong recommendations. That
221 may be the subject for a future version of this document.
226Kolkman, et al. Informational [Page 4]
228RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
231 The procedures herein are focused on the maintenance of signed zones
232 (i.e., signing and publishing zones on authoritative servers). It is
233 intended that maintenance of zones, such as re-signing or key
234 rollovers, be transparent to any verifying clients.
236 The structure of this document is as follows. In Section 2, we
237 discuss the importance of keeping the "chain of trust" intact.
238 Aspects of key generation and storage of keys are discussed in
239 Section 3; the focus in this section is mainly on the security of the
240 private part of the key(s). Section 4 describes considerations
241 concerning the public part of the keys. Sections 4.1 and 4.2 deal
242 with the rollover, or replacement, of keys. Section 4.3 discusses
243 considerations on how parents deal with their children's public keys
244 in order to maintain chains of trust. Section 4.4 covers all kinds
245 of timing issues around key publication. Section 5 covers the
246 considerations regarding selecting and using the NSEC or NSEC3
247 [RFC5155] Resource Record.
249 The typographic conventions used in this document are explained in
252 Since we describe operational suggestions and there are no protocol
253 specifications, the RFC 2119 [RFC2119] language does not apply to
254 this document, though we do use quotes from other documents that do
255 include the RFC 2119 language.
257 This document obsoletes RFC 4641 [RFC4641].
2591.1. The Use of the Term 'key'
261 It is assumed that the reader is familiar with the concept of
262 asymmetric cryptography, or public-key cryptography, on which DNSSEC
263 is based (see the definition of 'asymmetric cryptography' in RFC 4949
264 [RFC4949]). Therefore, this document will use the term 'key' rather
265 loosely. Where it is written that 'a key is used to sign data', it
266 is assumed that the reader understands that it is the private part of
267 the key pair that is used for signing. It is also assumed that the
268 reader understands that the public part of the key pair is published
269 in the DNSKEY Resource Record (DNSKEY RR) and that it is the public
270 part that is used in signature verification.
282Kolkman, et al. Informational [Page 5]
284RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
289 In this document, we will be using a number of time-related terms.
290 The following definitions apply:
292 Signature validity period: The period that a signature is valid. It
293 starts at the (absolute) time specified in the signature inception
294 field of the RRSIG RR and ends at the (absolute) time specified in
295 the expiration field of the RRSIG RR. The document sometimes also
296 uses the term 'validity period', which means the same.
298 Signature publication period: The period that a signature is
299 published. It starts at the time the signature is introduced in
300 the zone for the first time and ends at the time when the
301 signature is removed or replaced with a new signature. After one
302 stops publishing an RRSIG in a zone, it may take a while before
303 the RRSIG has expired from caches and has actually been removed
306 Key effectivity period: The period during which a key pair is
307 expected to be effective. It is defined as the time between the
308 earliest inception time stamp and the last expiration date of any
309 signature made with this key, regardless of any discontinuity in
310 the use of the key. The key effectivity period can span multiple
311 signature validity periods.
313 Maximum/Minimum Zone Time to Live (TTL): The maximum or minimum
314 value of the TTLs from the complete set of RRs in a zone, that are
315 used by validators or resolvers. Note that the minimum TTL is not
316 the same as the MINIMUM field in the SOA RR. See RFC 2308
317 [RFC2308] for more information.
3192. Keeping the Chain of Trust Intact
321 Maintaining a valid chain of trust is important because broken chains
322 of trust will result in data being marked as Bogus (as defined in
323 RFC 4033 [RFC4033] Section 5), which may cause entire (sub)domains to
324 become invisible to verifying clients. The administrators of secured
325 zones need to realize that, to verifying clients, their zone is part
328 As mentioned in the introduction, the procedures herein are intended
329 to ensure that maintenance of zones, such as re-signing or key
330 rollovers, will be transparent to the verifying clients on the
338Kolkman, et al. Informational [Page 6]
340RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
343 Administrators of secured zones will need to keep in mind that data
344 published on an authoritative primary server will not be immediately
345 seen by verifying clients; it may take some time for the data to be
346 transferred to other (secondary) authoritative name servers and
347 clients may be fetching data from caching non-authoritative servers.
348 In this light, note that the time until the data is available on the
349 slave can be negligible when using NOTIFY [RFC1996] and Incremental
350 Zone Transfer (IXFR) [RFC1995]. It increases when Authoritative
351 (full) Zone Transfers (AXFRs) are used in combination with NOTIFY.
352 It increases even more if you rely on the full zone transfers being
353 based only on the SOA timing parameters for refresh.
355 For the verifying clients, it is important that data from secured
356 zones can be used to build chains of trust, regardless of whether the
357 data came directly from an authoritative server, a caching name
358 server, or some middle box. Only by carefully using the available
359 timing parameters can a zone administrator ensure that the data
360 necessary for verification can be obtained.
362 The responsibility for maintaining the chain of trust is shared by
363 administrators of secured zones in the chain of trust. This is most
364 obvious in the case of a 'key compromise' when a tradeoff must be
365 made between maintaining a valid chain of trust and replacing the
366 compromised keys as soon as possible. Then zone administrators will
367 have to decide between keeping the chain of trust intact -- thereby
368 allowing for attacks with the compromised key -- or deliberately
369 breaking the chain of trust and making secured subdomains invisible
370 to security-aware resolvers (also see Section 4.2).
3723. Key Generation and Storage
374 This section describes a number of considerations with respect to the
375 use of keys. For the design of an operational procedure for key
376 generation and storage, a number of decisions need to be made:
378 o Does one differentiate between Zone Signing Keys and Key Signing
379 Keys or is the use of one type of key sufficient?
381 o Are Key Signing Keys (likely to be) in use as trust anchors
384 o What are the timing parameters that are allowed by the operational
387 o What are the cryptographic parameters that fit the operational
394Kolkman, et al. Informational [Page 7]
396RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
399 The following section discusses the considerations that need to be
400 taken into account when making those choices.
4023.1. Operational Motivation for Zone Signing Keys and Key Signing Keys
404 The DNSSEC validation protocol does not distinguish between different
405 types of DNSKEYs. The motivations to differentiate between keys are
406 purely operational; validators will not make a distinction.
408 For operational reasons, described below, it is possible to designate
409 one or more keys to have the role of Key Signing Keys (KSKs). These
410 keys will only sign the apex DNSKEY RRset in a zone. Other keys can
411 be used to sign all the other RRsets in a zone that require
412 signatures. They are referred to as Zone Signing Keys (ZSKs). In
413 cases where the differentiation between the KSK and ZSK is not made,
414 i.e., where keys have the role of both KSK and ZSK, we talk about a
415 Single-Type Signing Scheme.
417 If the two functions are separated, then for almost any method of key
418 management and zone signing, the KSK is used less frequently than the
419 ZSK. Once a DNSKEY RRset is signed with the KSK, all the keys in the
420 RRset can be used as ZSKs. If there has been an event that increases
421 the risk that a ZSK is compromised, it can be simply replaced with a
422 ZSK rollover. The new RRset is then re-signed with the KSK.
424 Changing a key that is a Secure Entry Point (SEP) [RFC4034] for a
425 zone can be relatively expensive, as it involves interaction with
426 third parties: When a key is only pointed to by a Delegation Signer
427 (DS) [RFC4034] record in the parent zone, one needs to complete the
428 interaction with the parent and wait for the updated DS record to
429 appear in the DNS. In the case where a key is configured as a trust
430 anchor, one has to wait until one has sufficient confidence that all
431 trust anchors have been replaced. In fact, it may be that one is not
432 able to reach the complete user-base with information about the key
435 Given the assumption that for KSKs the SEP flag is set, the KSK can
436 be distinguished from a ZSK by examining the flag field in the DNSKEY
437 RR: If the flag field is an odd number, it is a KSK; otherwise, it is
440 There is also a risk that keys can be compromised through theft or
441 loss. For keys that are installed on file-systems of name servers
442 that are connected to the network (e.g., for dynamic updates), that
443 risk is relatively high. Where keys are stored on Hardware Security
444 Modules (HSMs) or stored off-line, such risk is relatively low.
445 However, storing keys off-line or with more limitations on access
446 control has a negative effect on the operational flexibility. By
450Kolkman, et al. Informational [Page 8]
452RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
455 separating the KSK and ZSK functionality, these risks can be managed
456 while making the tradeoff against the involved costs. For example, a
457 KSK can be stored off-line or with more limitations on access control
458 than ZSKs, which need to be readily available for operational
459 purposes such as the addition or deletion of zone data. A KSK stored
460 on a smartcard that is kept in a safe, combined with a ZSK stored on
461 a file-system accessible by operators for daily routine use, may
462 provide better protection against key compromise without losing much
463 operational flexibility. It must be said that some HSMs give the
464 option to have your keys online, giving more protection and hardly
465 affecting the operational flexibility. In those cases, a KSK-ZSK
466 split is not more beneficial than the Single-Type Signing Scheme.
468 It is worth mentioning that there's not much point in obsessively
469 protecting the key if you don't protect the zone files, which also
470 live on the file-systems.
472 Finally, there is a risk of cryptanalysis of the key material. The
473 costs of such analysis are correlated to the length of the key.
474 However, cryptanalysis arguments provide no strong motivation for a
475 KSK/ZSK split. Suppose one differentiates between a KSK and a ZSK,
476 whereby the KSK effectivity period is X times the ZSK effectivity
477 period. Then, in order for the resistance to cryptanalysis to be the
478 same for the KSK and the ZSK, the KSK needs to be X times stronger
479 than the ZSK. Since for all practical purposes X will be somewhere
480 on the order of 10 to 100, the associated key sizes will vary only by
481 about a byte in size for symmetric keys. When translated to
482 asymmetric keys, the size difference is still too insignificant to
483 warrant a key-split; it only marginally affects the packet size and
486 The arguments for differentiation between the ZSK and KSK are weakest
489 o the exposure to risk is low (e.g., when keys are stored on HSMs);
491 o one can be certain that a key is not used as a trust anchor;
493 o maintenance of the various keys cannot be performed through tools
494 (is prone to human error); and
496 o the interaction through the child-parent provisioning chain -- in
497 particular, the timely appearance of a new DS record in the parent
498 zone in emergency situations -- is predictable.
506Kolkman, et al. Informational [Page 9]
508RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
511 If the above arguments hold, then the costs of the operational
512 complexity of a KSK-ZSK split may outweigh the costs of operational
513 flexibility, and choosing a Single-Type Signing Scheme is a
514 reasonable option. In other cases, we advise that the separation
515 between KSKs and ZSKs is made.
5173.2. Practical Consequences of KSK and ZSK Separation
519 A key that acts only as a Zone Signing Key is used to sign all the
520 data except the DNSKEY RRset in a zone on a regular basis. When a
521 ZSK is to be rolled, no interaction with the parent is needed. This
522 allows for a relatively short key effectivity period.
524 A key with only the Key Signing Key role is to be used to sign the
525 DNSKEY RRs in a zone. If a KSK is to be rolled, there may be
526 interactions with other parties. These can include the
527 administrators of the parent zone or administrators of verifying
528 resolvers that have the particular key configured as secure entry
529 points. In the latter case, everyone relying on the trust anchor
530 needs to roll over to the new key, a process that may be subject to
531 stability costs if automated trust anchor rollover mechanisms (e.g.,
532 RFC 5011 [RFC5011]) are not in place. Hence, the key effectivity
533 period of these keys can and should be made much longer.
5353.2.1. Rolling a KSK That Is Not a Trust Anchor
537 There are three schools of thought on rolling a KSK that is not a
540 1. It should be done frequently and regularly (possibly every few
541 months), so that a key rollover remains an operational routine.
543 2. It should be done frequently but irregularly. "Frequently" means
544 every few months, again based on the argument that a rollover is
545 a practiced and common operational routine; "irregular" means
546 with a large jitter, so that third parties do not start to rely
547 on the key and will not be tempted to configure it as a trust
550 3. It should only be done when it is known or strongly suspected
551 that the key can be or has been compromised, or in conjunction
552 with operator change policies and procedures, like when a new
553 algorithm or key storage is required.
555 There is no widespread agreement on which of these three schools of
556 thought is better for different deployments of DNSSEC. There is a
557 stability cost every time a non-anchor KSK is rolled over, but it is
558 possibly low if the communication between the child and the parent is
562Kolkman, et al. Informational [Page 10]
564RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
567 good. On the other hand, the only completely effective way to tell
568 if the communication is good is to test it periodically. Thus,
569 rolling a KSK with a parent is only done for two reasons: to test and
570 verify the rolling system to prepare for an emergency, and in the
571 case of (preventing) an actual emergency.
573 Finally, in most cases a zone administrator cannot be fully certain
574 that the zone's KSK is not in use as a trust anchor somewhere. While
575 the configuration of trust anchors is not the responsibility of the
576 zone administrator, there may be stability costs for the validator
577 administrator that (wrongfully) configured the trust anchor when the
578 zone administrator rolls a KSK.
5803.2.2. Rolling a KSK That Is a Trust Anchor
582 The same operational concerns apply to the rollover of KSKs that are
583 used as trust anchors: If a trust anchor replacement is done
584 incorrectly, the entire domain that the trust anchor covers will
585 become Bogus until the trust anchor is corrected.
587 In a large number of cases, it will be safe to work from the
588 assumption that one's keys are not in use as trust anchors. If a
589 zone administrator publishes a DNSSEC signing policy and/or a DNSSEC
590 practice statement [DNSSEC-DPS], that policy or statement should be
591 explicit regarding whether or not the existence of trust anchors will
592 be taken into account. There may be cases where local policies
593 enforce the configuration of trust anchors on zones that are mission
594 critical (e.g., in enterprises where the trust anchor for the
595 enterprise domain is configured in the enterprise's validator). It
596 is expected that the zone administrators are aware of such
599 One can argue that because of the difficulty of getting all users of
600 a trust anchor to replace an old trust anchor with a new one, a KSK
601 that is a trust anchor should never be rolled unless it is known or
602 strongly suspected that the key has been compromised. In other
603 words, the costs of a KSK rollover are prohibitively high because
604 some users cannot be reached.
606 However, the "operational habit" argument also applies to trust
607 anchor reconfiguration at the clients' validators. If a short key
608 effectivity period is used and the trust anchor configuration has to
609 be revisited on a regular basis, the odds that the configuration
610 tends to be forgotten are smaller. In fact, the costs for those
611 users can be minimized by automating the rollover with RFC 5011
612 [RFC5011] and by rolling the key regularly (and advertising such) so
618Kolkman, et al. Informational [Page 11]
620RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
623 that the operators of validating resolvers will put the appropriate
624 mechanism in place to deal with these stability costs: In other
625 words, budget for these costs instead of incurring them unexpectedly.
627 It is therefore preferable to roll KSKs that are expected to be used
628 as trust anchors on a regular basis if and only if those rollovers
629 can be tracked using standardized (e.g., RFC 5011 [RFC5011])
6323.2.3. The Use of the SEP Flag
634 The so-called SEP [RFC4035] flag can be used to distinguish between
635 keys that are intended to be used as the secure entry point into the
636 zone when building chains of trust, i.e., they are (to be) pointed to
637 by parental DS RRs or configured as a trust anchor.
639 While the SEP flag does not play any role in validation, it is used
640 in practice for operational purposes such as for the rollover
641 mechanism described in RFC 5011 [RFC5011]. The common convention is
642 to set the SEP flag on any key that is used for key exchanges with
643 the parent and/or potentially used for configuration as a trust
644 anchor. Therefore, it is suggested that the SEP flag be set on keys
645 that are used as KSKs and not on keys that are used as ZSKs, while in
646 those cases where a distinction between a KSK and ZSK is not made
647 (i.e., for a Single-Type Signing Scheme), it is suggested that the
648 SEP flag be set on all keys.
650 Note: Some signing tools may assume a KSK/ZSK split and use the
651 (non-)presence of the SEP flag to determine which key is to be used
652 for signing zone data; these tools may get confused when a Single-
653 Type Signing Scheme is used.
6553.3. Key Effectivity Period
657 In general, the available key length sets an upper limit on the key
658 effectivity period. For all practical purposes, it is sufficient to
659 define the key effectivity period based on purely operational
660 requirements and match the key length to that value. Ignoring the
661 operational perspective, a reasonable effectivity period for KSKs
662 that have corresponding DS records in the parent zone is on the order
663 of two decades or longer. That is, if one does not plan to test the
664 rollover procedure, the key should be effective essentially forever
665 and only rolled over in case of emergency.
667 When one opts for a regular key rollover, a reasonable key
668 effectivity period for KSKs that have a parent zone is one year,
669 meaning you have the intent to replace them after 12 months. The key
670 effectivity period is merely a policy parameter and should not be
674Kolkman, et al. Informational [Page 12]
676RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
679 considered a constant value. For example, the real key effectivity
680 period may be a little bit longer than 12 months, because not all
681 actions needed to complete the rollover could be finished in time.
683 As argued above, this annual rollover gives an operational practice
684 of rollovers for both the zone and validator administrators.
685 Besides, in most environments a year is a time span that is easily
686 planned and communicated.
688 Where keys are stored online and the exposure to various threats of
689 compromise is fairly high, an intended key effectivity period of a
690 month is reasonable for Zone Signing Keys.
692 Although very short key effectivity periods are theoretically
693 possible, when replacing keys one has to take into account the
694 rollover considerations discussed in Sections 4.1 and 4.4. Key
695 replacement endures for a couple of Maximum Zone TTLs, depending on
696 the rollover scenario. Therefore, a multiple of Maximum Zone TTL
697 durations is a reasonable lower limit on the key effectivity period.
698 Forcing a shorter key effectivity period will result in an
699 unnecessary and inconveniently large DNSKEY RRset published in the
702 The motivation for having the ZSK's effectivity period shorter than
703 the KSK's effectivity period is rooted in the operational
704 consideration that it is more likely that operators have more
705 frequent read access to the ZSK than to the KSK. Thus, in cases
706 where the ZSK cannot be afforded the same level of protection as the
707 KSK (such as when zone keys are kept online), and where the risk of
708 unauthorized disclosure of the ZSK's private key is not negligible
709 (e.g., when HSMs are not in use), the ZSK's effectivity period should
710 be kept shorter than the KSK's effectivity period.
712 In fact, if the risk of loss, theft, or other compromise is the same
713 for a ZSK and a KSK, there is little reason to choose different
714 effectivity periods for ZSKs and KSKs. And when the split between
715 ZSKs and KSKs is not made, the argument is redundant.
717 There are certainly cases in which the use of a Single-Type Signing
718 Scheme with a long key effectivity period is a good choice, for
719 example, where the costs and risks of compromise, and the costs and
720 risks involved with having to perform an emergency roll, are low.
730Kolkman, et al. Informational [Page 13]
732RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
7353.4. Cryptographic Considerations
7373.4.1. Signature Algorithm
739 At the time of this writing, there are three types of signature
740 algorithms that can be used in DNSSEC: RSA, Digital Signature
741 Algorithm (DSA), and GOST. Proposals for other algorithms are in the
742 making. All three are fully specified in many freely available
743 documents and are widely considered to be patent-free. The creation
744 of signatures with RSA and DSA takes roughly the same time, but DSA
745 is about ten times slower for signature verification. Also note
746 that, in the context of DNSSEC, DSA is limited to a maximum of
749 We suggest the use of RSA/SHA-256 as the preferred signature
750 algorithm and RSA/SHA-1 as an alternative. Both have advantages and
751 disadvantages. RSA/SHA-1 has been deployed for many years, while
752 RSA/SHA-256 has only begun to be deployed. On the other hand, it is
753 expected that if effective attacks on either algorithm appear, they
754 will appear for RSA/SHA-1 first. RSA/MD5 should not be considered
755 for use because RSA/MD5 will very likely be the first common-use
756 signature algorithm to be targeted for an effective attack.
758 At the time of publication, it is known that the SHA-1 hash has
759 cryptanalysis issues, and work is in progress to address them. The
760 use of public-key algorithms based on hashes stronger than SHA-1
761 (e.g., SHA-256) is recommended, if these algorithms are available in
762 implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]).
764 Also, at the time of publication, digital signature algorithms based
765 on Elliptic Curve (EC) Cryptography with DNSSEC (GOST [RFC5933],
766 Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605]) are
767 being standardized and implemented. The use of EC has benefits in
768 terms of size. On the other hand, one has to balance that against
769 the amount of validating resolver implementations that will not
770 recognize EC signatures and thus treat the zone as insecure. Beyond
771 the observation of this tradeoff, we will not discuss this further.
775 This section assumes RSA keys, as suggested in the previous section.
777 DNSSEC signing keys should be large enough to avoid all known
778 cryptographic attacks during the effectivity period of the key. To
779 date, despite huge efforts, no one has broken a regular 1024-bit key;
780 in fact, the best completed attack is estimated to be the equivalent
781 of a 700-bit key. An attacker breaking a 1024-bit signing key would
782 need to expend phenomenal amounts of networked computing power in a
786Kolkman, et al. Informational [Page 14]
788RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
791 way that would not be detected in order to break a single key.
792 Because of this, it is estimated that most zones can safely use
793 1024-bit keys for at least the next ten years. (A 1024-bit
794 asymmetric key has an approximate equivalent strength of a symmetric
797 Depending on local policy (e.g., owners of keys that are used as
798 extremely high value trust anchors, or non-anchor keys that may be
799 difficult to roll over), it may be advisable to use lengths longer
800 than 1024 bits. Typically, the next larger key size used is
801 2048 bits, which has the approximate equivalent strength of a
802 symmetric 112-bit key (RFC 3766 [RFC3766]). Signing and verifying
803 with a 2048-bit key takes longer than with a 1024-bit key. The
804 increase depends on software and hardware implementations, but public
805 operations (such as verification) are about four times slower, while
806 private operations (such as signing) are about eight times slower.
808 Another way to decide on the size of a key to use is to remember that
809 the effort it takes for an attacker to break a 1024-bit key is the
810 same, regardless of how the key is used. If an attacker has the
811 capability of breaking a 1024-bit DNSSEC key, he also has the
812 capability of breaking one of the many 1024-bit Transport Layer
813 Security (TLS) [RFC5246] trust anchor keys that are currently
814 installed in web browsers. If the value of a DNSSEC key is lower to
815 the attacker than the value of a TLS trust anchor, the attacker will
816 use the resources to attack the latter.
818 It is possible that there will be an unexpected improvement in the
819 ability for attackers to break keys and that such an attack would
820 make it feasible to break 1024-bit keys but not 2048-bit keys. If
821 such an improvement happens, it is likely that there will be a huge
822 amount of publicity, particularly because of the large number of
823 1024-bit TLS trust anchors built into popular web browsers. At that
824 time, all 1024-bit keys (both ones with parent zones and ones that
825 are trust anchors) can be rolled over and replaced with larger keys.
827 Earlier documents (including the previous version of this document)
828 urged the use of longer keys in situations where a particular key was
829 "heavily used". That advice may have been true 15 years ago, but it
830 is not true today when using RSA algorithms and keys of 1024 bits or
842Kolkman, et al. Informational [Page 15]
844RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
8473.4.3. Private Key Storage
849 It is preferred that, where possible, zone private keys and the zone
850 file master copy that is to be signed be kept and used in off-line,
851 non-network-connected, physically secure machines only.
852 Periodically, an application can be run to add authentication to a
853 zone by adding RRSIG and NSEC/NSEC3 RRs. Then the augmented file can
854 be transferred to the master.
856 When relying on dynamic update [RFC3007] or any other update
857 mechanism that runs at a regular interval to manage a signed zone, be
858 aware that at least one private key of the zone will have to reside
859 on the master server or reside on an HSM to which the server has
860 access. This key is only as secure as the amount of exposure the
861 server receives to unknown clients and on the level of security of
862 the host. Although not mandatory, one could administer a zone using
863 a "hidden master" scheme to minimize the risk. In this arrangement,
864 the master name server that processes the updates is unavailable to
865 general hosts on the Internet; it is not listed in the NS RRset. The
866 name servers in the NS RRset are able to receive zone updates through
867 IXFR, AXFR, or an out-of-band distribution mechanism, possibly in
868 combination with NOTIFY or another mechanism to trigger zone
871 The ideal situation is to have a one-way information flow to the
872 network to avoid the possibility of tampering from the network.
873 Keeping the zone master on-line on the network and simply cycling it
874 through an off-line signer does not do this. The on-line version
875 could still be tampered with if the host it resides on is
876 compromised. For maximum security, the master copy of the zone file
877 should be off-net and should not be updated based on an unsecured
878 network-mediated communication.
880 The ideal situation may not be achievable because of economic
881 tradeoffs between risks and costs. For instance, keeping a zone file
882 off-line is not practical and will increase the costs of operating a
883 DNS zone. So, in practice, the machines on which zone files are
884 maintained will be connected to a network. Operators are advised to
885 take security measures to shield the master copy against unauthorized
886 access in order to prevent modification of DNS data before it is
898Kolkman, et al. Informational [Page 16]
900RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
903 Similarly, the choice for storing a private key in an HSM will be
904 influenced by a tradeoff between various concerns:
906 o The risks that an unauthorized person has unnoticed read access to
909 o The remaining window of opportunity for the attacker.
911 o The economic impact of the possible attacks (for a TLD, that
912 impact will typically be higher than for an individual user).
914 o The costs of rolling the (compromised) keys. (The cost of rolling
915 a ZSK is lowest, and the cost of rolling a KSK that is in wide use
916 as a trust anchor is highest.)
918 o The costs of buying and maintaining an HSM.
920 For dynamically updated secured zones [RFC3007], both the master copy
921 and the private key that is used to update signatures on updated RRs
922 will need to be on-line.
926 Careful generation of all keys is a sometimes overlooked but
927 absolutely essential element in any cryptographically secure system.
928 The strongest algorithms used with the longest keys are still of no
929 use if an adversary can guess enough to lower the size of the likely
930 key space so that it can be exhaustively searched. Technical
931 suggestions for the generation of random keys will be found in
932 RFC 4086 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A]. In
933 particular, one should carefully assess whether the random number
934 generator used during key generation adheres to these suggestions.
935 Typically, HSMs tend to provide a good facility for key generation.
937 Keys with a long effectivity period are particularly sensitive, as
938 they will represent a more valuable target and be subject to attack
939 for a longer time than short-period keys. It is preferred that long-
940 term key generation occur off-line in a manner isolated from the
941 network via an air gap or, at a minimum, high-level secure hardware.
9433.4.5. Differentiation for 'High-Level' Zones?
945 An earlier version of this document (RFC 4641 [RFC4641]) made a
946 differentiation between key lengths for KSKs used for zones that are
947 high in the DNS hierarchy and those for KSKs used lower down in the
954Kolkman, et al. Informational [Page 17]
956RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
959 This distinction is now considered irrelevant. Longer key lengths
960 for keys higher in the hierarchy are not useful because the
961 cryptographic guidance is that everyone should use keys that no one
962 can break. Also, it is impossible to judge which zones are more or
963 less valuable to an attacker. An attack can only take place if the
964 key compromise goes unnoticed and the attacker can act as a man-in-
965 the-middle (MITM). For example, if example.com is compromised, and
966 the attacker forges answers for somebank.example.com. and sends them
967 out during an MITM, when the attack is discovered it will be simple
968 to prove that example.com has been compromised, and the KSK will be
9714. Signature Generation, Key Rollover, and Related Policies
975 Regardless of whether a zone uses periodic key rollovers or only
976 rolls keys in case of an irregular event, key rollovers are a fact of
977 life when using DNSSEC. Zone administrators who are in the process
978 of rolling their keys have to take into account the fact that data
979 published in previous versions of their zone still lives in caches.
980 When deploying DNSSEC, this becomes an important consideration;
981 ignoring data that may be in caches may lead to loss of service for
984 The most pressing example of this occurs when zone material signed
985 with an old key is being validated by a resolver that does not have
986 the old zone key cached. If the old key is no longer present in the
987 current zone, this validation fails, marking the data Bogus.
988 Alternatively, an attempt could be made to validate data that is
989 signed with a new key against an old key that lives in a local cache,
990 also resulting in data being marked Bogus.
992 The typographic conventions used in the diagrams below are explained
9954.1.1. Zone Signing Key Rollovers
997 If the choice for splitting ZSKs and KSKs has been made, then those
998 two types of keys can be rolled separately, and ZSKs can be rolled
999 without taking into account DS records from the parent or the
1000 configuration of such a key as the trust anchor.
1002 For "Zone Signing Key rollovers", there are two ways to make sure
1003 that during the rollover data still cached can be verified with the
1004 new key sets or newly generated signatures can be verified with the
1005 keys still in caches. One scheme, described in Section 4.1.1.1, uses
1010Kolkman, et al. Informational [Page 18]
1012RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1015 key pre-publication; the other uses double signatures, as described
1016 in Section 4.1.1.2. The pros and cons are described in
10194.1.1.1. Pre-Publish Zone Signing Key Rollover
1021 This section shows how to perform a ZSK rollover without the need to
1022 sign all the data in a zone twice -- the "Pre-Publish key rollover".
1023 This method has advantages in the case of a key compromise. If the
1024 old key is compromised, the new key has already been distributed in
1025 the DNS. The zone administrator is then able to quickly switch to
1026 the new key and remove the compromised key from the zone. Another
1027 major advantage is that the zone size does not double, as is the case
1028 with the Double-Signature ZSK rollover.
1030 Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves
1031 four stages as follows:
1033 ------------------------------------------------------------
1034 initial new DNSKEY new RRSIGs
1035 ------------------------------------------------------------
1037 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
1039 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1040 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
1041 DNSKEY_Z_11 DNSKEY_Z_11
1042 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1043 ------------------------------------------------------------
1045 ------------------------------------------------------------
1047 ------------------------------------------------------------
1055 ------------------------------------------------------------
1057 Figure 1: Pre-Publish Key Rollover
1066Kolkman, et al. Informational [Page 19]
1068RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1071 initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing
1072 Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e.,
1073 it is the Zone Signing Key.
1075 new DNSKEY: DNSKEY_Z_11 is introduced into the key set (note that no
1076 signatures are generated with this key yet, but this does not
1077 secure against brute force attacks on its public key). The
1078 minimum duration of this pre-roll phase is the time it takes for
1079 the data to propagate to the authoritative servers, plus the TTL
1080 value of the key set.
1082 new RRSIGs: At the "new RRSIGs" stage, DNSKEY_Z_11 is used to sign
1083 the data in the zone exclusively (i.e., all the signatures from
1084 DNSKEY_Z_10 are removed from the zone). DNSKEY_Z_10 remains
1085 published in the key set. This way, data that was loaded into
1086 caches from the zone in the "new DNSKEY" step can still be
1087 verified with key sets fetched from this version of the zone. The
1088 minimum time that the key set including DNSKEY_Z_10 is to be
1089 published is the time that it takes for zone data from the
1090 previous version of the zone to expire from old caches, i.e., the
1091 time it takes for this zone to propagate to all authoritative
1092 servers, plus the Maximum Zone TTL value of any of the data in the
1093 previous version of the zone.
1095 DNSKEY removal: DNSKEY_Z_10 is removed from the zone. The key set,
1096 now only containing DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with
1122Kolkman, et al. Informational [Page 20]
1124RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1127 The above scheme can be simplified by always publishing the "future"
1128 key immediately after the rollover. The scheme would look as
1129 follows (we show two rollovers); the future key is introduced in "new
1130 DNSKEY" as DNSKEY_Z_12 and again a newer one, numbered 13, in "new
1133 initial new RRSIGs new DNSKEY
1134 -----------------------------------------------------------------
1136 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1138 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1139 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11
1140 DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12
1141 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1142 ----------------------------------------------------------------
1144 ----------------------------------------------------------------
1145 new RRSIGs (II) new DNSKEY (II)
1146 ----------------------------------------------------------------
1148 RRSIG_Z_12(SOA) RRSIG_Z_12(SOA)
1150 DNSKEY_K_1 DNSKEY_K_1
1151 DNSKEY_Z_11 DNSKEY_Z_12
1152 DNSKEY_Z_12 DNSKEY_Z_13
1153 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1154 ----------------------------------------------------------------
1156 Figure 2: Pre-Publish Zone Signing Key Rollover,
1157 Showing Two Rollovers
1159 Note that the key introduced in the "new DNSKEY" phase is not used
1160 for production yet; the private key can thus be stored in a
1161 physically secure manner and does not need to be 'fetched' every time
1162 a zone needs to be signed.
11644.1.1.2. Double-Signature Zone Signing Key Rollover
1166 This section shows how to perform a ZSK rollover using the double
1167 zone data signature scheme, aptly named "Double-Signature rollover".
1169 During the "new DNSKEY" stage, the new version of the zone file will
1170 need to propagate to all authoritative servers and the data that
1171 exists in (distant) caches will need to expire, requiring at least
1172 the propagation delay plus the Maximum Zone TTL of previous versions
1178Kolkman, et al. Informational [Page 21]
1180RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1183 Double-Signature ZSK rollover involves three stages as follows:
1185 ----------------------------------------------------------------
1186 initial new DNSKEY DNSKEY removal
1187 ----------------------------------------------------------------
1189 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
1190 RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1191 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1192 DNSKEY_Z_10 DNSKEY_Z_10
1193 DNSKEY_Z_11 DNSKEY_Z_11
1194 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1195 ----------------------------------------------------------------
1197 Figure 3: Double-Signature Zone Signing Key Rollover
1199 initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing
1200 Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e.,
1201 it is the Zone Signing Key.
1203 new DNSKEY: At the "new DNSKEY" stage, DNSKEY_Z_11 is introduced
1204 into the key set and all the data in the zone is signed with
1205 DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need to
1206 continue until all data from version 0 (i.e., the version of the
1207 zone data containing SOA_0) of the zone has been replaced in all
1208 secondary servers and then has expired from remote caches. This
1209 will take at least the propagation delay plus the Maximum Zone TTL
1210 of version 0 of the zone.
1212 DNSKEY removal: DNSKEY_Z_10 is removed from the zone, as are all
1213 signatures created with it. The key set, now only containing
1214 DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11.
1216 At every instance, RRSIGs from the previous version of the zone can
1217 be verified with the DNSKEY RRset from the current version and vice
1218 versa. The duration of the "new DNSKEY" phase and the period between
1219 rollovers should be at least the propagation delay to secondary
1220 servers plus the Maximum Zone TTL of the previous version of the
1223 Note that in this example we assumed for simplicity that the zone was
1224 not modified during the rollover. In fact, new data can be
1225 introduced at any time during this period, as long as it is signed
1234Kolkman, et al. Informational [Page 22]
1236RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
12394.1.1.3. Pros and Cons of the Schemes
1241 Pre-Publish key rollover: This rollover does not involve signing the
1242 zone data twice. Instead, before the actual rollover, the new key
1243 is published in the key set and thus is available for
1244 cryptanalysis attacks. A small disadvantage is that this process
1245 requires four stages. Also, the Pre-Publish scheme involves more
1246 parental work when used for KSK rollovers, as explained in
1249 Double-Signature ZSK rollover: The drawback of this approach is that
1250 during the rollover the number of signatures in your zone doubles;
1251 this may be prohibitive if you have very big zones. An advantage
1252 is that it only requires three stages.
12544.1.2. Key Signing Key Rollovers
1256 For the rollover of a Key Signing Key, the same considerations as for
1257 the rollover of a Zone Signing Key apply. However, we can use a
1258 Double-Signature scheme to guarantee that old data (only the apex key
1259 set) in caches can be verified with a new key set and vice versa.
1260 Since only the key set is signed with a KSK, zone size considerations
1263 Note that KSK rollovers and ZSK rollovers are different in the sense
1264 that a KSK rollover requires interaction with the parent (and
1265 possibly replacing trust anchors) and the ensuing delay while waiting
1290Kolkman, et al. Informational [Page 23]
1292RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1295 ---------------------------------------------------------------------
1296 initial new DNSKEY DS change DNSKEY removal
1297 ---------------------------------------------------------------------
1299 SOA_0 -----------------------------> SOA_1 ------------------------>
1300 RRSIG_par(SOA) --------------------> RRSIG_par(SOA) --------------->
1301 DS_K_1 ----------------------------> DS_K_2 ----------------------->
1302 RRSIG_par(DS) ---------------------> RRSIG_par(DS) ---------------->
1305 SOA_0 SOA_1 -----------------------> SOA_2
1306 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA)
1308 DNSKEY_K_1 DNSKEY_K_1 ------------------>
1309 DNSKEY_K_2 ------------------> DNSKEY_K_2
1310 DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10
1311 RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ---------->
1312 RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY)
1313 ---------------------------------------------------------------------
1315 Figure 4: Stages of Deployment for a Double-Signature
1316 Key Signing Key Rollover
1318 initial: Initial version of the zone. The parental DS points to
1319 DNSKEY_K_1. Before the rollover starts, the child will have to
1320 verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
1321 it is needed during the rollover, and we refer to the value as
1324 new DNSKEY: During the "new DNSKEY" phase, the zone administrator
1325 generates a second KSK, DNSKEY_K_2. The key is provided to the
1326 parent, and the child will have to wait until a new DS RR has been
1327 generated that points to DNSKEY_K_2. After that DS RR has been
1328 published on all servers authoritative for the parent's zone, the
1329 zone administrator has to wait at least TTL_DS to make sure that
1330 the old DS RR has expired from caches.
1332 DS change: The parent replaces DS_K_1 with DS_K_2.
1334 DNSKEY removal: DNSKEY_K_1 has been removed.
1336 The scenario above puts the responsibility for maintaining a valid
1337 chain of trust with the child. It also is based on the premise that
1338 the parent only has one DS RR (per algorithm) per zone. An
1339 alternative mechanism has been considered. Using an established
1340 trust relationship, the interaction can be performed in-band, and the
1341 removal of the keys by the child can possibly be signaled by the
1342 parent. In this mechanism, there are periods where there are two DS
1346Kolkman, et al. Informational [Page 24]
1348RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1351 RRs at the parent. This is known as a KSK Double-DS rollover and is
1352 shown in Figure 5. This method has some drawbacks for KSKs. We
1353 first describe the rollover scheme and then indicate these drawbacks.
1355 --------------------------------------------------------------------
1356 initial new DS new DNSKEY DS removal
1357 --------------------------------------------------------------------
1359 SOA_0 SOA_1 ------------------------> SOA_2
1360 RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA)
1361 DS_K_1 DS_K_1 ----------------------->
1362 DS_K_2 -----------------------> DS_K_2
1363 RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS)
1366 SOA_0 -----------------------> SOA_1 ---------------------------->
1367 RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------>
1369 DNSKEY_K_1 ------------------> DNSKEY_K_2 ----------------------->
1370 DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ---------------------->
1371 RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) --------------->
1372 --------------------------------------------------------------------
1374 Figure 5: Stages of Deployment for a Double-DS
1375 Key Signing Key Rollover
1377 When the child zone wants to roll, it notifies the parent during the
1378 "new DS" phase and submits the new key (or the corresponding DS) to
1379 the parent. The parent publishes DS_K_1 and DS_K_2, pointing to
1380 DNSKEY_K_1 and DNSKEY_K_2, respectively. During the rollover ("new
1381 DNSKEY" phase), which can take place as soon as the new DS set
1382 propagated through the DNS, the child replaces DNSKEY_K_1 with
1383 DNSKEY_K_2. If the old key has expired from caches, at the "DS
1384 removal" phase the parent can be notified that the old DS record can
1387 The drawbacks of this scheme are that during the "new DS" phase, the
1388 parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2
1389 using the DNS, as DNSKEY_K_2 is not yet published. Besides, we
1390 introduce a "security lame" key (see Section 4.3.3). Finally, the
1391 child-parent interaction consists of two steps. The "Double
1392 Signature" method only needs one interaction.
1402Kolkman, et al. Informational [Page 25]
1404RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
14074.1.2.1. Special Considerations for RFC 5011 KSK Rollover
1409 The scenario sketched above assumes that the KSK is not in use as a
1410 trust anchor but that validating name servers exclusively depend on
1411 the parental DS record to establish the zone's security. If it is
1412 known that validating name servers have configured trust anchors,
1413 then that needs to be taken into account. Here, we assume that zone
1414 administrators will deploy RFC 5011 [RFC5011] style rollovers.
1416 RFC 5011 style rollovers increase the duration of key rollovers: The
1417 key to be removed must first be revoked. Thus, before the DNSKEY_K_1
1418 removal phase, DNSKEY_K_1 must be published for one more Maximum Zone
1419 TTL with the REVOKE bit set. The revoked key must be self-signed, so
1420 in this phase the DNSKEY RRset must also be signed with DNSKEY_K_1.
14224.1.3. Single-Type Signing Scheme Key Rollover
1424 The rollover of a key when a Single-Type Signing Scheme is used is
1425 subject to the same requirement as the rollover of a KSK or ZSK:
1426 During any stage of the rollover, the chain of trust needs to
1427 continue to validate for any combination of data in the zone as well
1428 as data that may still live in distant caches.
1430 There are two variants for this rollover. Since the choice for a
1431 Single-Type Signing Scheme is motivated by operational simplicity, we
1432 describe the most straightforward rollover scheme first.
1434 -------------------------------------------------------------------
1435 initial new DNSKEY DS change DNSKEY removal
1436 -------------------------------------------------------------------
1438 SOA_0 --------------------------> SOA_1 ---------------------->
1439 RRSIG_par(SOA) -----------------> RRSIG_par(SOA) ------------->
1440 DS_S_1 -------------------------> DS_S_2 --------------------->
1441 RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ---------->
1444 SOA_0 SOA_1 ----------------------> SOA_2
1445 RRSIG_S_1(SOA) RRSIG_S_1(SOA) ------------->
1446 RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA)
1447 DNSKEY_S_1 DNSKEY_S_1 ----------------->
1448 DNSKEY_S_2 -----------------> DNSKEY_S_2
1449 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ---------->
1450 RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY)
1451 -------------------------------------------------------------------
1453 Figure 6: Stages of the Straightforward Rollover
1454 in a Single-Type Signing Scheme
1458Kolkman, et al. Informational [Page 26]
1460RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1463 initial: Parental DS points to DNSKEY_S_1. All RRsets in the zone
1464 are signed with DNSKEY_S_1.
1466 new DNSKEY: A new key (DNSKEY_S_2) is introduced, and all the RRsets
1467 are signed with both DNSKEY_S_1 and DNSKEY_S_2.
1469 DS change: After the DNSKEY RRset with the two keys had time to
1470 propagate into distant caches (that is, the key set exclusively
1471 containing DNSKEY_S_1 has been expired), the parental DS record
1474 DNSKEY removal: After the DS RRset containing DS_S_1 has expired
1475 from distant caches, DNSKEY_S_1 can be removed from the DNSKEY
1478 In this first variant, the new signatures and new public key are
1479 added to the zone. Once they are propagated, the DS at the parent is
1480 switched. If the old DS has expired from the caches, the old
1481 signatures and old public key can be removed from the zone.
1483 This rollover has the drawback that it introduces double signatures
1484 over all data of the zone. Taking these zone size considerations
1485 into account, it is possible to not introduce the signatures made
1486 with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of
1487 DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an
1488 additional stage between the "DS change" and "DNSKEY removal" step:
1489 After the DS RRset containing DS_S_1 has expired from distant caches,
1490 the signatures can be swapped. Only after the new signatures made
1491 with DNSKEY_S_2 have been propagated can the old public key
1492 DNSKEY_S_1 be removed from the DNSKEY RRset.
1494 The second variant of the Single-Type Signing Scheme Key rollover is
1495 the Double-DS rollover. In this variant, one introduces a new DNSKEY
1496 into the key set and submits the new DS to the parent. The new key
1497 is not yet used to sign RRsets. The signatures made with DNSKEY_S_1
1498 are replaced with signatures made with DNSKEY_S_2 at the moment that
1499 DNSKEY_S_2 and DS_S_2 have been propagated.
1514Kolkman, et al. Informational [Page 27]
1516RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1519 -----------------------------------------------------------------------
1520 initial new DS new RRSIG DS removal
1521 -----------------------------------------------------------------------
1523 SOA_0 SOA_1 -------------------------> SOA_2
1524 RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA)
1525 DS_S_1 DS_S_1 ------------------------>
1526 DS_S_2 ------------------------> DS_S_2
1527 RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS)
1530 SOA_0 SOA_1 SOA_2 SOA_3
1531 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA)
1533 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
1534 DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2
1535 RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
1536 -----------------------------------------------------------------------
1538 Figure 7: Stages of Deployment for a Double-DS Rollover in a
1539 Single-Type Signing Scheme
15414.1.4. Algorithm Rollovers
1543 A special class of key rollovers is the one needed for a change of
1544 signature algorithms (either adding a new algorithm, removing an old
1545 algorithm, or both). Additional steps are needed to retain integrity
1546 during this rollover. We first describe the generic case; special
1547 considerations for rollovers that involve trust anchors and single-
1548 type keys are discussed later.
1550 There exist both a conservative and a liberal approach for algorithm
1551 rollover. This has to do with Section 2.2 of RFC 4035 [RFC4035]:
1553 There MUST be an RRSIG for each RRset using at least one DNSKEY
1554 of each algorithm in the zone apex DNSKEY RRset. The apex
1555 DNSKEY RRset itself MUST be signed by each algorithm appearing
1556 in the DS RRset located at the delegating parent (if any).
1558 The conservative approach interprets this section very strictly,
1559 meaning that it expects that every RRset has a valid signature for
1560 every algorithm signaled by the zone apex DNSKEY RRset, including
1561 RRsets in caches. The liberal approach uses a more loose
1562 interpretation of the section and limits the rule to RRsets in the
1563 zone at the authoritative name servers. There is a reasonable
1564 argument for saying that this is valid, because the specific section
1565 is a subsection of Section 2 ("Zone Signing") of RFC 4035.
1570Kolkman, et al. Informational [Page 28]
1572RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1575 When following the more liberal approach, algorithm rollover is just
1576 as easy as a regular Double-Signature KSK rollover (Section 4.1.2).
1577 Note that the Double-DS KSK rollover method cannot be used, since
1578 that would introduce a parental DS of which the apex DNSKEY RRset has
1579 not been signed with the introduced algorithm.
1581 However, there are implementations of validators known to follow the
1582 more conservative approach. Performing a Double-Signature KSK
1583 algorithm rollover will temporarily make your zone appear as Bogus by
1584 such validators during the rollover. Therefore, the rollover
1585 described in this section will explain the stages of deployment and
1586 will assume that the conservative approach is used.
1588 When adding a new algorithm, the signatures should be added first.
1589 After the TTL of RRSIGs has expired and caches have dropped the old
1590 data covered by those signatures, the DNSKEY with the new algorithm
1593 After the new algorithm has been added, the DS record can be
1594 exchanged using Double-Signature KSK rollover.
1596 When removing an old algorithm, the DS for the algorithm should be
1597 removed from the parent zone first, followed by the DNSKEY and the
1598 signatures (in the child zone).
1600 Figure 8 describes the steps.
1626Kolkman, et al. Informational [Page 29]
1628RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1631 ----------------------------------------------------------------
1632 initial new RRSIGs new DNSKEY
1633 ----------------------------------------------------------------
1635 SOA_0 -------------------------------------------------------->
1636 RRSIG_par(SOA) ----------------------------------------------->
1637 DS_K_1 ------------------------------------------------------->
1638 RRSIG_par(DS_K_1) -------------------------------------------->
1642 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
1643 RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1645 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
1647 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
1649 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
1652 ----------------------------------------------------------------
1653 new DS DNSKEY removal RRSIGs removal
1654 ----------------------------------------------------------------
1656 SOA_1 ------------------------------------------------------->
1657 RRSIG_par(SOA) ---------------------------------------------->
1658 DS_K_2 ------------------------------------------------------>
1659 RRSIG_par(DS_K_2) ------------------------------------------->
1662 -------------------> SOA_3 SOA_4
1663 -------------------> RRSIG_Z_10(SOA)
1664 -------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
1666 ------------------->
1667 -------------------> DNSKEY_K_2 DNSKEY_K_2
1668 ------------------->
1669 -------------------> DNSKEY_Z_11 DNSKEY_Z_11
1670 ------------------->
1671 -------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
1672 ----------------------------------------------------------------
1674 Figure 8: Stages of Deployment during an Algorithm Rollover
1682Kolkman, et al. Informational [Page 30]
1684RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1687 initial: Describes the state of the zone before any transition is
1688 done. The number of the keys may vary, but all keys (in DNSKEY
1689 records) for the zone use the same algorithm.
1691 new RRSIGs: The signatures made with the new key over all records in
1692 the zone are added, but the key itself is not. This step is
1693 needed to propagate the signatures created with the new algorithm
1694 to the caches. If this is not done, it is possible for a resolver
1695 to retrieve the new DNSKEY RRset (containing the new algorithm)
1696 but to have RRsets in its cache with signatures created by the old
1697 DNSKEY RRset (i.e., without the new algorithm).
1699 The RRSIG for the DNSKEY RRset does not need to be pre-published
1700 (since these records will travel together) and does not need
1701 special processing in order to keep them synchronized.
1703 new DNSKEY: After the old data has expired from caches, the new key
1704 can be added to the zone.
1706 new DS: After the cache data for the old DNSKEY RRset has expired,
1707 the DS record for the new key can be added to the parent zone and
1708 the DS record for the old key can be removed in the same step.
1710 DNSKEY removal: After the cache data for the old DS RRset has
1711 expired, the old algorithm can be removed. This time, the old key
1712 needs to be removed first, before removing the old signatures.
1714 RRSIGs removal: After the cache data for the old DNSKEY RRset has
1715 expired, the old signatures can also be removed during this step.
1717 Below, we deal with a few special cases of algorithm rollovers:
1719 1: Single-Type Signing Scheme Algorithm rollover: when there is no
1720 differentiation between ZSKs and KSKs (Section 4.1.4.1).
1722 2: RFC 5011 Algorithm rollover: when trust anchors can track the
1723 roll via RFC 5011 style rollover (Section 4.1.4.2).
1725 3: 1 and 2 combined: when a Single-Type Signing Scheme Algorithm
1726 rollover is performed RFC 5011 style (Section 4.1.4.3).
1728 In addition to the narrative below, these special cases are
1729 represented in Figures 12, 13, and 14 in Appendix C.
1738Kolkman, et al. Informational [Page 31]
1740RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
17434.1.4.1. Single-Type Signing Scheme Algorithm Rollover
1745 If one key is used that acts as both ZSK and KSK, the same scheme and
1746 figure as above (Figure 8 in Section 4.1.4) applies, whereby all
1747 DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are
1748 replaced with RRSIG_S_*. All DNSKEY_K_* records are replaced with
1749 DNSKEY_S_*, and all RRSIG_K_* records are replaced with RRSIG_S_*.
1750 The requirement to sign with both algorithms and make sure that old
1751 RRSIGs have the opportunity to expire from distant caches before
1752 introducing the new algorithm in the DNSKEY RRset is still valid.
1754 This is shown in Figure 12 in Appendix C.
17564.1.4.2. Algorithm Rollover, RFC 5011 Style
1758 Trust anchor algorithm rollover is almost as simple as a regular
1759 RFC 5011-based rollover. However, the old trust anchor must be
1760 revoked before it is removed from the zone.
1762 The timeline (see Figure 13 in Appendix C) is similar to that of
1763 Figure 8 above, but after the "new DS" step, an additional step is
1764 required where the DNSKEY is revoked. The details of this step
1765 ("revoke DNSKEY") are shown in Figure 9 below.
1767 ---------------------------------
1769 ---------------------------------
1771 ----------------------------->
1772 ----------------------------->
1773 ----------------------------->
1774 ----------------------------->
1787 ---------------------------------
1789 Figure 9: The Revoke DNSKEY State That Is Added to an Algorithm
1790 Rollover when RFC 5011 Is in Use
1794Kolkman, et al. Informational [Page 32]
1796RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1799 There is one exception to the requirement from RFC 4035 quoted in
1800 Section 4.1.4 above: While all zone data must be signed with an
1801 unrevoked key, it is permissible to sign the key set with a revoked
1802 key. The somewhat esoteric argument is as follows:
1804 Resolvers that do not understand the RFC 5011 REVOKE flag will handle
1805 DNSKEY_K_1_REVOKED the same as if it were DNSKEY_K_1. In other
1806 words, they will handle the revoked key as a normal key, and thus
1807 RRsets signed with this key will validate. As a result, the
1808 signature matches the algorithm listed in the DNSKEY RRset.
1810 Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from the
1811 set of trust anchors. That is okay, since they have already added
1812 DNSKEY_K_2 as the new trust anchor. Thus, algorithm 2 is the only
1813 signaled algorithm by now. That is, we only need RRSIG_K_2(DNSKEY)
1814 to authenticate the DNSKEY RRset, and we are still compliant with
1815 Section 2.2 of RFC 4035: There must be an RRSIG for each RRset using
1816 at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
18184.1.4.3. Single Signing Type Algorithm Rollover, RFC 5011 Style
1820 If a decision is made to perform an RFC 5011 style rollover with a
1821 Single Signing Scheme key, it should be noted that Section 2.1 of
1824 Once the resolver sees the REVOKE bit, it MUST NOT use this key
1825 as a trust anchor or for any other purpose except to validate
1826 the RRSIG it signed over the DNSKEY RRset specifically for the
1827 purpose of validating the revocation.
1829 This means that once DNSKEY_S_1 is revoked, it cannot be used to
1830 validate its signatures over non-DNSKEY RRsets. Thus, those RRsets
1831 should be signed with a shadow key, DNSKEY_Z_10, during the algorithm
1832 rollover. The shadow key can be removed at the same time the revoked
1833 DNSKEY_S_1 is removed from the zone. In other words, the zone must
1834 temporarily fall back to a KSK/ZSK split model during the rollover.
1836 In other words, the rule that at every RRset there must be at least
1837 one signature for each algorithm used in the DNSKEY RRset still
1838 applies. This means that a different key with the same algorithm,
1839 other than the revoked key, must sign the entire zone. Thus, more
1840 operations are needed if the Single-Type Signing Scheme is used.
1841 Before rolling the algorithm, a new key must be introduced with the
1842 same algorithm as the key that is a candidate for revocation. That
1843 key can than temporarily act as a ZSK during the algorithm rollover.
1850Kolkman, et al. Informational [Page 33]
1852RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1855 As with algorithm rollover RFC 5011 style, while all zone data must
1856 be signed with an unrevoked key, it is permissible to sign the key
1857 set with a revoked key using the same esoteric argument given in
1860 The lesson of all of this is that a Single-Type Signing Scheme
1861 algorithm rollover using RFC 5011 is as complicated as the name of
1862 the rollover implies: Reverting to a split-key scheme for the
1863 duration of the rollover may be preferable.
18654.1.4.4. NSEC-to-NSEC3 Algorithm Rollover
1867 A special case is the rollover from an NSEC signed zone to an NSEC3
1868 signed zone. In this case, algorithm numbers are used to signal
1869 support for NSEC3 but they do not mandate the use of NSEC3.
1870 Therefore, NSEC records should remain in the zone until the rollover
1871 to a new algorithm has completed and the new DNSKEY RRset has
1872 populated distant caches, at the end of the "new DNSKEY" stage. At
1873 that point, the validators that have not implemented NSEC3 will treat
1874 the zone as unsecured as soon as they follow the chain of trust to
1875 the DS that points to a DNSKEY of the new algorithm, while validators
1876 that support NSEC3 will happily validate using NSEC. Turning on
1877 NSEC3 can then be done during the "new DS" step: increasing the
1878 serial number, introducing the NSEC3PARAM record to signal that
1879 NSEC3-authenticated data related to denial of existence should be
1880 served, and re-signing the zone.
1882 In summary, an NSEC-to-NSEC3 rollover is an ordinary algorithm
1883 rollover whereby NSEC is used all the time and only after that
1884 rollover finished NSEC3 needs to be deployed. The procedures are
1885 also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155].
18874.1.5. Considerations for Automated Key Rollovers
1889 As keys must be renewed periodically, there is some motivation to
1890 automate the rollover process. Consider the following:
1892 o ZSK rollovers are easy to automate, as only the child zone is
1895 o A KSK rollover needs interaction between the parent and child.
1896 Data exchange is needed to provide the new keys to the parent;
1897 consequently, this data must be authenticated, and integrity must
1898 be guaranteed in order to avoid attacks on the rollover.
1906Kolkman, et al. Informational [Page 34]
1908RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
19114.2. Planning for Emergency Key Rollover
1913 This section deals with preparation for a possible key compromise.
1914 It is advisable to have a documented procedure ready for those times
1915 when a key compromise is suspected or confirmed.
1917 When the private material of one of a zone's keys is compromised, it
1918 can be used by an attacker for as long as a valid trust chain exists.
1919 A trust chain remains intact for
1921 o as long as a signature over the compromised key in the trust chain
1924 o as long as the DS RR in the parent zone points to the
1925 (compromised) key signing the DNSKEY RRset, and
1927 o as long as the (compromised) key is anchored in a resolver and is
1928 used as a starting point for validation (this is generally the
1931 While a trust chain to a zone's compromised key exists, your
1932 namespace is vulnerable to abuse by anyone who has obtained
1933 illegitimate possession of the key. Zone administrators have to make
1934 a decision as to whether the abuse of the compromised key is worse
1935 than having data in caches that cannot be validated. If the zone
1936 administrator chooses to break the trust chain to the compromised
1937 key, data in caches signed with this key cannot be validated.
1938 However, if the zone administrator chooses to take the path of a
1939 regular rollover, during the rollover the malicious key holder can
1940 continue to spoof data so that it appears to be valid.
19424.2.1. KSK Compromise
1944 A compromised KSK can be used to sign the key set of an attacker's
1945 version of the zone. That zone could be used to poison the DNS.
1947 A zone containing a DNSKEY RRset with a compromised KSK is vulnerable
1948 as long as the compromised KSK is configured as the trust anchor or a
1949 DS record in the parent zone points to it.
1951 Therefore, when the KSK has been compromised, the trust anchor or the
1952 parent DS record should be replaced as soon as possible. It is local
1953 policy whether to break the trust chain during the emergency
1954 rollover. The trust chain would be broken when the compromised KSK
1955 is removed from the child's zone while the parent still has a DS
1956 record pointing to the compromised KSK. The assumption is that there
1962Kolkman, et al. Informational [Page 35]
1964RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
1967 is only one DS record at the parent. If there are multiple DS
1968 records, this does not apply, although the chain of trust of this
1969 particular key is broken.
1971 Note that an attacker's version of the zone still uses the
1972 compromised KSK, and the presence of the corresponding DS record in
1973 the parent would cause the data in this zone to appear as valid.
1974 Removing the compromised key would cause the attacker's version of
1975 the zone to appear as valid and the original zone as Bogus.
1976 Therefore, we advise administrators not to remove the KSK before the
1977 parent has a DS record for the new KSK in place.
19794.2.1.1. Emergency Key Rollover Keeping the Chain of Trust Intact
1981 If it is desired to perform an emergency key rollover in a manner
1982 that keeps the chain of trust intact, the timing of the replacement
1983 of the KSK is somewhat critical. The goal is to remove the
1984 compromised KSK as soon as the new DS RR is available at the parent.
1985 This means ensuring that the signature made with a new KSK over the
1986 key set that contains the compromised KSK expires just after the new
1987 DS appears at the parent. Expiration of that signature will cause
1988 expiration of that key set from the caches.
1990 The procedure is as follows:
1992 1. Introduce a new KSK into the key set; keep the compromised KSK in
1993 the key set. Lower the TTL for DNSKEYs so that the DNSKEY RRset
1994 will expire from caches sooner.
1996 2. Sign the key set, with a short validity period. The validity
1997 period should expire shortly after the DS is expected to appear
1998 in the parent and the old DSs have expired from caches. This
1999 provides an upper limit on how long the compromised KSK can be
2000 used in a replay attack.
2002 3. Upload the DS for this new key to the parent.
2004 4. Follow the procedure of the regular KSK rollover: Wait for the DS
2005 to appear at the authoritative servers, and then wait as long as
2006 the TTL of the old DS RRs. If necessary, re-sign the DNSKEY
2007 RRset and modify/extend the expiration time.
2009 5. Remove the compromised DNSKEY RR from the zone, and re-sign the
2010 key set using your "normal" TTL and signature validity period.
2018Kolkman, et al. Informational [Page 36]
2020RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2023 An additional danger of a key compromise is that the compromised key
2024 could be used to facilitate a legitimate-looking DNSKEY/DS rollover
2025 and/or name server changes at the parent. When that happens, the
2026 domain may be in dispute. An authenticated out-of-band and secure
2027 notify mechanism to contact a parent is needed in this case.
2029 Note that this is only a problem when the DNSKEY and/or DS records
2030 are used to authenticate communication with the parent.
20324.2.1.2. Emergency Key Rollover Breaking the Chain of Trust
2034 There are two methods to perform an emergency key rollover in a
2035 manner that breaks the chain of trust. The first method causes the
2036 child zone to appear Bogus to validating resolvers. The other causes
2037 the child zone to appear Insecure. These are described below.
2039 In the method that causes the child zone to appear Bogus to
2040 validating resolvers, the child zone replaces the current KSK with a
2041 new one and re-signs the key set. Next, it sends the DS of the new
2042 key to the parent. Only after the parent has placed the new DS in
2043 the zone is the child's chain of trust repaired. Note that until
2044 that time, the child zone is still vulnerable to spoofing: The
2045 attacker is still in possession of the compromised key that the DS
2048 An alternative method of breaking the chain of trust is by removing
2049 the DS RRs from the parent zone altogether. As a result, the child
2050 zone would become Insecure. After the DS has expired from distant
2051 caches, the keys and signatures are removed from the child zone, new
2052 keys and signatures are introduced, and finally, a new DS is
2053 submitted to the parent.
20554.2.2. ZSK Compromise
2057 Primarily because there is no interaction with the parent required
2058 when a ZSK is compromised, the situation is less severe than with a
2059 KSK compromise. The zone must still be re-signed with a new ZSK as
2060 soon as possible. As this is a local operation and requires no
2061 communication between the parent and child, this can be achieved
2062 fairly quickly. However, one has to take into account that -- just
2063 as with a normal rollover -- the immediate disappearance of the old
2064 compromised key may lead to verification problems. Also note that
2065 until the RRSIG over the compromised ZSK has expired, the zone may
2074Kolkman, et al. Informational [Page 37]
2076RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
20794.2.3. Compromises of Keys Anchored in Resolvers
2081 A key can also be pre-configured in resolvers as a trust anchor. If
2082 trust anchor keys are compromised, the administrators of resolvers
2083 using these keys should be notified of this fact. Zone
2084 administrators may consider setting up a mailing list to communicate
2085 the fact that a SEP key is about to be rolled over. This
2086 communication will of course need to be authenticated by some means,
2087 e.g., by using digital signatures.
2089 End-users faced with the task of updating an anchored key should
2090 always verify the new key. New keys should be authenticated out-of-
2091 band, for example, through the use of an announcement website that is
2092 secured using Transport Layer Security (TLS) [RFC5246].
2096 Stand-by keys are keys that are published in your zone but are not
2097 used to sign RRsets. There are two reasons why someone would want to
2098 use stand-by keys. One is to speed up the emergency key rollover.
2099 The other is to recover from a disaster that leaves your production
2100 private keys inaccessible.
2102 The way to deal with stand-by keys differs for ZSKs and KSKs. To
2103 make a stand-by ZSK, you need to publish its DNSKEY RR. To make a
2104 stand-by KSK, you need to get its DS RR published at the parent.
2106 Assuming you have your normal DNS operation, to prepare stand-by keys
2109 o Generate a stand-by ZSK and KSK. Store them safely in a location
2110 different than the place where the currently used ZSK and KSK are
2113 o Pre-publish the DNSKEY RR of the stand-by ZSK in the zone.
2115 o Pre-publish the DS of the stand-by KSK in the parent zone.
2117 Now suppose a disaster occurs and disables access to the currently
2118 used keys. To recover from that situation, follow these procedures:
2120 o Set up your DNS operations and introduce the stand-by KSK into the
2123 o Post-publish the disabled ZSK and sign the zone with the stand-by
2130Kolkman, et al. Informational [Page 38]
2132RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2135 o After some time, when the new signatures have been propagated, the
2136 old keys, old signatures, and the old DS can be removed.
2138 o Generate a new stand-by key set at a different location and
2139 continue "normal" operation.
21434.3.1. Initial Key Exchanges and Parental Policies Considerations
2145 The initial key exchange is always subject to the policies set by the
2146 parent. It is specifically important in a registry-registrar-
2147 registrant model where a registry maintains the parent zone, and the
2148 registrant (the user of the child-domain name) deals with the
2149 registry through an intermediary called a registrar (see [RFC3375]
2150 for a comprehensive definition). The key material is to be passed
2151 from the DNS operator to the parent via a registrar, where both the
2152 DNS operator and registrar are selected by the registrant and might
2153 be different organizations. When designing a key exchange policy,
2154 one should take into account that the authentication and
2155 authorization mechanisms used during a key exchange should be as
2156 strong as the authentication and authorization mechanisms used for
2157 the exchange of delegation information between the parent and child.
2158 That is, there is no implicit need in DNSSEC to make the
2159 authentication process stronger than it is for regular DNS.
2161 Using the DNS itself as the source for the actual DNSKEY material has
2162 the benefit that it reduces the chances of user error. A DNSKEY
2163 query tool can make use of the SEP bit [RFC4035] to select the proper
2164 key(s) from a DNSSEC key set, thereby reducing the chance that the
2165 wrong DNSKEY is sent. It can validate the self-signature over a key,
2166 thereby verifying the ownership of the private key material.
2167 Fetching the DNSKEY from the DNS ensures that the chain of trust
2168 remains intact once the parent publishes the DS RR indicating that
2169 the child is secure.
2171 Note: Out-of-band verification is still needed when the key material
2172 is fetched for the first time, even via DNS. The parent can never be
2173 sure whether or not the DNSKEY RRs have been spoofed.
2175 With some types of key rollovers, the DNSKEY is not pre-published,
2176 and a DNSKEY query tool is not able to retrieve the successor key.
2177 In this case, the out-of-band method is required. This also allows
2178 the child to determine the digest algorithm of the DS record.
2186Kolkman, et al. Informational [Page 39]
2188RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
21914.3.2. Storing Keys or Hashes?
2193 When designing a registry system, one should consider whether to
2194 store the DNSKEYs and/or the corresponding DSs. Since a child zone
2195 might wish to have a DS published using a message digest algorithm
2196 not yet understood by the registry, the registry can't count on being
2197 able to generate the DS record from a raw DNSKEY. Thus, we suggest
2198 that registry systems should be able to store DS RRs, even if they
2199 also store DNSKEYs (see also "DNSSEC Trust Anchor Configuration and
2200 Maintenance" [DNSSEC-TRUST-ANCHOR]).
2202 The storage considerations also relate to the design of the customer
2203 interface and the method by which data is transferred between the
2204 registrant and registry: Will the child-zone administrator be able to
2205 upload DS RRs with unknown hash algorithms, or does the interface
2206 only allow DNSKEYs? When registries support the Extensible
2207 Provisioning Protocol (EPP) [RFC5910], that can be used for
2208 registrar-registry interactions, since that protocol allows the
2209 transfer of both DS and, optionally, DNSKEY RRs. There is no
2210 standardized way to move the data between the customer and the
2211 registrar. Different registrars have different mechanisms, ranging
2212 from simple web interfaces to various APIs. In some cases, the use
2213 of the DNSSEC extensions to EPP may be applicable.
2215 Having an out-of-band mechanism such as a registry directory (e.g.,
2216 Whois) to find out which keys are used to generate DS Resource
2217 Records for specific owners and/or zones may also help with
22204.3.3. Security Lameness
2222 Security lameness is defined as the state whereby the parent has a DS
2223 RR pointing to a nonexistent DNSKEY RR. Security lameness may occur
2224 temporarily during a Double-DS rollover scheme. However, care should
2225 be taken that not all DS RRs are pointing to a nonexistent DNSKEY RR,
2226 which will cause the child's zone to be marked Bogus by verifying DNS
2229 As part of a comprehensive delegation check, the parent could, at key
2230 exchange time, verify that the child's key is actually configured in
2231 the DNS. However, if a parent does not understand the hashing
2232 algorithm used by the child, the parental checks are limited to only
2233 comparing the key id.
2242Kolkman, et al. Informational [Page 40]
2244RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2247 Child zones should be very careful in removing DNSKEY material --
2248 specifically, SEP keys -- for which a DS RR exists.
2250 Once a zone is "security lame", a fix (e.g., removing a DS RR) will
2251 take time to propagate through the DNS.
22534.3.4. DS Signature Validity Period
2255 Since the DS can be replayed as long as it has a valid signature, a
2256 short signature validity period for the DS RRSIG minimizes the time
2257 that a child is vulnerable in the case of a compromise of the child's
2258 KSK(s). A signature validity period that is too short introduces the
2259 possibility that a zone is marked Bogus in the case of a
2260 configuration error in the signer. There may not be enough time to
2261 fix the problems before signatures expire (this is a generic
2262 argument; also see Section 4.4.2). Something as mundane as zone
2263 administrator unavailability during weekends shows the need for DS
2264 signature validity periods longer than two days. Just like any
2265 signature validity period, we suggest an absolute minimum for the DS
2266 signature validity period of a few days.
2268 The maximum signature validity period of the DS record depends on how
2269 long child zones are willing to be vulnerable after a key compromise.
2270 On the other hand, shortening the DS signature validity period
2271 increases the operational risk for the parent. Therefore, the parent
2272 may have a policy to use a signature validity period that is
2273 considerably longer than the child would hope for.
2275 A compromise between the policy/operational constraints of the parent
2276 and minimizing damage for the child may result in a DS signature
2277 validity period somewhere between a week and several months.
2279 In addition to the signature validity period, which sets a lower
2280 bound on the number of times the zone administrator will need to sign
2281 the zone data and an upper bound on the time that a child is
2282 vulnerable after key compromise, there is the TTL value on the DS
2283 RRs. Shortening the TTL reduces the damage of a successful replay
2284 attack. It does mean that the authoritative servers will see more
2285 queries. But on the other hand, a short TTL lowers the persistence
2286 of DS RRsets in caches, thereby increasing the speed with which
2287 updated DS RRsets propagate through the DNS.
2298Kolkman, et al. Informational [Page 41]
2300RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
23034.3.5. Changing DNS Operators
2305 The parent-child relationship is often described in terms of a
2306 registry-registrar-registrant model, where a registry maintains the
2307 parent zone and the registrant (the user of the child-domain name)
2308 deals with the registry through an intermediary called a registrar
2309 [RFC3375]. Registrants may outsource the maintenance of their DNS
2310 system, including the maintenance of DNSSEC key material, to the
2311 registrar or to another third party, referred to here as the DNS
2314 For various reasons, a registrant may want to move between DNS
2315 operators. How easy this move will be depends principally on the DNS
2316 operator from which the registrant is moving (the losing operator),
2317 as the losing operator has control over the DNS zone and its keys.
2318 The following sections describe the two cases: where the losing
2319 operator cooperates with the new operator (the gaining operator), and
2320 where the two do not cooperate.
23224.3.5.1. Cooperating DNS Operators
2324 In this scenario, it is assumed that the losing operator will not
2325 pass any private key material to the gaining operator (that would
2326 constitute a trivial case) but is otherwise fully cooperative.
2328 In this environment, the change could be made with a Pre-Publish ZSK
2329 rollover, whereby the losing operator pre-publishes the ZSK of the
2330 gaining operator, combined with a Double-Signature KSK rollover where
2331 the two registrars exchange public keys and independently generate a
2332 signature over those key sets that they combine and both publish in
2333 their copy of the zone. Once that is done, they can use their own
2334 private keys to sign any of their zone content during the transfer.
2354Kolkman, et al. Informational [Page 42]
2356RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2359 ------------------------------------------------------------
2360 initial | pre-publish |
2361 ------------------------------------------------------------
2365 ------------------------------------------------------------
2366 Child at A: Child at A: Child at B:
2367 SOA_A0 SOA_A1 SOA_B0
2368 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
2371 RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
2374 DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
2375 DNSKEY_Z_B DNSKEY_Z_B
2376 DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A
2377 DNSKEY_K_B DNSKEY_K_B
2378 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
2379 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
2380 ------------------------------------------------------------
2382 ------------------------------------------------------------
2383 re-delegation | post-migration |
2384 ------------------------------------------------------------
2388 ------------------------------------------------------------
2389 Child at A: Child at B: Child at B:
2391 SOA_A1 SOA_B0 SOA_B1
2392 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
2395 NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS)
2398 DNSKEY_Z_A DNSKEY_Z_A
2399 DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
2400 DNSKEY_K_A DNSKEY_K_A
2401 DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B
2402 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
2403 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
2404 ------------------------------------------------------------
2406 Figure 10: Rollover for Cooperating Operators
2410Kolkman, et al. Informational [Page 43]
2412RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2415 In this figure, A denotes the losing operator and B the gaining
2416 operator. RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is
2417 produced with a KSK, and the appended A or B indicates the producers
2418 of the key pair. "Child at A" is how the zone content is represented
2419 by the losing DNS operator, and "Child at B" is how the zone content
2420 is represented by the gaining DNS operator.
2422 The zone is initially delegated from the parent to the name servers
2423 of operator A. Operator A uses his own ZSK and KSK to sign the zone.
2424 The cooperating operator A will pre-publish the new NS record and the
2425 ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset
2426 generated by the KSK of operator B. Operator B needs to publish the
2427 same DNSKEY RRset. When that DNSKEY RRset has populated the caches,
2428 the re-delegation can be made, which involves adjusting the NS and DS
2429 records in the parent zone to point to operator B. And after all
2430 DNSSEC records related to operator A have expired from the caches,
2431 operator B can stop publishing the keys and signatures belonging to
2432 operator A, and vice versa.
2434 The requirement to exchange signatures has a couple of drawbacks. It
2435 requires more operational overhead, because not only do the operators
2436 have to exchange public keys but they also have to exchange the
2437 signatures of the new DNSKEY RRset. This drawback does not exist if
2438 the Double-Signature KSK rollover is replaced with a Double-DS KSK
2439 rollover. See Figure 15 in Appendix D for the diagram.
2441 Thus, if the registry and registrars allow DS records to be published
2442 that do not point to a published DNSKEY in the child zone, the
2443 Double-DS KSK rollover is preferred (see Figure 5), in combination
2444 with the Pre-Publish ZSK rollover. This does not require sharing the
2445 KSK signatures between the operators, but both operators still have
2446 to publish each other's ZSKs.
24484.3.5.2. Non-Cooperating DNS Operators
2450 In the non-cooperating case, matters are more complicated. The
2451 losing operator may not cooperate and leave the data in the DNS as
2452 is. In extreme cases, the losing operator may become obstructive and
2453 publish a DNSKEY RR with a high TTL and corresponding signature
2454 validity period so that registrar A's DNSKEY could end up in caches
2455 for (in theory at least) decades.
2457 The problem arises when a validator tries to validate with the losing
2458 operator's key and there is no signature material produced with the
2459 losing operator available in the delegation path after re-delegation
2460 from the losing operator to the gaining operator has taken place.
2461 One could imagine a rollover scenario where the gaining operator
2462 takes a copy of all RRSIGs created by the losing operator and
2466Kolkman, et al. Informational [Page 44]
2468RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2471 publishes those in conjunction with its own signatures, but that
2472 would not allow any changes in the zone content. Since a
2473 re-delegation took place, the NS RRset has by definition changed, so
2474 such a rollover scenario will not work. Besides, if zone transfers
2475 are not allowed by the losing operator and NSEC3 is deployed in the
2476 losing operator's zone, then the gaining operator's zone will not
2477 have certainty that all of the losing operator's RRSIGs have been
2480 The only viable operation for the registrant is to have his zone go
2481 Insecure for the duration of the change. The registry should be
2482 asked to remove the DS RR pointing to the losing operator's DNSKEY
2483 and to change the NS RRset to point to the gaining operator. Once
2484 this has propagated through the DNS, the registry should be asked to
2485 insert the DS record pointing to the (newly signed) zone at
2488 Note that some behaviors of resolver implementations may aid in the
2489 process of changing DNS operators:
2491 o TTL sanity checking, as described in RFC 2308 [RFC2308], will
2492 limit the impact of the actions of an obstructive losing operator.
2493 Resolvers that implement TTL sanity checking will use an upper
2494 limit for TTLs on RRsets in responses.
2496 o If RRsets at the zone cut (are about to) expire, the resolver
2497 restarts its search above the zone cut. Otherwise, the resolver
2498 risks continuing to use a name server that might be un-delegated
2501 o Limiting the time that DNSKEYs that seem to be unable to validate
2502 signatures are cached and/or trying to recover from cases where
2503 DNSKEYs do not seem to be able to validate data also reduce the
2504 effects of the problem of non-cooperating registrars.
2506 However, there is no operational methodology to work around this
2507 business issue, and proper contractual relationships between all
2508 involved parties seem to be the only solution to cope with these
2509 problems. It should be noted that in many cases, the problem with
2510 temporary broken delegations already exists when a zone changes from
2511 one DNS operator to another. Besides, it is often the case that when
2512 operators are changed, the services that are referenced by that zone
2513 also change operators, possibly involving some downtime.
2515 In any case, to minimize such problems, the classic configuration is
2516 to have relatively short TTLs on all involved Resource Records. That
2517 will solve many of the problems regarding changes to a zone,
2518 regardless of whether DNSSEC is used.
2522Kolkman, et al. Informational [Page 45]
2524RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2529 Without DNSSEC, all times in the DNS are relative. The SOA fields
2530 REFRESH, RETRY, and EXPIRATION are timers used to determine the time
2531 that has elapsed after a slave server synchronized with a master
2532 server. The TTL value and the SOA RR minimum TTL parameter [RFC2308]
2533 are used to determine how long a forwarder should cache data (or
2534 negative responses) after it has been fetched from an authoritative
2535 server. By using a signature validity period, DNSSEC introduces the
2536 notion of an absolute time in the DNS. Signatures in DNSSEC have an
2537 expiration date after which the signature is marked as invalid and
2538 the signed data is to be considered Bogus.
2540 The considerations in this section are all qualitative and focused on
2541 the operational and managerial issues. A more thorough quantitative
2542 analysis of rollover timing parameters can be found in "DNSSEC Key
2543 Timing Considerations" [DNSSEC-KEY-TIMING].
25454.4.1. Time Considerations
2547 Because of the expiration of signatures, one should consider the
2550 o We suggest that the Maximum Zone TTL value of your zone data be
2551 smaller than your signature validity period.
2553 If the TTL duration was similar to that of the signature
2554 validity period, then all RRsets fetched during the validity
2555 period would be cached until the signature expiration time.
2556 Section 8.1 of RFC 4033 [RFC4033] suggests that "the resolver
2557 may use the time remaining before expiration of the signature
2558 validity period of a signed RRset as an upper bound for the
2559 TTL". As a result, the query load on authoritative servers
2560 would peak at the signature expiration time, as this is also
2561 the time at which records simultaneously expire from caches.
2563 Having a TTL that is at least a few times smaller than your
2564 signature validity period avoids query load peaks.
2566 o We suggest that the signature publication period end at least one
2567 Maximum Zone TTL duration (but preferably a minimum of a few days)
2568 before the end of the signature validity period.
2570 Re-signing a zone shortly before the end of the signature
2571 validity period may cause the simultaneous expiration of data
2572 from caches. This in turn may lead to peaks in the load on
2573 authoritative servers. To avoid this, schemes are deployed
2578Kolkman, et al. Informational [Page 46]
2580RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2583 whereby the zone is periodically visited for a re-signing
2584 operation, and those signatures that are within a so-called
2585 Refresh Period from signature expiration are recreated. Also
2586 see Section 4.4.2 below.
2588 In the case of an operational error, you would have one Maximum
2589 Zone TTL duration to resolve the problem. Re-signing a zone a
2590 few days before the end of the signature validity period
2591 ensures that the signatures will survive at least a (long)
2592 weekend in case of such operational havoc. This is called the
2593 Refresh Period (see Section 4.4.2).
2595 o We suggest that the Minimum Zone TTL be long enough to both fetch
2596 and verify all the RRs in the trust chain. In workshop
2597 environments, it has been demonstrated [NIST-Workshop] that a low
2598 TTL (under 5 to 10 minutes) caused disruptions because of the
2599 following two problems:
2601 1. During validation, some data may expire before the validation
2602 is complete. The validator should be able to keep all data
2603 until it is completed. This applies to all RRs needed to
2604 complete the chain of trust: DS, DNSKEY, RRSIG, and the final
2605 answers, i.e., the RRset that is returned for the initial
2608 2. Frequent verification causes load on recursive name servers.
2609 Data at delegation points, DS, DNSKEY, and RRSIG RRs benefits
2610 from caching. The TTL on those should be relatively long.
2611 Data at the leaves in the DNS tree has less impact on
2612 recursive name servers.
2614 o Slave servers will need to be able to fetch newly signed zones
2615 well before the RRSIGs in the zone served by the slave server pass
2616 their signature expiration time.
2618 When a slave server is out of synchronization with its master
2619 and data in a zone is signed by expired signatures, it may be
2620 better for the slave server not to give out any answer.
2622 Normally, a slave server that is not able to contact a master
2623 server for an extended period will expire a zone. When that
2624 happens, the server will respond differently to queries for
2625 that zone. Some servers issue SERVFAIL, whereas others turn
2626 off the AA bit in the answers. The time of expiration is set
2627 in the SOA record and is relative to the last successful
2628 refresh between the master and the slave servers. There exists
2629 no coupling between the signature expiration of RRSIGs in the
2630 zone and the expire parameter in the SOA.
2634Kolkman, et al. Informational [Page 47]
2636RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2639 If the server serves a DNSSEC-secured zone, then it may happen
2640 that the signatures expire well before the SOA expiration timer
2641 counts down to zero. It is not possible to completely prevent
2642 this by modifying the SOA parameters.
2644 However, the effects can be minimized where the SOA expiration
2645 time is equal to or shorter than the Refresh Period (see
2648 The consequence of an authoritative server not being able to
2649 update a zone for an extended period of time is that signatures
2650 may expire. In this case, non-secure resolvers will continue
2651 to be able to resolve data served by the particular slave
2652 servers, while security-aware resolvers will experience
2653 problems because of answers being marked as Bogus.
2655 We suggest that the SOA expiration timer be approximately one
2656 third or a quarter of the signature validity period. It will
2657 allow problems with transfers from the master server to be
2658 noticed before signatures time out.
2660 We also suggest that operators of name servers that supply
2661 secondary services develop systems to identify upcoming
2662 signature expirations in zones they slave and take appropriate
2663 action where such an event is detected.
2665 When determining the value for the expiration parameter, one
2666 has to take the following into account: What are the chances
2667 that all secondaries expire the zone? How quickly can the
2668 administrators of the secondary servers be reached to load a
2669 valid zone? These questions are not DNSSEC-specific but may
2670 influence the choice of your signature validity periods.
26724.4.2. Signature Validity Periods
26744.4.2.1. Maximum Value
2676 The first consideration for choosing a maximum signature validity
2677 period is the risk of a replay attack. For low-value, long-term
2678 stable resources, the risks may be minimal, and the signature
2679 validity period may be several months. Although signature validity
2680 periods of many years are allowed, the same "operational habit"
2681 arguments as those given in Section 3.2.2 play a role: When a zone is
2682 re-signed with some regularity, then zone administrators remain
2683 conscious of the operational necessity of re-signing.
2690Kolkman, et al. Informational [Page 48]
2692RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
26954.4.2.2. Minimum Value
2697 The minimum value of the signature validity period is set for the
2698 time by which one would like to survive operational failure in
2699 provisioning: At what time will a failure be noticed, and at what
2700 time is action expected to be taken? By answering these questions,
2701 availability of zone administrators during (long) weekends or time
2702 taken to access backup media can be taken into account. The result
2703 could easily suggest a minimum signature validity period of a few
2706 Note, however, that the argument above is assuming that zone data has
2707 just been signed and published when the problem occurred. In
2708 practice, it may be that a zone is signed according to a frequency
2709 set by the Re-Sign Period, whereby the signer visits the zone content
2710 and only refreshes signatures that are within a given amount of time
2711 (the Refresh Period) of expiration. The Re-Sign Period must be
2712 smaller than the Refresh Period in order for zone data to be signed
2713 in a timely fashion.
2715 If an operational problem occurs during re-signing, then the
2716 signatures in the zone to expire first are the ones that have been
2717 generated longest ago. In the worst case, these signatures are the
2718 Refresh Period minus the Re-Sign Period away from signature
2721 To make matters slightly more complicated, some signers vary the
2722 signature validity period over a small range (the jitter interval) so
2723 that not all signatures expire at the same time.
2725 In other words, the minimum signature validity period is set by first
2726 choosing the Refresh Period (usually a few days), then defining the
2727 Re-Sign Period in such a way that the Refresh Period minus the
2728 Re-Sign Period, minus the maximum jitter sets the time in which
2729 operational havoc can be resolved.
2746Kolkman, et al. Informational [Page 49]
2748RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2751 The relationship between signature times is illustrated in Figure 11.
2753 Inception Signing Expiration
2756 |------------------|---------------------------------|.....|.....|
2760 | Inception offset | |
2761 |<---------------->| Validity Period |
2762 | |<---------------------------------------->|
2765 Inception Signing Reuse Reuse Reuse New Expiration
2766 time time RRSIG time
2768 |------------------|-------------------------------|-------|
2770 <-----> <-----> <-----> <----->
2777 Figure 11: Signature Timing Parameters
2779 Note that in the figure the validity of the signature starts shortly
2780 before the signing time. That is done to deal with validators that
2781 might have some clock skew. This is called the inception offset, and
2782 it should be chosen so that false negatives are minimized to a
27854.4.2.3. Differentiation between RRsets
2787 It is possible to vary signature validity periods between signatures
2788 over different RRsets in the zone. In practice, this could be done
2789 when zones contain highly volatile data (which may be the case in
2790 dynamic-update environments). Note, however, that the risk of replay
2791 (e.g., by stale secondary servers) should be the leading factor in
2792 determining the signature validity period, since the TTLs on the data
2793 itself are still the primary parameter for cache expiry.
2795 In some cases, the risk of replaying existing data might be different
2796 from the risk of replaying the denial of data. In those cases, the
2797 signature validity period on NSEC or NSEC3 records may be tweaked
2802Kolkman, et al. Informational [Page 50]
2804RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2807 When a zone contains secure delegations, then a relatively short
2808 signature validity period protects the child against replay attacks
2809 in the case where the child's key is compromised (see Section 4.3.4).
2810 Since there is a higher operational risk for the parent registry when
2811 choosing a short validity period and a higher operational risk for
2812 the child when choosing a long validity period, some (price)
2813 differentiation may occur for validity periods between individual DS
2814 RRs in a single zone.
2816 There seem to be no other arguments for differentiation in validity
28195. "Next Record" Types
2821 One of the design tradeoffs made during the development of DNSSEC was
2822 to separate the signing and serving operations instead of performing
2823 cryptographic operations as DNS requests are being serviced. It is
2824 therefore necessary to create records that cover the very large
2825 number of nonexistent names that lie between the names that do exist.
2827 There are two mechanisms to provide authenticated proof of
2828 nonexistence of domain names in DNSSEC: a clear-text one and an
2829 obfuscated-data one. Each mechanism:
2831 o includes a list of all the RRTYPEs present, which can be used to
2832 prove the nonexistence of RRTYPEs at a certain name;
2834 o stores only the name for which the zone is authoritative (that is,
2835 glue in the zone is omitted); and
2837 o uses a specific RRTYPE to store information about the RRTYPEs
2838 present at the name: The clear-text mechanism uses NSEC, and the
2839 obfuscated-data mechanism uses NSEC3.
28415.1. Differences between NSEC and NSEC3
2843 The clear-text mechanism (NSEC) is implemented using a sorted linked
2844 list of names in the zone. The obfuscated-data mechanism (NSEC3) is
2845 similar but first hashes the names using a one-way hash function,
2846 before creating a sorted linked list of the resulting (hashed)
2849 The NSEC record requires no cryptographic operations aside from the
2850 validation of its associated signature record. It is human readable
2851 and can be used in manual queries to determine correct operation.
2852 The disadvantage is that it allows for "zone walking", where one can
2853 request all the entries of a zone by following the linked list of
2854 NSEC RRs via the "Next Domain Name" field. Though all agree that DNS
2858Kolkman, et al. Informational [Page 51]
2860RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2863 data is accessible through query mechanisms, for some zone
2864 administrators this behavior is undesirable for policy, regulatory,
2867 Furthermore, NSEC requires a signature over every RR in the zone
2868 file, thereby ensuring that any denial of existence is
2869 cryptographically signed. However, in a large zone file containing
2870 many delegations, very few of which are to signed zones, this may
2871 produce unacceptable additional overhead, especially where insecure
2872 delegations are subject to frequent updates (a typical example might
2873 be a TLD operator with few registrants using secure delegations).
2874 NSEC3 allows intervals between two secure delegations to "opt out",
2875 in which case they may contain one or more insecure delegations, thus
2876 reducing the size and cryptographic complexity of the zone at the
2877 expense of the ability to cryptographically deny the existence of
2878 names in a specific span.
2880 The NSEC3 record uses a hashing method of the requested name. To
2881 increase the workload required to guess entries in the zone, the
2882 number of hashing iterations can be specified in the NSEC3 record.
2883 Additionally, a salt can be specified that also modifies the hashes.
2884 Note that NSEC3 does not give full protection against information
2885 leakage from the zone (you can still derive the size of the zone,
2886 which RRTYPEs are in there, etc.).
2890 The first motivation to deploy NSEC3 -- prevention of zone
2891 enumeration -- only makes sense when zone content is not highly
2892 structured or trivially guessable. Highly structured zones, such as
2893 in-addr.arpa., ip6.arpa., and e164.arpa., can be trivially enumerated
2894 using ordinary DNS properties, while for small zones that only
2895 contain records in the apex of the zone and a few common names such
2896 as "www" or "mail", guessing zone content and proving completeness is
2897 also trivial when using NSEC3. In these cases, the use of NSEC is
2898 preferred to ease the work required by signers and validating
2901 For large zones where there is an implication of "not readily
2902 available" names, such as those where one has to sign a
2903 non-disclosure agreement before obtaining it, NSEC3 is preferred.
2904 The second reason to consider NSEC3 is "Opt-Out", which can reduce
2905 the number of NSEC3 records required. This is discussed further
2906 below (Section 5.3.4).
2914Kolkman, et al. Informational [Page 52]
2916RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
29195.3. NSEC3 Parameters
2921 NSEC3 is controlled by a number of parameters, some of which can be
2922 varied: This section discusses the choice of those parameters.
29245.3.1. NSEC3 Algorithm
2926 The NSEC3 hashing algorithm is performed on the Fully Qualified
2927 Domain Name (FQDN) in its uncompressed form. This ensures that brute
2928 force work done by an attacker for one FQDN cannot be reused for
2929 another FQDN attack, as these entries are by definition unique.
2931 At the time of this writing, there is only one NSEC3 hash algorithm
2932 defined. [RFC5155] specifically states: "When specifying a new hash
2933 algorithm for use with NSEC3, a transition mechanism MUST also be
2934 defined". Therefore, this document does not consider NSEC3 hash
2935 algorithm transition.
29375.3.2. NSEC3 Iterations
2939 One of the concerns with NSEC3 is that a pre-calculated dictionary
2940 attack could be performed in order to assess whether or not certain
2941 domain names exist within a zone. Two mechanisms are introduced in
2942 the NSEC3 specification to increase the costs of such dictionary
2943 attacks: iterations and salt.
2945 The iterations parameter defines the number of additional times the
2946 hash function has been performed. A higher value results in greater
2947 resiliency against dictionary attacks, at a higher computational cost
2948 for both the server and resolver.
2950 RFC 5155 Section 10.3 [RFC5155] considers the tradeoffs between
2951 incurring cost during the signing process and imposing costs to the
2952 validating name server, while still providing a reasonable barrier
2953 against dictionary attacks. It provides useful limits of iterations
2954 for a given RSA key size. These are 150 iterations for 1024-bit
2955 keys, 500 iterations for 2048-bit keys, and 2,500 iterations for
2956 4096-bit keys. Choosing a value of 100 iterations is deemed to be a
2957 sufficiently costly, yet not excessive, value: In the worst-case
2958 scenario, the performance of name servers would be halved, regardless
2959 of key size [NSEC3-HASH-PERF].
2970Kolkman, et al. Informational [Page 53]
2972RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
2977 While the NSEC3 iterations parameter increases the cost of hashing a
2978 dictionary word, the NSEC3 salt reduces the lifetime for which that
2979 calculated hash can be used. A change of the salt value by the zone
2980 administrator would cause an attacker to lose all pre-calculated work
2983 There must be a complete NSEC3 chain using the same salt value, that
2984 matches the salt value in the NSEC3PARAM record. NSEC3 salt changes
2985 do not need special rollover procedures. Since changing the salt
2986 requires that all the NSEC3 records be regenerated and thus requires
2987 generating new RRSIGs over these NSEC3 records, it makes sense to
2988 align the change of the salt with a change of the Zone Signing Key,
2989 as that process in itself already usually requires that all RRSIGs be
2990 regenerated. If there is no critical dependency on incremental
2991 signing and the zone can be signed with little effort, there is no
2992 need for such alignment.
2996 The Opt-Out mechanism was introduced to allow for a gradual
2997 introduction of signed records in zones that contain mostly
2998 delegation records. The use of the Opt-Out flag changes the meaning
2999 of the NSEC3 span from authoritative denial of the existence of names
3000 within the span to proof that DNSSEC is not available for the
3001 delegations within the span. This allows for the addition or removal
3002 of the delegations covered by the span without recalculating or
3003 re-signing RRs in the NSEC3 RR chain.
3005 Opt-Out is specified to be used only over delegation points and will
3006 therefore only bring relief to zones with a large number of insecure
3007 delegations. This consideration typically holds for large TLDs and
3008 similar zones; in most other circumstances, Opt-Out should not be
3009 deployed. Further considerations can be found in Section 12.2 of
30126. Security Considerations
3014 DNSSEC adds data origin authentication and data integrity to the DNS,
3015 using digital signatures over Resource Record sets. DNSSEC does not
3016 protect against denial-of-service attacks, nor does it provide
3017 confidentiality. For more general security considerations related to
3018 DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034], and
3026Kolkman, et al. Informational [Page 54]
3028RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3031 This document tries to assess the operational considerations to
3032 maintain a stable and secure DNSSEC service. When performing key
3033 rollovers, it is important to keep in mind that it takes time for the
3034 data to be propagated to the verifying clients. It is also important
3035 to note that this data may be cached. Not taking into account the
3036 'data propagation' properties in the DNS may cause validation
3037 failures, because cached data may mismatch data fetched from the
3038 authoritative servers; this will make secured zones unavailable to
3039 security-aware resolvers.
3043 Significant parts of the text of this document are copied from
3044 RFC 4641 [RFC4641]. That document was edited by Olaf Kolkman and
3045 Miek Gieben. Other people that contributed or were otherwise
3046 involved in that work were, in random order: Rip Loomis, Olafur
3047 Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van
3048 Rein, Tim McGinnis, Gilles Guette, Olivier Courtay, Sam Weiler, Jelte
3049 Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman,
3050 Marcos Sanz, Peter Koch, Mike StJohns, Emma Bretherick, Adrian
3051 Bedford, Lindy Foster, and O. Courtay.
3053 For this version of the document, we would like to acknowledge people
3054 who were actively involved in the compilation of the document. In
3055 random order: Mark Andrews, Patrik Faltstrom, Tony Finch, Alfred
3056 Hoenes, Bill Manning, Scott Rose, Wouter Wijngaards, Antoin
3057 Verschuren, Marc Lampo, George Barwood, Sebastian Castro, Suresh
3058 Krishnaswamy, Eric Rescorla, Stephen Morris, Olafur Gudmundsson,
3059 Ondrej Sury, and Rickard Bellgrim.
3063 Significant contributions to this document were from:
3065 Paul Hoffman, who contributed on the choice of cryptographic
3066 parameters and addressing some of the trust anchor issues;
3068 Jelte Jansen, who provided the initial text in Section 4.1.4;
3070 Paul Wouters, who provided the initial text for Section 5, and
3071 Alex Bligh, who improved it.
3073 The figure in Section 4.4.2 was adapted from the OpenDNSSEC user
3082Kolkman, et al. Informational [Page 55]
3084RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
30899.1. Normative References
3091 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
3092 STD 13, RFC 1034, November 1987.
3094 [RFC1035] Mockapetris, P., "Domain names - implementation and
3095 specification", STD 13, RFC 1035, November 1987.
3097 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3098 Rose, "DNS Security Introduction and Requirements",
3099 RFC 4033, March 2005.
3101 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3102 Rose, "Resource Records for the DNS Security Extensions",
3103 RFC 4034, March 2005.
3105 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3106 Rose, "Protocol Modifications for the DNS Security
3107 Extensions", RFC 4035, March 2005.
3109 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
3110 (DS) Resource Records (RRs)", RFC 4509, May 2006.
3112 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
3113 Security (DNSSEC) Hashed Authenticated Denial of
3114 Existence", RFC 5155, March 2008.
3116 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
3117 and RRSIG Resource Records for DNSSEC", RFC 5702,
31209.2. Informative References
3122 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
3125 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
3126 Changes (DNS NOTIFY)", RFC 1996, August 1996.
3128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3129 Requirement Levels", BCP 14, RFC 2119, March 1997.
3131 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
3132 NCACHE)", RFC 2308, March 1998.
3138Kolkman, et al. Informational [Page 56]
3140RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3143 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
3144 Update", RFC 3007, November 2000.
3146 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol
3147 Requirements", RFC 3375, September 2002.
3149 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
3150 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
3151 RFC 3766, April 2004.
3153 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
3154 Requirements for Security", BCP 106, RFC 4086, June 2005.
3156 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
3157 RFC 4641, September 2006.
3159 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
3160 RFC 4949, August 2007.
3162 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
3163 Trust Anchors", RFC 5011, September 2007.
3165 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
3166 Security Extensions Mapping for the Extensible
3167 Provisioning Protocol (EPP)", RFC 5910, May 2010.
3169 [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST
3170 Signature Algorithms in DNSKEY and RRSIG Resource Records
3171 for DNSSEC", RFC 5933, July 2010.
3173 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
3174 Signature Algorithm (DSA) for DNSSEC", RFC 6605,
3178 Rose, S., "NIST DNSSEC workshop notes", July 2001,
3179 <http://www.ietf.org/mail-archive/web/dnsop/current/
3183 Barker, E. and J. Kelsey, "Recommendation for Random
3184 Number Generation Using Deterministic Random Bit
3185 Generators", NIST Special Publication 800-90A,
3188 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
3189 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
3194Kolkman, et al. Informational [Page 57]
3196RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3200 Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
3201 Timing Considerations", Work in Progress, July 2012.
3204 Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
3205 Framework for DNSSEC Policies and DNSSEC Practice
3206 Statements", Work in Progress, November 2012.
3208 [DNSSEC-TRUST-ANCHOR]
3209 Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor
3210 Configuration and Maintenance", Work in Progress,
3214 Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs
3215 document 2010-002, March 2010.
3250Kolkman, et al. Informational [Page 58]
3252RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3255Appendix A. Terminology
3257 In this document, there is some jargon used that is defined in other
3258 documents. In most cases, we have not copied the text from the
3259 documents defining the terms but have given a more elaborate
3260 explanation of the meaning. Note that these explanations should not
3261 be seen as authoritative.
3263 Anchored key: A DNSKEY configured in resolvers around the globe.
3264 This key is hard to update, hence the term 'anchored'.
3266 Bogus: Also see Section 5 of RFC 4033 [RFC4033]. An RRset in DNSSEC
3267 is marked "Bogus" when a signature of an RRset does not validate
3270 Key rollover: A key rollover (also called key supercession in some
3271 environments) is the act of replacing one key pair with another at
3272 the end of a key effectivity period.
3274 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is
3275 used exclusively for signing the apex key set. The fact that a
3276 key is a KSK is only relevant to the signing tool.
3278 Key size: The term 'key size' can be substituted by 'modulus size'
3279 throughout the document for RSA keys. It is mathematically more
3280 correct to use modulus size for RSA keys, but as this is a
3281 document directed at operators we feel more at ease with the term
3284 Private and public keys: DNSSEC secures the DNS through the use of
3285 public-key cryptography. Public-key cryptography is based on the
3286 existence of two (mathematically related) keys, a public key and a
3287 private key. The public keys are published in the DNS by the use
3288 of the DNSKEY Resource Record (DNSKEY RR). Private keys should
3291 Refresh Period: The period before the expiration time of the
3292 signature, during which the signature is refreshed by the signer.
3294 Re-Sign Period: This refers to the frequency with which a signing
3295 pass on the zone is performed. The Re-Sign Period defines when
3296 the zone is exposed to the signer. And on the signer, not all
3297 signatures in the zone have to be regenerated: That depends on the
3306Kolkman, et al. Informational [Page 59]
3308RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3311 Secure Entry Point (SEP) key: A KSK that has a DS record in the
3312 parent zone pointing to it or that is configured as a trust
3313 anchor. Although not required by the protocol, we suggest that
3314 the SEP flag [RFC4034] be set on these keys.
3316 Self-signature: This only applies to signatures over DNSKEYs; a
3317 signature made with DNSKEY x over DNSKEY x is called a self-
3318 signature. Note: Without further information, self-signatures
3319 convey no trust. They are useful to check the authenticity of the
3320 DNSKEY, i.e., they can be used as a hash.
3322 Signing jitter: A random variation in the signature validity period
3323 of RRSIGs in a zone to prevent all of them from expiring at the
3326 Signer: The system that has access to the private key material and
3327 signs the Resource Record sets in a zone. A signer may be
3328 configured to sign only parts of the zone, e.g., only those RRsets
3329 for which existing signatures are about to expire.
3331 Singing the zone file: The term used for the event where an
3332 administrator joyfully signs its zone file while producing melodic
3335 Single-Type Signing Scheme: A signing scheme whereby the distinction
3336 between Zone Signing Keys and Key Signing Keys is not made.
3338 Zone administrator: The 'role' that is responsible for signing a
3339 zone and publishing it on the primary authoritative server.
3341 Zone Signing Key (ZSK): A key that is used for signing all data in a
3342 zone (except, perhaps, the DNSKEY RRset). The fact that a key is
3343 a ZSK is only relevant to the signing tool.
3362Kolkman, et al. Informational [Page 60]
3364RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3367Appendix B. Typographic Conventions
3369 The following typographic conventions are used in this document:
3371 Key notation: A key is denoted by DNSKEY_x_y, where x is an
3372 identifier for the type of key: K for Key Signing Key, Z for Zone
3373 Signing Key, and S when there is no distinction made between KSKs
3374 and ZSKs but the key is used as a secure entry point. The 'y'
3375 denotes a number or an identifier; y could be thought of as the
3378 RRsets ignored: If the signatures of non-DNSKEY RRsets have the same
3379 parameters as the SOA, then those are not mentioned; e.g., in the
3380 example below, the SOA is signed with the same parameters as the
3381 foo.example.com A RRset and the latter is therefore ignored in the
3382 abbreviated notation.
3384 RRset notations: RRs are only denoted by the type. All other
3385 information -- owner, class, rdata, and TTL -- is left out. Thus:
3386 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRsets are a
3387 list of RRs. An example of this would be "A1, A2", specifying the
3388 RRset containing two "A" records. This could again be abbreviated
3391 Signature notation: Signatures are denoted as RRSIG_x_y(type), which
3392 means that the RRset with the specific RRTYPE 'type' is signed
3393 with DNSKEY_x_y. Signatures in the parent zone are denoted as
3396 SOA representation: SOAs are represented as SOA_x, where x is the
3399 DS representation: DSs are represented as DS_x_y, where x and y are
3400 identifiers similar to the key notation: x is an identifier for
3401 the type of key the DS record refers to; y is the 'key id' of the
3404 Zone representation: Using the above notation we have simplified the
3405 representation of a signed zone by leaving out all unnecessary
3406 details, such as the names, and by representing all data by
3418Kolkman, et al. Informational [Page 61]
3420RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3423 Using this notation, the following signed zone:
3425 example.com. 3600 IN SOA ns1.example.com. olaf.example.net. (
3427 450 ; refresh (7 minutes 30 seconds)
3428 600 ; retry (10 minutes)
3429 345600 ; expire (4 days)
3430 300 ; minimum (5 minutes)
3432 3600 RRSIG SOA 5 2 3600 20120824013000 (
3433 20100424013000 14 example.com.
3434 NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo
3436 OMY3rTMA2qorupQXjQ== )
3437 3600 NS ns1.example.com.
3438 3600 NS ns2.example.com.
3439 3600 NS ns3.example.com.
3440 3600 RRSIG NS 5 2 3600 20120824013000 (
3441 20100424013000 14 example.com.
3442 p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz
3444 +SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4
3445 zAgaJM/MeG08KpeHhg== )
3446 3600 TXT "Net::DNS domain"
3447 3600 RRSIG TXT 5 2 3600 20120824013000 (
3448 20100424013000 14 example.com.
3449 o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp
3451 BcQ1o99vwn+IS4+J1g== )
3452 300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY
3453 300 RRSIG NSEC 5 2 300 20120824013000 (
3454 20100424013000 14 example.com.
3455 JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+
3457 PkXNI/Vgf4t3xZaIyw== )
3458 3600 DNSKEY 256 3 5 (
3459 AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX
3461 sAuryjQ/HFa5r4mrbhkJ
3463 3600 DNSKEY 257 3 5 (
3464 AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO
3466 oy88Nh+u2c9HF1tw0naH
3474Kolkman, et al. Informational [Page 62]
3476RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3479 3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
3480 20100424013000 14 example.com.
3481 HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U
3483 QhhmMwV3tIxJk2eDRQ== )
3484 3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
3485 20100424013000 15 example.com.
3486 P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE
3488 JWL70YiUnUG3m9OL9w== )
3489 foo.example.com. 3600 IN A 192.0.2.2
3490 3600 RRSIG A 5 3 3600 20120824013000 (
3491 20100424013000 14 example.com.
3492 xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO
3494 JPV/SA4BkoFxIcPrDQ== )
3495 300 NSEC example.com. A RRSIG NSEC
3496 300 RRSIG NSEC 5 3 300 20120824013000 (
3497 20100424013000 14 example.com.
3498 Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF
3500 Qe000JyzObxx27pY8A== )
3502 is reduced to the following representation:
3505 RRSIG_Z_14(SOA_2005092303)
3511 The rest of the zone data has the same signature as the SOA record,
3512 i.e., an RRSIG created with DNSKEY_K_14.
3530Kolkman, et al. Informational [Page 63]
3532RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3535Appendix C. Transition Figures for Special Cases of Algorithm Rollovers
3537 The figures in this appendix complement and illustrate the special
3538 cases of algorithm rollovers as described in Section 4.1.4.
3540 ----------------------------------------------------------------
3541 initial new RRSIGs new DNSKEY
3542 ----------------------------------------------------------------
3544 SOA_0 -------------------------------------------------------->
3545 RRSIG_par(SOA) ----------------------------------------------->
3546 DS_S_1 ------------------------------------------------------->
3547 RRSIG_par(DS_S_1) -------------------------------------------->
3551 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA)
3552 RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3554 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
3556 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
3557 RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3559 ----------------------------------------------------------------
3560 new DS DNSKEY removal RRSIGs removal
3561 ----------------------------------------------------------------
3563 SOA_1 ------------------------------------------------------->
3564 RRSIG_par(SOA) ---------------------------------------------->
3565 DS_S_2 ------------------------------------------------------>
3566 RRSIG_par(DS_S_2) ------------------------------------------->
3569 -------------------> SOA_3 SOA_4
3570 -------------------> RRSIG_S_1(SOA)
3571 -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3573 ------------------->
3574 -------------------> DNSKEY_S_2 DNSKEY_S_2
3575 -------------------> RRSIG_S_1(DNSKEY)
3576 -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3577 ----------------------------------------------------------------
3579 Figure 12: Single-Type Signing Scheme Algorithm Roll
3581 Also see Section 4.1.4.1.
3586Kolkman, et al. Informational [Page 64]
3588RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3591 ----------------------------------------------------------------
3592 initial new RRSIGs new DNSKEY
3593 ----------------------------------------------------------------
3595 SOA_0 -------------------------------------------------------->
3596 RRSIG_par(SOA) ----------------------------------------------->
3597 DS_K_1 ------------------------------------------------------->
3598 RRSIG_par(DS_K_1) -------------------------------------------->
3602 RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
3603 RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
3605 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
3607 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1
3609 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
3612 ----------------------------------------------------------------
3613 new DS revoke DNSKEY DNSKEY removal
3614 ----------------------------------------------------------------
3616 SOA_1 ------------------------------------------------------->
3617 RRSIG_par(SOA) ---------------------------------------------->
3618 DS_K_2 ------------------------------------------------------>
3619 RRSIG_par(DS_K_2) ------------------------------------------->
3622 -------------------> SOA_3 SOA_4
3623 -------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
3624 -------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
3626 -------------------> DNSKEY_K_1_REVOKED
3627 -------------------> DNSKEY_K_2 DNSKEY_K_2
3628 ------------------->
3629 -------------------> DNSKEY_Z_2 DNSKEY_Z_2
3630 -------------------> RRSIG_K_1(DNSKEY)
3631 -------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
3642Kolkman, et al. Informational [Page 65]
3644RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3647 ----------------------------------------------------------------
3649 ----------------------------------------------------------------
3651 ------------------------------------->
3652 ------------------------------------->
3653 ------------------------------------->
3654 ------------------------------------->
3665 ----------------------------------------------------------------
3667 Figure 13: RFC 5011 Style Algorithm Roll
3669 Also see Section 4.1.4.2.
3672 ----------------------------------------------------------------
3673 initial new RRSIGs new DNSKEY
3674 ----------------------------------------------------------------
3676 SOA_0 -------------------------------------------------------->
3677 RRSIG_par(SOA) ----------------------------------------------->
3678 DS_S_1 ------------------------------------------------------->
3679 RRSIG_par(DS_S_1) -------------------------------------------->
3684 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
3685 RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3687 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
3688 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
3690 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
3691 RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3698Kolkman, et al. Informational [Page 66]
3700RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3703 ----------------------------------------------------------------
3704 new DS revoke DNSKEY DNSKEY removal
3705 ----------------------------------------------------------------
3707 SOA_1 ------------------------------------------------------->
3708 RRSIG_par(SOA) ---------------------------------------------->
3709 DS_S_2 ------------------------------------------------------>
3710 RRSIG_par(DS_S_2) ------------------------------------------->
3713 -------------------> SOA_3 SOA_4
3715 -------------------> RRSIG_Z_10(SOA)
3716 -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
3718 -------------------> DNSKEY_S_1_REVOKED
3719 -------------------> DNSKEY_Z_10
3720 -------------------> DNSKEY_S_2 DNSKEY_S_2
3721 -------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
3722 -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
3724 ----------------------------------------------------------------
3726 ----------------------------------------------------------------
3728 ------------------------------------->
3729 ------------------------------------->
3730 ------------------------------------->
3731 ------------------------------------->
3744 ----------------------------------------------------------------
3746 Figure 14: RFC 5011 Algorithm Roll in a Single-Type
3747 Signing Scheme Environment
3749 Also see Section 4.1.4.3.
3754Kolkman, et al. Informational [Page 67]
3756RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3759Appendix D. Transition Figure for Changing DNS Operators
3761 The figure in this Appendix complements and illustrates the special
3762 case of changing DNS operators as described in Section 4.3.5.1.
3810Kolkman, et al. Informational [Page 68]
3812RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3815 ------------------------------------------------------------
3816 new DS | pre-publish |
3817 ------------------------------------------------------------
3821 ------------------------------------------------------------
3822 Child at A: Child at A: Child at B:
3823 SOA_A0 SOA_A1 SOA_B0
3824 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
3827 RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
3830 DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
3831 DNSKEY_Z_B DNSKEY_Z_B
3832 DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
3833 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
3834 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
3835 ------------------------------------------------------------
3837 ------------------------------------------------------------
3838 re-delegation | post-migration |
3839 ------------------------------------------------------------
3843 ------------------------------------------------------------
3844 Child at A: Child at B: Child at B:
3846 SOA_A1 SOA_B0 SOA_B1
3847 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
3850 NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS)
3853 DNSKEY_Z_A DNSKEY_Z_A
3854 DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
3855 DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B
3856 RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
3857 ------------------------------------------------------------
3859 Figure 15: An Alternative Rollover Approach for Cooperating Operators
3866Kolkman, et al. Informational [Page 69]
3868RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3871Appendix E. Summary of Changes from RFC 4641
3873 This document differs from RFC 4641 [RFC4641] in the following ways:
3875 o Addressed the errata listed on
3876 <http://www.rfc-editor.org/errata_search.php?rfc=4641>.
3878 o Recommended RSA/SHA-256 in addition to RSA/SHA-1.
3880 o Did a complete rewrite of Section 3.5 of RFC 4641 (Section 3.4.2
3881 of this document), removing the table and suggesting a key size of
3882 1024 for keys in use for less than 8 years, issued up to at least
3885 o Removed the KSK for high-level zones consideration.
3887 o Added text on algorithm rollover.
3889 o Added text on changing (non-cooperating) DNS registrars.
3891 o Did a significant rewrite of Section 3, whereby the argument is
3892 made that the timescales for rollovers are made purely on
3893 operational arguments.
3897 o Introduced Single-Type Signing Scheme terminology and made the
3898 arguments for the choice of a Single-Type Signing Scheme more
3901 o Added a section about stand-by keys.
3922Kolkman, et al. Informational [Page 70]
3924RFC 6781 DNSSEC Operational Practices, Version 2 December 2012
3935 EMail: olaf@nlnetlabs.nl
3936 URI: http://www.nlnetlabs.nl
3939 W. (Matthijs) Mekking
3945 EMail: matthijs@nlnetlabs.nl
3946 URI: http://www.nlnetlabs.nl
3955 EMail: miek.gieben@sidn.nl
3956 URI: http://www.sidn.nl
3978Kolkman, et al. Informational [Page 71]