idnits 2.17.1 draft-ietf-dnsop-rfc4641bis-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2441 has weird spacing: '...Hoffman for h...' == Line 2444 has weird spacing: '... Jansen who p...' == Line 2446 has weird spacing: '...Wouters who p...' == Line 2449 has weird spacing: '...escorla whose...' == Line 2452 has weird spacing: '... Morris who m...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 11, 2012) is 4245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-dnssec-key-timing-03 == Outdated reference: A later version (-11) exists of draft-ietf-dnsop-dnssec-dps-framework-08 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP O. Kolkman 3 Internet-Draft W. Mekking 4 Obsoletes: 4641 (if approved) NLnet Labs 5 Intended status: Informational R. Gieben 6 Expires: March 15, 2013 SIDN Labs 7 September 11, 2012 9 DNSSEC Operational Practices, Version 2 10 draft-ietf-dnsop-rfc4641bis-13 12 Abstract 14 This document describes a set of practices for operating the DNS with 15 security extensions (DNSSEC). The target audience is zone 16 administrators deploying DNSSEC. 18 The document discusses operational aspects of using keys and 19 signatures in the DNS. It discusses issues of key generation, key 20 storage, signature generation, key rollover, and related policies. 22 This document obsoletes RFC 4641 as it covers more operational ground 23 and gives more up-to-date requirements with respect to key sizes and 24 the DNSSEC operations. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on March 15, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 7 80 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 7 81 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 9 82 3. Key Generation and Storage . . . . . . . . . . . . . . . . . . 10 83 3.1. Operational Motivation for Zone Signing Keys and Key 84 Signing Keys . . . . . . . . . . . . . . . . . . . . . . . 10 85 3.2. Practical Consequences of KSK and ZSK Separation . . . . . 12 86 3.2.1. Rolling a KSK that is not a trust anchor . . . . . . . 12 87 3.2.2. Rolling a KSK that is a trust anchor . . . . . . . . . 13 88 3.2.3. The use of the SEP flag . . . . . . . . . . . . . . . 14 89 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 15 90 3.4. Cryptographic Considerations . . . . . . . . . . . . . . . 16 91 3.4.1. Signature Algorithm . . . . . . . . . . . . . . . . . 16 92 3.4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . 17 93 3.4.3. Private Key Storage . . . . . . . . . . . . . . . . . 18 94 3.4.4. Key Generation . . . . . . . . . . . . . . . . . . . . 19 95 3.4.5. Differentiation for 'High-Level' Zones? . . . . . . . 19 96 4. Signature Generation, Key Rollover, and Related Policies . . . 21 97 4.1. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 21 98 4.1.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 21 99 4.1.1.1. Pre-Publish Zone Signing Key Rollover . . . . . . 21 100 4.1.1.2. Double Signature Zone Signing Key Rollover . . . . 24 101 4.1.1.3. Pros and Cons of the Schemes . . . . . . . . . . . 25 102 4.1.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 25 103 4.1.2.1. Special Considerations for RFC 5011 KSK 104 rollover . . . . . . . . . . . . . . . . . . . . . 27 105 4.1.3. Rollover for a Single Type Signing Scheme Key 106 Rollover . . . . . . . . . . . . . . . . . . . . . . . 28 107 4.1.4. Algorithm rollovers . . . . . . . . . . . . . . . . . 30 108 4.1.4.1. Single Type Signing Scheme Algorithm Rollover . . 34 109 4.1.4.2. Algorithm rollover, RFC 5011 style . . . . . . . . 34 110 4.1.4.3. Single Signing Type Algorithm Rollover, RFC 111 5011 style . . . . . . . . . . . . . . . . . . . . 36 112 4.1.4.4. NSEC to NSEC3 algorithm rollover . . . . . . . . . 36 113 4.1.5. Considerations for Automated Key Rollovers . . . . . . 37 114 4.2. Planning for Emergency Key Rollover . . . . . . . . . . . 37 115 4.2.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 38 116 4.2.1.1. Emergency Key Rollover Keeping the Chain of 117 Trust Intact . . . . . . . . . . . . . . . . . . . 38 118 4.2.1.2. Emergency Key Rollover Breaking the Chain of 119 Trust . . . . . . . . . . . . . . . . . . . . . . 39 120 4.2.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 40 121 4.2.3. Compromises of Keys Anchored in Resolvers . . . . . . 40 122 4.2.4. Stand-by Keys . . . . . . . . . . . . . . . . . . . . 40 123 4.3. Parent Policies . . . . . . . . . . . . . . . . . . . . . 41 124 4.3.1. Initial Key Exchanges and Parental Policies 125 Considerations . . . . . . . . . . . . . . . . . . . . 41 126 4.3.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 42 127 4.3.3. Security Lameness . . . . . . . . . . . . . . . . . . 42 128 4.3.4. DS Signature Validity Period . . . . . . . . . . . . . 43 129 4.3.5. Changing DNS Operators . . . . . . . . . . . . . . . . 44 130 4.3.5.1. Cooperating DNS operators . . . . . . . . . . . . 44 131 4.3.5.2. Non Cooperating DNS Operators . . . . . . . . . . 46 132 4.4. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 48 133 4.4.1. Time Considerations . . . . . . . . . . . . . . . . . 48 134 4.4.2. Signature Validity Periods . . . . . . . . . . . . . . 50 135 4.4.2.1. Maximum Value . . . . . . . . . . . . . . . . . . 50 136 4.4.2.2. Minimum Value . . . . . . . . . . . . . . . . . . 51 137 4.4.2.3. Differentiation between RRsets . . . . . . . . . . 52 138 5. Next Record type . . . . . . . . . . . . . . . . . . . . . . . 54 139 5.1. Differences between NSEC and NSEC3 . . . . . . . . . . . . 54 140 5.2. NSEC or NSEC3 . . . . . . . . . . . . . . . . . . . . . . 55 141 5.3. NSEC3 parameters . . . . . . . . . . . . . . . . . . . . . 55 142 5.3.1. NSEC3 Algorithm . . . . . . . . . . . . . . . . . . . 55 143 5.3.2. NSEC3 Iterations . . . . . . . . . . . . . . . . . . . 56 144 5.3.3. NSEC3 Salt . . . . . . . . . . . . . . . . . . . . . . 56 145 5.3.4. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . 57 146 6. Security Considerations . . . . . . . . . . . . . . . . . . . 58 147 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 59 148 8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 60 149 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 150 9.1. Normative References . . . . . . . . . . . . . . . . . . . 61 151 9.2. Informative References . . . . . . . . . . . . . . . . . . 61 152 Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 64 153 Appendix B. Typographic Conventions . . . . . . . . . . . . . . . 66 154 Appendix C. Transition Figures for Special Case Algorithm 155 Rollovers . . . . . . . . . . . . . . . . . . . . . . 69 156 Appendix D. Transition Figure for Changing DNS Operators . . . . 75 157 Appendix E. Summary of Changes from RFC 4641 . . . . . . . . . . 77 158 Appendix F. Document Editing History . . . . . . . . . . . . . . 78 159 F.1. draft-ietf-dnsop-rfc4641-00 . . . . . . . . . . . . . . . 78 160 F.2. version 0->1 . . . . . . . . . . . . . . . . . . . . . . . 78 161 F.3. version 1->2 . . . . . . . . . . . . . . . . . . . . . . . 79 162 F.4. version 2->3 . . . . . . . . . . . . . . . . . . . . . . . 79 163 F.5. version 3->4 . . . . . . . . . . . . . . . . . . . . . . . 80 164 F.6. version 4->5 . . . . . . . . . . . . . . . . . . . . . . . 80 165 F.7. version 5->6 . . . . . . . . . . . . . . . . . . . . . . . 80 166 F.8. version 6->7 . . . . . . . . . . . . . . . . . . . . . . . 81 167 F.9. version 7->8 . . . . . . . . . . . . . . . . . . . . . . . 81 168 F.10. version 8->9 . . . . . . . . . . . . . . . . . . . . . . . 81 169 F.11. version 9->10 . . . . . . . . . . . . . . . . . . . . . . 82 170 F.12. version 10->11 . . . . . . . . . . . . . . . . . . . . . . 82 171 F.13. version 11->12 . . . . . . . . . . . . . . . . . . . . . . 82 172 F.14. version 12->13 . . . . . . . . . . . . . . . . . . . . . . 82 173 F.15. Subversion information . . . . . . . . . . . . . . . . . . 82 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 83 176 1. Introduction 178 This document describes how to run a DNS Security (DNSSEC)-enabled 179 environment. It is intended for operators who have knowledge of the 180 DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to 181 deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035 182 [RFC4035] and RFC 5155 [RFC5155]). The focus of the document is on 183 serving authoritative DNS information and is aimed at zone owners, 184 name server operators, registries, registrars and registrants. It 185 assumes that there is no direct relation between those entities and 186 the operators of validating recursive name servers (validators). 188 During workshops and early operational deployment, operators and 189 system administrators have gained experience about operating the DNS 190 with security extensions (DNSSEC). This document translates these 191 experiences into a set of practices for zone administrators. 192 Although the DNS Root has been signed since July 15, 2010 and now 193 more than 80 secure delegations are provisioned in the root, at the 194 time of writing there still exists relatively little experience with 195 DNSSEC in production environments below the top-level domain (TLD) 196 level; this document should therefore explicitly not be seen as 197 representing 'Best Current Practices'. Instead, it describes the 198 decisions that should be made when deploying DNSSEC, gives the 199 choices available for each one, and provides some operational 200 guidelines. The document does not give strong recommendations. That 201 may be subject for a future version of this document. 203 The procedures herein are focused on the maintenance of signed zones 204 (i.e., signing and publishing zones on authoritative servers). It is 205 intended that maintenance of zones such as re-signing or key 206 rollovers be transparent to any verifying clients. 208 The structure of this document is as follows. In Section 2, we 209 discuss the importance of keeping the "chain of trust" intact. 210 Aspects of key generation and storage of keys are discussed in 211 Section 3; the focus in this section is mainly on the security of the 212 private part of the key(s). Section 4 describes considerations 213 concerning the public part of the keys. Section 4.1 and Section 4.2 214 deal with the rollover, or replacement, of keys. Section 4.3 215 discusses considerations on how parents deal with their children's 216 public keys in order to maintain chains of trust. Section 4.4 covers 217 all kinds of timing issues around key publication. Section 5 covers 218 the considerations regarding selecting and using NSEC or NSEC3 219 [RFC5155]. 221 The typographic conventions used in this document are explained in 222 Appendix B. 224 Since we describe operational suggestions and there are no protocol 225 specifications, the RFC 2119 [RFC2119] language does not apply to 226 this document, though we do use quotes from other documents that do 227 include the RFC 2119 language. 229 This document obsoletes RFC 4641 [RFC4641]. 231 1.1. The Use of the Term 'key' 233 It is assumed that the reader is familiar with the concept of 234 asymmetric keys on which DNSSEC is based (public key cryptography RFC 235 4949 [RFC4949]). Therefore, this document will use the term 'key' 236 rather loosely. Where it is written that 'a key is used to sign 237 data' it is assumed that the reader understands that it is the 238 private part of the key pair that is used for signing. It is also 239 assumed that the reader understands that the public part of the key 240 pair is published in the DNSKEY Resource Record and that it is the 241 public part that is used in signature verification. 243 1.2. Time Definitions 245 In this document, we will be using a number of time-related terms. 246 The following definitions apply: 248 Signature validity period: The period that a signature is valid. It 249 starts at the (absolute) time specified in the signature inception 250 field of the RRSIG RR and ends at the (absolute) time specified in 251 the expiration field of the RRSIG RR. The document sometimes also 252 uses the term "validity period", which means the same. 254 Signature publication period: The period that a signature is 255 published. It starts at the time the signature is introduced in 256 the zone for the first time and ends at the time when the 257 signature is removed or replaced with a new signature. After one 258 stops publishing an RRSIG in a zone, it may take a while before 259 the RRSIG has expired from caches and has actually been removed 260 from the DNS. 262 Key effectivity period: The period during which a key pair is 263 expected to be effective. It is defined as the time between the 264 earliest inception time stamp and the last expiration date of any 265 signature made with this key, regardless of any discontinuity in 266 the use of the key. The key effectivity period can span multiple 267 signature validity periods. 269 Maximum/Minimum Zone Time to Live (TTL): The maximum or minimum 270 value of the TTLs from the complete set of RRs in a zone, that are 271 used by validators or resolvers. Note that the minimum TTL is not 272 the same as the MINIMUM field in the SOA RR. See RFC 2308 273 [RFC2308] for more information. 275 2. Keeping the Chain of Trust Intact 277 Maintaining a valid chain of trust is important because broken chains 278 of trust will result in data being marked as Bogus (as defined in RFC 279 4033 [RFC4033] Section 5), which may cause entire (sub)domains to 280 become invisible to verifying clients. The administrators of secured 281 zones need to realize that, to verifying clients, their zone is part 282 of a chain of trust. 284 As mentioned in the introduction, the procedures herein are intended 285 to ensure that maintenance of zones, such as re-signing or key 286 rollovers, will be transparent to the verifying clients on the 287 Internet. 289 Administrators of secured zones will need to keep in mind that data 290 published on an authoritative primary server will not be immediately 291 seen by verifying clients; it may take some time for the data to be 292 transferred to other (secondary) authoritative name servers and 293 clients may be fetching data from caching non-authoritative servers. 294 In this light, note that the time until the data is available on the 295 slave can be negligible when using NOTIFY [RFC1996] and incremental 296 transfer (IXFR) [RFC1995]. It increases when full zone transfers 297 (AXFR) are used in combination with NOTIFY. It increases even more 298 if you rely on the full zone transfers being based only on the SOA 299 timing parameters for refresh. 301 For the verifying clients, it is important that data from secured 302 zones can be used to build chains of trust regardless of whether the 303 data came directly from an authoritative server, a caching name 304 server, or some middle box. Only by carefully using the available 305 timing parameters can a zone administrator ensure that the data 306 necessary for verification can be obtained. 308 The responsibility for maintaining the chain of trust is shared by 309 administrators of secured zones in the chain of trust. This is most 310 obvious in the case of a 'key compromise' when a trade-off must be 311 made between maintaining a valid chain of trust and replacing the 312 compromised keys as soon as possible. Then zone administrators will 313 have to decide between keeping the chain of trust intact - thereby 314 allowing for attacks with the compromised key - or deliberately 315 breaking the chain of trust and making secured subdomains invisible 316 to security-aware resolvers (also see Section 4.2). 318 3. Key Generation and Storage 320 This section describes a number of considerations with respect to the 321 use of keys. For the design of an operational procedure for key 322 generation and storage, a number of decisions need to be made: 324 o Does one differentiate between Zone Signing Keys and Key Signing 325 Keys or is the use of one type of key sufficient? 327 o Are Key Signing Keys (likely to be) in use as trust anchors 328 [RFC4033]? 330 o What are the timing parameters that are allowed by the operational 331 requirements? 333 o What are the cryptographic parameters that fit the operational 334 need? 336 The following section discusses the considerations that need to be 337 taken into account when making those choices. 339 3.1. Operational Motivation for Zone Signing Keys and Key Signing Keys 341 The DNSSEC validation protocol does not distinguish between different 342 types of DNSKEYs. The motivations to differentiate between keys are 343 purely operational; validators will not make a distinction. 345 For operational reasons, described below, it is possible to designate 346 one or more keys to have the role of Key Signing Keys (KSKs). These 347 keys will only sign the apex DNSKEY RRset in a zone. Other keys can 348 be used to sign all the other RRsets in a zone that require 349 signatures. They are referred to as Zone Signing Keys (ZSKs). In 350 cases where the differentiation between KSK and ZSK is not made, keys 351 have both the role of KSK and ZSK, we talk about a Single Type 352 Signing Scheme. 354 If the two functions are separated, then for almost any method of key 355 management and zone signing, the KSK is used less frequently than the 356 ZSK. Once a DNSKEY RRset is signed with the KSK, all the keys in the 357 RRset can be used as ZSKs. If there has been an event that increases 358 the risk that a ZSK is compromised, it can be simply replaced with a 359 ZSK rollover. The new RRset is then re-signed with the KSK. 361 Changing a key that is a secure entry point (SEP) [RFC4034] for a 362 zone can be relatively expensive as it involves interaction with 363 third parties: when a key is only pointed to by a delegation signer 364 (DS) [RFC4034] record in the parent zone, one needs to complete the 365 interaction with the parent and wait for the updated DS record to 366 appear in the DNS. In the case where a key is configured as a trust 367 anchor, one has to wait until one has sufficient confidence that all 368 trust anchors have been replaced. In fact, it may be that one is not 369 able to reach the complete user-base with information about the key 370 rollover. 372 Given the assumption that for KSKs the SEP flag is set, the KSK can 373 be distinguished from a ZSK by examining the flag field in the DNSKEY 374 RR: If the flag field is an odd number it is a KSK; otherwise it is a 375 ZSK. 377 There is also a risk that keys can be compromised through theft or 378 loss. For keys that are installed on file-systems of name servers 379 that are connected to the network (e.g. for dynamic updates), that 380 risk is relatively high. Where keys are stored on Hardware Security 381 Modules (HSMs) or stored off-line, such risk is relatively low. 382 However, storing keys off-line or with more limitations on access 383 control has a negative effect on the operational flexibility. By 384 separating the KSK and ZSK functionality, these risks can be managed 385 while making the tradeoff against the involved costs. For example, a 386 KSK can be stored off-line or with more limitations on access control 387 than ZSKs which need to be readily available for operational purposes 388 such as the addition or deletion of zone data. A KSK stored on a 389 smartcard, that is kept in a safe, combined with a ZSK stored on a 390 file-system accessible by operators for daily routine may provide a 391 better protection against key compromise without losing much 392 operational flexibility. It must be said that some HSMs give the 393 option to have your keys online, giving more protection and hardly 394 affecting the operational flexibility. In those cases, a KSK-ZSK 395 split is not more beneficial than the Single Type Signing Scheme. 397 It is worth mentioning that there's not much point obsessively 398 protecting the key if you don't protect the zone files, which also 399 live on the file-systems. 401 Finally there is a risk of cryptanalysis of the key material. The 402 costs of such analysis are correlated to the length of the key. 403 However, cryptanalysis arguments provide no strong motivation for a 404 KSK/ZSK split. Suppose one differentiates between a KSK and a ZSK 405 whereby the KSK effectivity period is X times the ZSK effectivity 406 period. Then, in order for the resistance to cryptanalysis to be the 407 same for the KSK and the ZSK, the KSK needs to be X times stronger 408 than the ZSK. Since for all practical purposes, X will be somewhere 409 of the order of 10 to 100, the associated key sizes will vary only 410 about a byte in size for symmetric keys. When translated to 411 asymmetric keys, the size difference is still too insignificant to 412 warrant a key-split; it only marginally affects the packet size and 413 signing speed. 415 The arguments for differentiation between the ZSK and KSK are weakest 416 when: 418 o the exposure to risk is low (e.g. when keys are stored on HSMs); 420 o one can be certain that a key is not used as a trust anchor; 422 o maintenance of the various keys cannot be performed through tools 423 (is prone to human error); and 425 o the interaction through the child-parent provisioning chain -- in 426 particular the timely appearance of a new DS record in the parent 427 zone in emergency situations -- is predictable. 429 If the above holds then the costs of the operational complexity of a 430 KSK-ZSK split may outweigh the costs of operational flexibility and 431 choosing a Single Type Signing Scheme is a reasonable option. In 432 other cases we advise that the separation between KSKs and ZSKs is 433 made. 435 3.2. Practical Consequences of KSK and ZSK Separation 437 A key that acts only as a Zone Signing Key is used to sign all the 438 data except the DNSKEY RRset in a zone on a regular basis. When a 439 ZSK is to be rolled, no interaction with the parent is needed. This 440 allows for a relatively short key effectivity period. 442 A key with only the Key Signing Key role is to be used to sign the 443 DNSKEY RRs in a zone. If a KSK is to be rolled, there may be 444 interactions with other parties. These can include the 445 administrators of the parent zone or administrators of verifying 446 resolvers that have the particular key configured as secure entry 447 points. In the latter case, everyone relying on the trust anchor 448 needs to roll over to the new key, a process that may be subject to 449 stability costs if automated trust anchor rollover mechanisms (e.g. 450 RFC 5011 [RFC5011]) are not in place. Hence, the key effectivity 451 period of these keys can and should be made much longer. 453 3.2.1. Rolling a KSK that is not a trust anchor 455 There are three schools of thought on rolling a KSK that is not a 456 trust anchor: 458 1. It should be done frequently and regularly (possibly every few 459 months) so that a key rollover remains an operational routine. 461 2. It should be done frequently but irregularly. Frequently meaning 462 every few months, again based on the argument that a rollover is 463 a practiced and common operational routine, and irregular meaning 464 with a large jitter, so that third parties do not start to rely 465 on the key and will not be tempted to configure it as a trust 466 anchor. 468 3. It should only be done when it is known or strongly suspected 469 that the key can be or has been compromised, or in conjunction 470 with operator change policies and procedures, like when a new 471 algorithm or key storage is required. 473 There is no widespread agreement on which of these three schools of 474 thought is better for different deployments of DNSSEC. There is a 475 stability cost every time a non-anchor KSK is rolled over, but it is 476 possibly low if the communication between the child and the parent is 477 good. On the other hand, the only completely effective way to tell 478 if the communication is good is to test it periodically. Thus, 479 rolling a KSK with a parent is only done for two reasons: to test and 480 verify the rolling system to prepare for an emergency, and in the 481 case of (preventing) an actual emergency. 483 Finally, in most cases a zone administrator cannot be fully certain 484 that the zone's KSK is not in use as a trust anchor somewhere. While 485 the configuration of trust anchors is not the responsibility of the 486 zone administrator, there may be stability costs for the validator 487 administrator that (wrongfully) configured the trust anchor when the 488 zone administrator rolls a KSK. 490 3.2.2. Rolling a KSK that is a trust anchor 492 The same operational concerns apply to the rollover of KSKs that are 493 used as trust anchors: if a trust anchor replacement is done 494 incorrectly, the entire domain that the trust anchor covers will 495 become Bogus until the trust anchor is corrected. 497 In a large number of cases it will be safe to work from the 498 assumption that one's keys are not in use as trust anchors. If a 499 zone administrator publishes a "DNSSEC Signing Policy and/or a DNSSEC 500 Practice Statement" [I-D.ietf-dnsop-dnssec-dps-framework] that should 501 be explicit about the fact whether the existence of trust anchors 502 will be taken into account. There may be cases where local policies 503 enforce the configuration of trust anchors on zones which are mission 504 critical (e.g. in enterprises where the trust anchor for the 505 enterprise domain is configured in the enterprise's validator). It 506 is expected that the zone administrators are aware of such 507 circumstances. 509 One can argue that because of the difficulty of getting all users of 510 a trust anchor to replace an old trust anchor with a new one, a KSK 511 that is a trust anchor should never be rolled unless it is known or 512 strongly suspected that the key has been compromised. In other words 513 the costs of a KSK rollover are prohibitively high because some users 514 cannot be reached. 516 However, the "operational habit" argument also applies to trust 517 anchor reconfiguration at the clients' validators. If a short key 518 effectivity period is used and the trust anchor configuration has to 519 be revisited on a regular basis, the odds that the configuration 520 tends to be forgotten is smaller. In fact, the costs for those users 521 can be minimized by automating the rollover with RFC 5011 [RFC5011] 522 and by rolling the key regularly (and advertising such) so that the 523 operators of validating resolvers will put the appropriate mechanism 524 in place to deal with these stability costs: in other words, budget 525 for these costs instead of incurring them unexpectedly. 527 It is therefore preferred to roll KSKs that are expected to be used 528 as trust anchors on a regular basis if and only if those rollovers 529 can be tracked using standardized (e.g. RFC 5011 [RFC5011]) 530 mechanisms. 532 3.2.3. The use of the SEP flag 534 The so-called Secure Entry Point (SEP) [RFC4035] flag can be used to 535 distinguish between keys that are intended to be used as the secure 536 entry point into the zone when building chains of trust, i.e., they 537 are (to be) pointed to by parental DS RRs or configured as a trust 538 anchor. 540 While the SEP flag does not play any role in validation, it is used 541 in practice for operational purposes such as for the rollover 542 mechanism described in RFC 5011 [RFC5011]. The common convention is 543 to set the SEP flag on any key that is used for key exchanges with 544 the parent and/or potentially used for configuration as a trust 545 anchor. Therefore, it is suggested that the SEP flag is set on keys 546 that are used as KSKs and not on keys that are used as ZSKs, while in 547 those cases where a distinction between KSK and ZSK is not made (i.e. 548 for a Single Type Signing Scheme), it is suggested that the SEP flag 549 is set on all keys. 551 Note: some signing tools may assume a KSK/ZSK split and use the (non) 552 presence of the SEP flag to determine which key is to be used for 553 signing zone data; these tools may get confused when a Single Type 554 Signing Scheme is used. 556 3.3. Key Effectivity Period 558 In general the available key length sets an upper limit on the key 559 effectivity period. For all practical purposes it is sufficient to 560 define the key effectivity period based on purely operational 561 requirements and match the key length to that value. Ignoring the 562 operational perspective, a reasonable effectivity period for KSKs 563 that have corresponding DS records in the parent zone is of the order 564 of two decades or longer. That is, if one does not plan to test the 565 rollover procedure, the key should be effective essentially forever, 566 and only rolled over in case of emergency. 568 When one opts for a regular key-rollover, a reasonable key 569 effectivity period for KSKs that have a parent zone is one year, 570 meaning you have the intent to replace them after 12 months. The key 571 effectivity period is merely a policy parameter, and should not be 572 considered a constant value. For example, the real key effectivity 573 period may be a little bit longer than 12 months, because not all 574 actions needed to complete the rollover could be finished in time. 576 As argued above, this annual rollover gives operational practice of 577 rollovers for both the zone and validator administrators. Besides, 578 in most environments a year is a time-span that is easily planned and 579 communicated. 581 Where keys are stored online and the exposure to various threats of 582 compromise is fairly high, an intended key effectivity period of a 583 month is reasonable for Zone Signing Keys. 585 Although very short key effectivity periods are theoretically 586 possible, when replacing keys one has to take into account the 587 rollover considerations from Section 4.1 and Section 4.4. Key 588 replacement endures for a couple of Maximum Zone TTLs, depending on 589 the rollover scenario. Therefore, a multiple of Maximum Zone TTL 590 durations is a reasonable lower limit on the key effectivity period. 591 Forcing a smaller key effectivity period will result in an 592 unnecessary and inconventiently large DNSKEY RRset published in the 593 zone. 595 The motivation for having the ZSK's effectivity period shorter than 596 the KSK's effectivity period is rooted in the operational 597 consideration that it is more likely that operators have more 598 frequent read access to the ZSK than to the KSK. Thus, in cases 599 where the ZSK cannot be afforded the same level of protection as the 600 KSK (such as when zone keys are kept online), and where the risk of 601 unauthorized disclosure of the ZSK's private key is not negligible 602 (e.g. when HSMs are not in use), the ZSK's effectivity period should 603 be kept shorter than the KSK's effectivity period. 605 In fact, if the risk of loss, theft, or other compromise is the same 606 for a zone and key signing key, there is little reason to choose 607 different effectivity periods for ZSKs and KSKs. And when the split 608 between ZSKs and KSKs is not made, the argument is redundant. 610 There are certainly cases in which the use of a Single Type Signing 611 Scheme with a long key effectivity period is a good choice, for 612 example, where the costs and risks of compromise, and the costs and 613 risks involved with having to perform an emergency roll are low. 615 3.4. Cryptographic Considerations 617 3.4.1. Signature Algorithm 619 At the time of writing, there are three types of signature algorithms 620 that can be used in DNSSEC: RSA, DSA and GOST. Proposals for other 621 algorithms are in the making. All three are fully specified in many 622 freely-available documents, and are widely considered to be patent- 623 free. The creation of signatures with RSA and DSA takes roughly the 624 same time, but DSA is about ten times slower for signature 625 verification. Also note that, in the context of DNSSEC, DSA is 626 limited to a maximum of 1024 bit keys. 628 We suggest the use of RSA/SHA-256 as the preferred signature 629 algorithms and RSA/SHA-1 as an alternative. Both have advantages and 630 disadvantages. RSA/SHA-1 has been deployed for many years, while 631 RSA/SHA-256 has only begun to be deployed. On the other hand, it is 632 expected that if effective attacks on either algorithm appear, they 633 will appear for RSA/SHA-1 first. RSA/MD5 should not be considered 634 for use because RSA/MD5 will very likely be the first common-use 635 signature algorithm to have an effective attack. 637 At the time of publication, it is known that the SHA-1 hash has 638 cryptanalysis issues and work is in progress on addressing them. The 639 use of public key algorithms based on hashes stronger than SHA-1 640 (e.g., SHA-256) is recommended, if these algorithms are available in 641 implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]). 643 Also at the time of publication, digital signature algorithms based 644 on Elliptic Curve (EC) Cryptography with DNSSEC (GOST [RFC5933], 645 ECDSA [RFC6605]) are being standardized and implemented. The use of 646 EC has benefits in terms of size. On the other hand, one has to 647 balance that against the amount of validating resolver 648 implementations that will not recognize EC signatures and thus treat 649 the zone as insecure. Beyond the observation of this trade-off, we 650 will not discuss this further. 652 3.4.2. Key Sizes 654 This section assumes RSA keys, as suggested in the previous section. 656 DNSSEC signing keys should be large enough to avoid all known 657 cryptographic attacks during the effectivity period of the key. To 658 date, despite huge efforts, no one has broken a regular 1024-bit key; 659 in fact, the best completed attack is estimated to be the equivalent 660 of a 700-bit key. An attacker breaking a 1024-bit signing key would 661 need to expend phenomenal amounts of networked computing power in a 662 way that would not be detected in order to break a single key. 663 Because of this, it is estimated that most zones can safely use 1024- 664 bit keys for at least the next ten years (A 1024-bit asymmetric key 665 has an approximate equivalent strength of a symmetric 80-bit key). 667 Depending on local policy (e.g. owners of keys that are used as 668 extremely high value trust anchors, or non-anchor keys that may be 669 difficult to roll over), it may be advisable to use lengths longer 670 than 1024 bits. Typically, the next larger key size used is 2048 671 bits, which has the approximate equivalent strength of a symmetric 672 112-bit key (RFC 3766 [RFC3766]). Signing and verifying with a 2048- 673 bit key takes longer than with a 1024-bit key. The increase depends 674 on software and hardware implementations, but public operations (such 675 as verification) are about four times slower, while private 676 operations (such as signing) slow down about eight times. 678 Another way to decide on the size of key to use is to remember that 679 the effort it takes for an attacker to break a 1024-bit key is the 680 same regardless of how the key is used. If an attacker has the 681 capability of breaking a 1024-bit DNSSEC key, he also has the 682 capability of breaking one of the many 1024-bit TLS trust anchor keys 683 that are currently installed in web browsers. If the value of a 684 DNSSEC key is lower to the attacker than the value of a TLS trust 685 anchor, the attacker will use the resources to attack the latter. 687 It is possible that there will be an unexpected improvement in the 688 ability for attackers to break keys, and that such an attack would 689 make it feasible to break 1024-bit keys but not 2048-bit keys. If 690 such an improvement happens, it is likely that there will be a huge 691 amount of publicity, particularly because of the large number of 692 1024-bit TLS trust anchors built into popular web browsers. At that 693 time, all 1024-bit keys (both ones with parent zones and ones that 694 are trust anchors) can be rolled over and replaced with larger keys. 696 Earlier documents (including the previous version of this document) 697 urged the use of longer keys in situations where a particular key was 698 "heavily used". That advice may have been true 15 years ago, but it 699 is not true today when using RSA algorithms and keys of 1024 bits or 700 higher. 702 3.4.3. Private Key Storage 704 It is preferred that, where possible, zone private keys and the zone 705 file master copy that is to be signed be kept and used in off-line, 706 non-network-connected, physically secure machines only. 707 Periodically, an application can be run to add authentication to a 708 zone by adding RRSIG and NSEC/NSEC3 RRs. Then the augmented file can 709 be transferred to the master. 711 When relying on dynamic update [RFC3007] or any other update 712 mechanism that runs at a regular interval to manage a signed zone, be 713 aware that at least one private key of the zone will have to reside 714 on the master server, or reside on an HSM to which the server has 715 access. This key is only as secure as the amount of exposure the 716 server receives to unknown clients and on the level of security of 717 the host. Although not mandatory, one could administer a zone using 718 a "hidden master" scheme to minimize the risk. In this arrangement 719 the master name server that processes the updates is unavailable to 720 general hosts on the Internet; it is not listed in the NS RRset. The 721 name servers in the NS RRset are able to receive zone updates through 722 IXFR, AXFR, or an out-of-band distribution mechanism, possibly in 723 combination with NOTIFY or another mechanism to trigger zone 724 replication. 726 The ideal situation is to have a one-way information flow to the 727 network to avoid the possibility of tampering from the network. 728 Keeping the zone master on-line on the network and simply cycling it 729 through an off-line signer does not do this. The on-line version 730 could still be tampered with if the host it resides on is 731 compromised. For maximum security, the master copy of the zone file 732 should be off-net and should not be updated based on an unsecured 733 network mediated communication. 735 The ideal situation may not be achievable because of economic 736 tradeoffs between risks and costs. For instance, keeping a zone file 737 off-line is not practical and will increase the costs of operating a 738 DNS zone. So in practice the machines on which zone files are 739 maintained will be connected to a network. Operators are advised to 740 take security measures to shield unauthorized access to the master 741 copy in order to prevent modification of DNS data before its signed. 743 Similarly the choice for storing a private key in an HSM will be 744 influenced by a tradeoff between various concerns: 746 o The risks that an unauthorized person has unnoticed read-access to 747 the private key. 749 o The remaining window of opportunity for the attacker. 751 o The economic impact of the possible attacks (for a TLD that impact 752 will typically be higher than for an individual users). 754 o The costs of rolling the (compromised) keys. (The costs of 755 rolling a ZSK is lowest and the costs of rolling a KSK that is in 756 wide use as a trust anchor is highest.) 758 o The costs of buying and maintaining an HSM. 760 For dynamically updated secured zones [RFC3007], both the master copy 761 and the private key that is used to update signatures on updated RRs 762 will need to be on-line. 764 3.4.4. Key Generation 766 Careful generation of all keys is a sometimes overlooked but 767 absolutely essential element in any cryptographically secure system. 768 The strongest algorithms used with the longest keys are still of no 769 use if an adversary can guess enough to lower the size of the likely 770 key space so that it can be exhaustively searched. Technical 771 suggestions for the generation of random keys will be found in RFC 772 4086 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A]. In particular, 773 one should carefully assess whether the random number generator used 774 during key generation adheres to these suggestions. Typically, HSMs 775 tend to provide a good facility for key generation. 777 Keys with a long effectivity period are particularly sensitive as 778 they will represent a more valuable target and be subject to attack 779 for a longer time than short-period keys. It is preferred that long- 780 term key generation occur off-line in a manner isolated from the 781 network via an air gap or, at a minimum, high-level secure hardware. 783 3.4.5. Differentiation for 'High-Level' Zones? 785 An earlier version of this document (RFC 4641 [RFC4641]) made a 786 differentiation between key lengths for KSKs used for zones that are 787 high in the DNS hierarchy and those for KSKs used low down. 789 This distinction is now considered not relevant. Longer key lengths 790 for keys higher in the hierarchy are not useful because the 791 cryptographic guidance is that everyone should use keys that no one 792 can break. Also, it is impossible to judge which zones are more or 793 less valuable to an attacker. An attack can only take place if the 794 key compromise goes unnoticed and the attacker can act as a man-in- 795 the-middle (MITM). For example, if example.com is compromised and 796 the attacker forges answers for somebank.example.com. and sends them 797 out during an MITM, when the attack is discovered, it will be simple 798 to prove that example.com has been compromised and the KSK will be 799 rolled. 801 4. Signature Generation, Key Rollover, and Related Policies 803 4.1. Key Rollovers 805 Regardless of whether a zone uses periodic key rollovers, or only 806 rolls keys in case of an irregular event, key rollovers are a fact of 807 life when using DNSSEC. Zone administrators who are in the process 808 of rolling their keys have to take into account that data published 809 in previous versions of their zone still lives in caches. When 810 deploying DNSSEC, this becomes an important consideration; ignoring 811 data that may be in caches may lead to loss of service for clients. 813 The most pressing example of this occurs when zone material signed 814 with an old key is being validated by a resolver that does not have 815 the old zone key cached. If the old key is no longer present in the 816 current zone, this validation fails, marking the data Bogus. 817 Alternatively, an attempt could be made to validate data that is 818 signed with a new key against an old key that lives in a local cache, 819 also resulting in data being marked Bogus. 821 The typographic conventions used in the diagrams below are explained 822 in Appendix B. 824 4.1.1. Zone Signing Key Rollovers 826 If the choice for splitting zone and key signing keys has been made, 827 then those two types of keys can be rolled separately and zone 828 signing keys can be rolled without taking into account DS records 829 from the parent or the configuration of such a key as trust anchor. 831 For "Zone Signing Key rollovers", there are two ways to make sure 832 that during the rollover data still cached can be verified with the 833 new key sets or newly generated signatures can be verified with the 834 keys still in caches. One scheme, described in Section 4.1.1.1, uses 835 key pre-publication; the other uses double signatures, described in 836 Section 4.1.1.2. The pros and cons are described in Section 4.1.1.3. 838 4.1.1.1. Pre-Publish Zone Signing Key Rollover 840 This section shows how to perform a ZSK rollover without the need to 841 sign all the data in a zone twice -- the "Pre-Publish key rollover". 842 This method has advantages in the case of a key compromise. If the 843 old key is compromised, the new key has already been distributed in 844 the DNS. The zone administrator is then able to quickly switch to 845 the new key and remove the compromised key from the zone. Another 846 major advantage is that the zone size does not double, as is the case 847 with the Double Signature ZSK rollover. 849 Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves 850 four stages as follows: 852 ---------------------------------------------------------- 853 initial new DNSKEY new RRSIGs 854 ---------------------------------------------------------- 855 SOA_0 SOA_1 SOA_2 856 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) 858 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 859 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 860 DNSKEY_Z_11 DNSKEY_Z_11 861 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) 862 ------------------------------------------------------------ 864 ------------------------------------------------------------ 865 DNSKEY removal 866 ------------------------------------------------------------ 867 SOA_3 868 RRSIG_Z_11(SOA) 870 DNSKEY_K_1 871 DNSKEY_Z_11 873 RRSIG_K_1(DNSKEY) 874 ------------------------------------------------------------ 876 Figure 1: Pre-Publish Key Rollover 878 initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing 879 Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e., 880 it is the Zone Signing Key. 882 new DNSKEY: DNSKEY_Z_11 is introduced into the key set (note that no 883 signatures are generated with this key yet, but this does not 884 secure against brute force attacks on its public key). The 885 minimum duration of this pre-roll phase is the time it takes for 886 the data to propagate to the authoritative servers, plus TTL value 887 of the key set. 889 new RRSIGs: At the "new RRSIGs" stage , DNSKEY_Z_11 is used to sign 890 the data in the zone exclusively (i.e., all the signatures from 891 DNSKEY_Z_10 are removed from the zone). DNSKEY_Z_10 remains 892 published in the key set. This way, data that was loaded into 893 caches from the zone in the "new DNSKEY" step can still be 894 verified with key sets fetched from this version of the zone. The 895 minimum time that the key set including DNSKEY_Z_10 is to be 896 published is the time that it takes for zone data from the 897 previous version of the zone to expire from old caches, i.e., the 898 time it takes for this zone to propagate to all authoritative 899 servers, plus the Maximum Zone TTL value of any of the data in the 900 previous version of the zone. 902 DNSKEY removal: DNSKEY_Z_10 is removed from the zone. The key set, 903 now only containing DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with 904 the DNSKEY_K_1. 906 The above scheme can be simplified by always publishing the "future" 907 key immediately after the rollover. The scheme would look as follows 908 (we show two rollovers); the future key is introduced in "new DNSKEY" 909 as DNSKEY_Z_12 and again a newer one, numbered 13, in "new DNSKEY 910 (II)": 912 initial new RRSIGs new DNSKEY 913 ----------------------------------------------------------------- 914 SOA_0 SOA_1 SOA_2 915 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) 917 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 918 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 919 DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12 920 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) 921 ---------------------------------------------------------------- 923 ---------------------------------------------------------------- 924 new RRSIGs (II) new DNSKEY (II) 925 ---------------------------------------------------------------- 926 SOA_3 SOA_4 927 RRSIG_Z_12(SOA) RRSIG_Z_12(SOA) 929 DNSKEY_K_1 DNSKEY_K_1 930 DNSKEY_Z_11 DNSKEY_Z_12 931 DNSKEY_Z_12 DNSKEY_Z_13 932 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) 933 ---------------------------------------------------------------- 935 Figure 2: Pre-Publish Zone Signing Key Rollover, Showing Two 936 Rollovers 938 Note that the key introduced in the "new DNSKEY" phase is not used 939 for production yet; the private key can thus be stored in a 940 physically secure manner and does not need to be 'fetched' every time 941 a zone needs to be signed. 943 4.1.1.2. Double Signature Zone Signing Key Rollover 945 This section shows how to perform a ZSK key rollover using the double 946 zone data signature scheme, aptly named "Double Signature rollover". 948 During the "new DNSKEY" stage the new version of the zone file will 949 need to propagate to all authoritative servers and the data that 950 exists in (distant) caches will need to expire, requiring at least 951 the propagation delay plus the Maximum Zone TTL of previous versions 952 of the zone. 954 Double Signature ZSK rollover involves three stages as follows: 956 ---------------------------------------------------------------- 957 initial new DNSKEY DNSKEY removal 958 ---------------------------------------------------------------- 959 SOA_0 SOA_1 SOA_2 960 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) 961 RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) 962 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 963 DNSKEY_Z_10 DNSKEY_Z_10 964 DNSKEY_Z_11 DNSKEY_Z_11 965 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) 966 ---------------------------------------------------------------- 968 Figure 3: Double Signature Zone Signing Key Rollover 970 initial: Initial Version of the zone: DNSKEY_K_1 is the Key Signing 971 Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e., 972 it is the Zone Signing Key. 974 new DNSKEY: At the "New DNSKEY" stage DNSKEY_Z_11 is introduced into 975 the key set and all the data in the zone is signed with 976 DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need to 977 continue until all data from version 0 (i.e. the version of the 978 zone data containing SOA_0) of the zone has been replaced in all 979 secondary servers and then has expired from remote caches. This 980 will take at least the propagation delay plus the Maximum Zone TTL 981 of version 0 of the zone. 983 DNSKEY removal: DNSKEY_Z_10 is removed from the zone as are all 984 signatures created with it. The key set, now only containing 985 DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11. 987 At every instance, RRSIGs from the previous version of the zone can 988 be verified with the DNSKEY RRset from the current version and vice- 989 versa. The duration of the "new DNSKEY" phase and the period between 990 rollovers should be at least the propogation delay to secondary 991 servers plus the Maximum Zone TTL of the previous version of the 992 zone. 994 Note that in this example we assumed for simplicity that the zone was 995 not modified during the rollover. In fact new data can be introduced 996 at anytime during this period, as long as it is signed with both 997 keys. 999 4.1.1.3. Pros and Cons of the Schemes 1001 Pre-Publish key rollover: This rollover does not involve signing the 1002 zone data twice. Instead, before the actual rollover, the new key 1003 is published in the key set and thus is available for 1004 cryptanalysis attacks. A small disadvantage is that this process 1005 requires four stages. Also the Pre-Publish scheme involves more 1006 parental work when used for KSK rollovers as explained in 1007 Section 4.1.2. 1009 Double Signature ZSK rollover: The drawback of this approach is that 1010 during the rollover the number of signatures in your zone doubles; 1011 this may be prohibitive if you have very big zones. An advantage 1012 is that it only requires three stages. 1014 4.1.2. Key Signing Key Rollovers 1016 For the rollover of a Key Signing Key, the same considerations as for 1017 the rollover of a Zone Signing Key apply. However, we can use a 1018 Double Signature scheme to guarantee that old data (only the apex key 1019 set) in caches can be verified with a new key set and vice versa. 1020 Since only the key set is signed with a KSK, zone size considerations 1021 do not apply. 1023 Note that KSK rollovers and ZSK rollovers are different in the sense 1024 that a KSK rollover requires interaction with the parent (and 1025 possibly replacing of trust anchors) and the ensuing delay while 1026 waiting for it. 1028 --------------------------------------------------------------------- 1029 initial new DNSKEY DS change DNSKEY removal 1030 --------------------------------------------------------------------- 1031 Parent: 1032 SOA_0 -----------------------------> SOA_1 ------------------------> 1033 RRSIG_par(SOA) --------------------> RRSIG_par(SOA) ---------------> 1034 DS_K_1 ----------------------------> DS_K_2 -----------------------> 1035 RRSIG_par(DS) ---------------------> RRSIG_par(DS) ----------------> 1037 Child: 1038 SOA_0 SOA_1 -----------------------> SOA_2 1039 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) 1041 DNSKEY_K_1 DNSKEY_K_1 ------------------> 1042 DNSKEY_K_2 ------------------> DNSKEY_K_2 1043 DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10 1044 RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ----------> 1045 RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY) 1046 --------------------------------------------------------------------- 1048 Figure 4: Stages of Deployment for a Double Signature Key Signing Key 1049 Rollover 1051 initial: Initial version of the zone. The parental DS points to 1052 DNSKEY_K_1. Before the rollover starts, the child will have to 1053 verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- 1054 it is needed during the rollover and we refer to the value as 1055 TTL_DS. 1057 new DNSKEY: During the "new DNSKEY" phase, the zone administrator 1058 generates a second KSK, DNSKEY_K_2. The key is provided to the 1059 parent, and the child will have to wait until a new DS RR has been 1060 generated that points to DNSKEY_K_2. After that DS RR has been 1061 published on all servers authoritative for the parent's zone, the 1062 zone administrator has to wait at least TTL_DS to make sure that 1063 the old DS RR has expired from caches. 1065 DS change: The parent replaces DS_K_1 with DS_K_2. 1067 DNSKEY removal: DNSKEY_K_1 has been removed. 1069 The scenario above puts the responsibility for maintaining a valid 1070 chain of trust with the child. It also is based on the premise that 1071 the parent only has one DS RR (per algorithm) per zone. An 1072 alternative mechanism has been considered. Using an established 1073 trust relation, the interaction can be performed in-band, and the 1074 removal of the keys by the child can possibly be signaled by the 1075 parent. In this mechanism, there are periods where there are two DS 1076 RRs at the parent. This is known as a KSK Double-DS Rollover, and is 1077 shown in Figure 5. This method has some drawbacks for KSKs. We 1078 first describe the rollover scheme and then indicate these drawbacks. 1080 -------------------------------------------------------------------- 1081 initial new DS new DNSKEY DS removal 1082 -------------------------------------------------------------------- 1083 Parent: 1084 SOA_0 SOA_1 ------------------------> SOA_2 1085 RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA) 1086 DS_K_1 DS_K_1 -----------------------> 1087 DS_K_2 -----------------------> DS_K_2 1088 RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS) 1090 Child: 1091 SOA_0 -----------------------> SOA_1 ----------------------------> 1092 RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------> 1094 DNSKEY_K_1 ------------------> DNSKEY_K_2 -----------------------> 1095 DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ----------------------> 1096 RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) ---------------> 1097 -------------------------------------------------------------------- 1099 Figure 5: Stages of Deployment for a Double-DS Key Signing Key 1100 Rollover 1102 When the child zone wants to roll, it notifies the parent during the 1103 "new DS" phase and submits the new key (or the corresponding DS) to 1104 the parent. The parent publishes DS_K_1 and DS_K_2, pointing to 1105 DNSKEY_K_1 and DNSKEY_K_2, respectively. During the rollover ("new 1106 DNSKEY" phase), which can take place as soon as the new DS set 1107 propagated through the DNS, the child replaces DNSKEY_K_1 with 1108 DNSKEY_K_2. If the old key has expired from caches, at the "DS 1109 removal" phase, the parent can be notified that the old DS record can 1110 be deleted. 1112 The drawbacks of this scheme are that, during the "new DS" phase, the 1113 parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 1114 using the DNS -- as DNSKEY_K_2 is not yet published. Besides, we 1115 introduce a "security lame" key (see Section 4.3.3). Finally, the 1116 child-parent interaction consists of two steps. The "Double 1117 Signature" method only needs one interaction. 1119 4.1.2.1. Special Considerations for RFC 5011 KSK rollover 1121 The scenario sketched above assumes that the KSK is not in use as a 1122 trust anchor, but that validating name servers exclusively depend on 1123 the parental DS record to establish the zone's security. If it is 1124 known that validating name servers have configured trust anchors, 1125 then that needs to be taken into account. Here we assume that zone 1126 administrators will deploy RFC 5011 [RFC5011] style rollovers. 1128 RFC 5011 style rollovers increase the duration of key rollovers: the 1129 key to be removed must first be revoked. Thus, before the DNSKEY_K_1 1130 removal phase, DNSKEY_K_1 must be published for one more Maximum Zone 1131 TTL with the REVOKE bit set. The revoked key must be self-signed, so 1132 in this phase the DNSKEY RRset must also be signed with DNSKEY_K_1. 1134 4.1.3. Rollover for a Single Type Signing Scheme Key Rollover 1136 The rollover of a key when a Single Type Signing Scheme is used is 1137 subject to the same requirement as the rollover of a KSK or ZSK: 1138 During any stage of the rollover, the chain of trust needs to 1139 continue to validate for any combination of data in the zone as well 1140 as data that may still live in distant caches. 1142 There are two variants for this rollover. Since the choice for a 1143 Single Type Signing Scheme is motivated by operational simplicity we 1144 describe the most straightforward rollover scheme first. 1146 ---------------------------------------------------------------- 1147 initial new DNSKEY DS change DNSKEY removal 1148 ---------------------------------------------------------------- 1149 Parent: 1150 SOA_0 --------------------------> SOA_1 ----------------------> 1151 RRSIG_par(SOA) -----------------> RRSIG_par(SOA) -------------> 1152 DS_S_1 -------------------------> DS_S_2 ---------------------> 1153 RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ----------> 1155 Child: 1156 SOA_0 SOA_1 ----------------------> SOA_2 1157 RRSIG_S_1(SOA) RRSIG_S_1(SOA) -------------> 1158 RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA) 1159 DNSKEY_S_1 DNSKEY_S_1 -----------------> 1160 DNSKEY_S_2 -----------------> DNSKEY_S_2 1161 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ----------> 1162 RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY) 1163 ----------------------------------------------------------------- 1165 Figure 6: Stages of the Straightforward rollover in a Single Type 1166 Signing Scheme 1168 initial: Parental DS points to DNSKEY_S_1. All RRsets in the zone 1169 are signed with DNSKEY_S_1. 1171 new DNSKEY: A new key (DNSKEY_S_2) is introduced and all the RRsets 1172 are signed with both DNSKEY_S_1 and DNSKEY_S_2. 1174 DS change: After the DNSKEY RRset with the two keys had time to 1175 propagate into distant caches (that is the key set exclusively 1176 containing DNSKEY_S_1 has been expired) the parental DS record can 1177 be changed. 1179 DNSKEY removal: After the DS RRset containing DS_S_1 has expired 1180 from distant caches, DNSKEY_S_1 can be removed from the DNSKEY 1181 RRset. 1183 In this first variant, the new signatures and new public key are 1184 added to the zone. Once they are propagated, the DS at the parent is 1185 switched. If the old DS has expired from the caches, the old 1186 signatures and old public key can be removed from the zone. 1188 This rollover has the drawback that it introduces double signatures 1189 over all data of the zone. Taking these zone size considerations 1190 into account, it is possible to not introduce the signatures made 1191 with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of 1192 DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an 1193 additional stage between the "DS change" and "DNSKEY removal" step: 1194 After the DS RRset containing DS_S_1 has expired from distant caches, 1195 the signatures can be swapped. Only after the new signatures made 1196 with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1 1197 can be removed from the DNSKEY RRset. 1199 The second variant of Single Type Signing Scheme Key rollover is the 1200 Double-DS rollver. In this variant, one introduces a new DNSKEY into 1201 the key set and submits the new DS to the parent. The new key is not 1202 yet used to sign RRsets. The signatures made with DNSKEY_S_1 are 1203 replaced with signatures made with DNSKEY_S_2 at the moment that 1204 DNSKEY_S_2 and DS_S_2 have been propagated. 1206 ------------------------------------------------------------------------ 1207 initial new DS new RRSIG DS removal 1208 ------------------------------------------------------------------------ 1209 Parent: 1210 SOA_0 SOA_1 -------------------------> SOA_2 1211 RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA) 1212 DS_S_1 DS_S_1 ------------------------> 1213 DS_S_2 ------------------------> DS_S_2 1214 RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS) 1216 Child: 1217 SOA_0 SOA_1 SOA_2 SOA_3 1218 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA) 1220 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 1221 DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2 1222 RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) 1223 ----------------------------------------------------------------------- 1225 Figure 7: Stages of Deployment for a Double-DS Rollover in a Single 1226 Type Signing Scheme 1228 4.1.4. Algorithm rollovers 1230 A special class of key rollovers is the one needed for a change of 1231 signature algorithms (either adding a new algorithm, removing an old 1232 algorithm, or both). Additional steps are needed to retain integrity 1233 during this rollover. We first describe the generic case; special 1234 considerations for rollovers that involve trust anchors and single 1235 type keys are discussed later. 1237 There exist both a conservative and a liberal approach for algorithm 1238 rollover. This has to do with section 2.2 in RFC 4035 [RFC4035]: 1240 There MUST be an RRSIG for each RRset using at least one DNSKEY of 1241 each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset 1242 itself MUST be signed by each algorithm appearing in the DS RRset 1243 located at the delegating parent (if any). 1245 The conservative approach interprets this section very strictly, 1246 meaning that it expects that every RRset has a valid signature for 1247 every algorithm signalled by the zone apex DNSKEY RRset - including 1248 RRsets in caches. The liberal approach uses a more loose 1249 interpretation of the section and limits the rule to RRsets in the 1250 zone at the authoritative name servers. There is a reasonable 1251 argument for saying that this is valid, because the specific section 1252 is a subsection of section 2. in RFC 4035: Zone Signing. 1254 When following the more liberal approach, algorithm rollover is just 1255 as easy as a regular Double-Signature KSK rollover (Section 4.1.2). 1256 Note that the Double-DS KSK rollover method cannot be used, since 1257 that would introduce a parental DS of which the apex DNSKEY RRset has 1258 not been signed with the introduced algorithm. 1260 However, there are implementations of validators known that follow 1261 the more conservative approach. Performing a Double-Signature KSK 1262 algorithm rollover will temporarily make your zone appear as Bogus by 1263 such validators during the rollover. Therefore, the rollover 1264 described in this section will explain the stages of deployment 1265 assuming the conservative approach. 1267 When adding a new algorithm, the signatures should be added first. 1268 After the TTL of RRSIGS has expired, and caches have dropped the old 1269 data covered by those signatures, the DNSKEY with the new algorithm 1270 can be added. 1272 After the new algorithm has been added, the DS record can be 1273 exchanged using Double-Signature KSK Rollover. 1275 When removing an old algorithm, the DS for the algorithm should be 1276 removed from the parent zone first, followed by the DNSKEY and the 1277 signatures (in the child zone). 1279 Figure 8 describes the steps. 1281 ---------------------------------------------------------------- 1282 initial new RRSIGs new DNSKEY 1283 ---------------------------------------------------------------- 1284 Parent: 1285 SOA_0 --------------------------------------------------------> 1286 RRSIG_par(SOA) -----------------------------------------------> 1287 DS_K_1 -------------------------------------------------------> 1288 RRSIG_par(DS_K_1) --------------------------------------------> 1290 Child: 1291 SOA_0 SOA_1 SOA_2 1292 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) 1293 RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) 1295 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 1296 DNSKEY_K_2 1297 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 1298 DNSKEY_Z_11 1299 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) 1300 RRSIG_K_2(DNSKEY) 1302 ---------------------------------------------------------------- 1303 new DS DNSKEY removal RRSIGs removal 1304 ---------------------------------------------------------------- 1305 Parent: 1306 SOA_1 -------------------------------------------------------> 1307 RRSIG_par(SOA) ----------------------------------------------> 1308 DS_K_2 ------------------------------------------------------> 1309 RRSIG_par(DS_K_2) -------------------------------------------> 1311 Child: 1312 -------------------> SOA_3 SOA_4 1313 -------------------> RRSIG_Z_10(SOA) 1314 -------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) 1316 -------------------> 1317 -------------------> DNSKEY_K_2 DNSKEY_K_2 1318 -------------------> 1319 -------------------> DNSKEY_Z_11 DNSKEY_Z_11 1320 -------------------> 1321 -------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY) 1322 ---------------------------------------------------------------- 1324 Figure 8: Stages of Deployment during an Algorithm Rollover 1326 initial: Describes state of the zone before any transition is done. 1327 The number of the keys may vary, but all keys (in DNSKEY records) 1328 for the zone use the same algorithm. 1330 new RRSIGs: The signatures made with the new key over all records in 1331 the zone are added, but the key itself is not. This step is 1332 needed to propagate the signatures created with the new algorithm 1333 to the caches. If this is not done, it is possible for a resolver 1334 to retrieve the new DNSKEY RRset (containing the new algorithm) 1335 but to have RRsets in its cache with signatures created by the old 1336 DNSKEY RRset (i.e. without the new algorithm). 1338 The RRSIG for the DNSKEY RRset does not need to be pre-published 1339 (since these records will travel together), and does not need 1340 special processing in order to keep them synchronized. 1342 new DNSKEY: After the old data has expired from caches, the new key 1343 can be added to the zone. 1345 new DS: After the cache data for the old DNSKEY RRset has expired, 1346 the DS record for the new key can be added to the parent zone and 1347 the DS record for the old key can be removed in the same step. 1349 DNSKEY removal: After the cache data for the old DS RRset has 1350 expired, the old algorithm can be removed. This time the old key 1351 needs to be removed first, before removing the old signatures. 1353 RRSIGs removal: After the cache data for the old DNSKEY RRset has 1354 expired, the old signatures can also be removed during this step. 1356 Below we deal with a few special cases of algorithm rollovers: 1358 1: Single Type Signing Scheme Algorithm Rollover: when there is no 1359 differentiation between Zone and Key signing keys 1360 (Section 4.1.4.1). 1362 2: RFC 5011 Algorithm Rollover: when trust anchors can track the 1363 roll via RFC 5011 style rollover (Section 4.1.4.2). 1365 3: 1 and 2 combined: when a Single Type Signing Scheme Algorithm 1366 rollover is performed RFC 5011 style (Section 4.1.4.3). 1368 In addition to the narrative below, these special cases are 1369 represented in Figure 12, Figure 13 and Figure 14 in Appendix C. 1371 4.1.4.1. Single Type Signing Scheme Algorithm Rollover 1373 If one key is used that acts both as ZSK and KSK, the same scheme and 1374 figure as above (in Section 4.1.4, Figure 8) applies whereby all 1375 DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are 1376 replaced with RRSIG_S_*. All DNSKEY_K_* records are replaced with 1377 DNSKEY_S_* and all RRSIG_K_* records are replaced with RRSIG_S_*. 1378 The requirement to sign with both algorithms and make sure that old 1379 RRSIGS have the opportunity to expire from distant caches before 1380 introducing the new algorithm in the DNSKEY RRset is still valid. 1382 This is shown in Figure 12 in Appendix C. 1384 4.1.4.2. Algorithm rollover, RFC 5011 style 1386 Trust anchor algorithm rollover is almost as simple as a regular RFC 1387 5011 based rollover. However, the old trust anchor must be revoked 1388 before it is removed from the zone. 1390 The timeline (see Figure 13 in Appendix C) is similar to that of 1391 Figure 8 above, but after the "new DS" step, an additional step is 1392 required where the DNSKEY is revoked. The details of this step 1393 ("revoke DNSKEY") are shown in figure Figure 9 below. 1395 --------------------------------- 1396 revoke DNSKEY 1397 --------------------------------- 1398 Parent: 1399 -----------------------------> 1400 -----------------------------> 1401 -----------------------------> 1402 -----------------------------> 1404 Child: 1405 SOA_3 1406 RRSIG_Z_10(SOA) 1407 RRSIG_Z_11(SOA) 1409 DNSKEY_K_1_REVOKED 1410 DNSKEY_K_2 1412 DNSKEY_Z_11 1413 RRSIG_K_1(DNSKEY) 1414 RRSIG_K_2(DNSKEY) 1415 -------------------------------- 1417 Figure 9: The Revoke DNSKEY state that is added to an algorithm 1418 rollover when RFC 5011 is in use. 1420 There is one exception to the requirement from RFC 4035 quoted in 1421 section 4.1.5 above: while all zone data must be signed with an 1422 unrevoked key, it is permissible to sign the key set with a revoked 1423 key. The somewhat esoteric argument is as follows: 1425 Resolvers that do not understand the RFC 5011 Revoke flag will handle 1426 DNSKEY_K_1_REVOKED the same as if it was DNSKEY_K_1. In other words, 1427 they will handle the revoked key as a normal key, and thus RRsets 1428 signed with this key will validate. As a result, the signature 1429 matches the algorithm listed in the DNSKEY RRset. 1431 Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from the 1432 set of trust anchors. That is okay, since they have already added 1433 DNSKEY_K_2 as the new trust anchor. Thus, algorithm 2 is the only 1434 signaled algorithm by now. That means, we only need 1435 RRSIG_K_2(DNSKEY) to authenticate the DNSKEY RRset, and we still are 1436 compliant with section 2.2 from RFC 4035: There must be an RRSIG for 1437 each RRset using at least one DNSKEY of each algorithm in the zone 1438 apex DNSKEY RRset. 1440 4.1.4.3. Single Signing Type Algorithm Rollover, RFC 5011 style 1442 If a decision is made to perform an RFC 5011 style rollover with a 1443 Single Signing Scheme key, it should be noted that section 2.1 of RFC 1444 5011 states: 1446 Once the resolver sees the REVOKE bit, it MUST NOT use this key 1447 as a trust anchor or for any other purpose except to validate 1448 the RRSIG it signed over the DNSKEY RRset specifically for the 1449 purpose of validating the revocation. 1451 This means that if once DNSKEY_S_1 is revoked, it cannot be used to 1452 validate its signatures over non-DNSKEY RRsets. Thus, those RRsets 1453 should be signed with a shadow key, DNSKEY_Z_10, during the algorithm 1454 rollover. The shadow key can be removed at the same time the revoked 1455 DNSKEY_S_1 is removed from the zone. In other words, the zone must 1456 temporarily fall back to a KSK/ZSK split model during the rollover. 1458 In other words, the rule that at every RRset there must be at least 1459 one signature for each algorithm used in the DNSKEY RRset still 1460 applies. This means that a different key with the same algorithm, 1461 other than the revoked key, must sign the entire zone. Thus, more 1462 operations are needed if the Single Type Signing Scheme is used. 1463 Before rolling the algorithm, a new key must be introduced with the 1464 same algorithm as the key that is candidate for revocation. That key 1465 can than temporarily act as ZSK during the algorithm rollover. 1467 As with algorithm rollover RFC 5011 style, while all zone data must 1468 be signed with an unrevoked key, it is permissible to sign the key 1469 set with a revoked key using the same esoteric argument given in 1470 Section 4.1.4.2. 1472 The lesson of all of this is that a Single Type Signing Scheme 1473 algorithm rollover using RFC 5011 is as complicated as the name of 1474 the rollover implies: reverting to a split key scheme for the 1475 duration of the rollover may be preferable. 1477 4.1.4.4. NSEC to NSEC3 algorithm rollover 1479 A special case is the rollover from an NSEC signed zone to an NSEC3 1480 signed zone. In this case algorithm numbers are used to signal 1481 support for NSEC3 but they do not mandate the use of NSEC3. 1482 Therefore, NSEC records should remain in the zone until the rollover 1483 to a new algorithm has completed and the new DNSKEY RRset has 1484 populated distant caches, at the end of the "new DNSKEY" stage. At 1485 that point the validators that have not implemented NSEC3 will treat 1486 the zone as unsecured as soon as they follow the chain of trust to 1487 the DS that points to a DNSKEY of the new algorithm, while validators 1488 that support NSEC3 will happily validate using NSEC. Turning on 1489 NSEC3 can then be done during the "new DS" step: increasing the 1490 serial number, introducing the NSEC3PARAM record to signal that NSEC3 1491 authenticated denial of existence data should be served, and 1492 resigning the zone. 1494 Summarizing, an NSEC to NSEC3 rollover is an ordinary algorithm 1495 rollover whereby NSEC is used all the time and only after that 1496 rollover finished NSEC3 needs to be deployed. The procedures are 1497 also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155]. 1499 4.1.5. Considerations for Automated Key Rollovers 1501 As keys must be renewed periodically, there is some motivation to 1502 automate the rollover process. Consider the following: 1504 o ZSK rollovers are easy to automate as only the child zone is 1505 involved. 1507 o A KSK rollover needs interaction between parent and child. Data 1508 exchange is needed to provide the new keys to the parent; 1509 consequently, this data must be authenticated and integrity must 1510 be guaranteed in order to avoid attacks on the rollover. 1512 4.2. Planning for Emergency Key Rollover 1514 This section deals with preparation for a possible key compromise. 1515 It is advised to have a documented procedure ready for when a key 1516 compromise is suspected or confirmed. 1518 When the private material of one of a zone's keys is compromised it 1519 can be used by an attacker for as long as a valid trust chain exists. 1520 A trust chain remains intact for 1522 o as long as a signature over the compromised key in the trust chain 1523 is valid, and 1525 o as long as the DS RR in the parent zone points to the 1526 (compromised) key signing the DNSKEY RRset, and 1528 o as long as the (compromised) key is anchored in a resolver and is 1529 used as a starting point for validation (this is generally the 1530 hardest to update). 1532 While a trust chain to a zone's compromised key exists, your 1533 namespace is vulnerable to abuse by anyone who has obtained 1534 illegitimate possession of the key. Zone administrators have to make 1535 a decision as to whether the abuse of the compromised key is worse 1536 than having data in caches that cannot be validated. If the zone 1537 administrator chooses to break the trust chain to the compromised 1538 key, data in caches signed with this key cannot be validated. 1539 However, if the zone administrator chooses to take the path of a 1540 regular rollover, during the rollover the malicious key holder can 1541 continue to spoof data so that it appears to be valid. 1543 4.2.1. KSK Compromise 1545 A compromised KSK can be used to sign the key set of an attacker's 1546 version of the zone. That zone could be used to poison the DNS. 1548 A zone containing a DNSKEY RRset with a compromised KSK is vulnerable 1549 as long as the compromised KSK is configured as trust anchor or a DS 1550 record in the parent zone points to it. 1552 Therefore, when the KSK has been compromised, the trust anchor or the 1553 parent DS record should be replaced as soon as possible. It is local 1554 policy whether to break the trust chain during the emergency 1555 rollover. The trust chain would be broken when the compromised KSK 1556 is removed from the child's zone while the parent still has a DS 1557 record pointing to the compromised KSK. The assumption is that there 1558 is only one DS record at the parent. If there are multiple DS 1559 records this does not apply, although the chain of trust of this 1560 particular key is broken. 1562 Note that an attacker's version of the zone still uses the 1563 compromised KSK and the presence of the corresponding DS record in 1564 the parent would cause the data in this zone to appear as valid. 1565 Removing the compromised key would cause the attacker's version of 1566 the zone to appear as valid and the original zone as Bogus. 1567 Therefore, we advise not to remove the KSK before the parent has a DS 1568 record for the new KSK in place. 1570 4.2.1.1. Emergency Key Rollover Keeping the Chain of Trust Intact 1572 If it is desired to perform an emergency key rollover in a manner 1573 that keeps the chain of trust intact, the timing of the replacement 1574 of the KSK is somewhat critical. The goal is to remove the 1575 compromised KSK as soon as the new DS RR is available at the parent. 1576 This means ensuring that the signature made with a new KSK over the 1577 key set that contains the compromised KSK expires just after the new 1578 DS appears at the parent. Expiration of that signature will cause 1579 expiration of that key set from the caches. 1581 The procedure is as follows: 1583 1. Introduce a new KSK into the key set, keep the compromised KSK in 1584 the key set. Lower the TTL for DNSKEYs so that the DNSKEY RRset 1585 will expire from caches sooner. 1587 2. Sign the key set, with a short validity period. The validity 1588 period should expire shortly after the DS is expected to appear 1589 in the parent and the old DSes have expired from caches. This 1590 provides an upper limit on how long the compromised KSK can be 1591 used in a replay attack. 1593 3. Upload the DS for this new key to the parent. 1595 4. Follow the procedure of the regular KSK rollover: Wait for the DS 1596 to appear at the authoritative servers and then wait as long as 1597 the TTL of the old DS RRs. If necessary, re-sign the DNSKEY 1598 RRset and modify/extend the expiration time. 1600 5. Remove the compromised DNSKEY RR from the zone and re-sign the 1601 key set using your "normal" TTL and signature validity period. 1603 An additional danger of a key compromise is that the compromised key 1604 could be used to facilitate a legitimately looking DNSKEY/DS rollover 1605 and/or name server changes at the parent. When that happens, the 1606 domain may be in dispute. An authenticated out-of-band and secure 1607 notify mechanism to contact a parent is needed in this case. 1609 Note that this is only a problem when the DNSKEY and or DS records 1610 are used to authenticate communication with the parent. 1612 4.2.1.2. Emergency Key Rollover Breaking the Chain of Trust 1614 There are two methods to perform an emergency key rollover in a 1615 manner that breaks the chain of trust. The first method causes the 1616 child zone to appear Bogus to validating resolvers. The other causes 1617 the child zone to appear Insecure. These are described below. 1619 In the method that causes the child zone to appear Bogus to 1620 validating resolvers, the child zone replaces the current KSK with a 1621 new one and re-signs the key set. Next, it sends the DS of the new 1622 key to the parent. Only after the parent has placed the new DS in 1623 the zone is the child's chain of trust repaired. Note that until 1624 that time, the child zone is still vulnerable to spoofing: the 1625 attacker is still in possession of the compromised key that the DS 1626 points to. 1628 An alternative method of breaking the chain of trust is by removing 1629 the DS RRs from the parent zone altogether. As a result, the child 1630 zone would become Insecure. After the DS has expired from distant 1631 caches, the keys and signatures are removed from the child zone, new 1632 keys and signatures are introduced and finally, a new DS is submitted 1633 to the parent. 1635 4.2.2. ZSK Compromise 1637 Primarily because there is no interaction with the parent required 1638 when a ZSK is compromised, the situation is less severe than with a 1639 KSK compromise. The zone must still be re-signed with a new ZSK as 1640 soon as possible. As this is a local operation and requires no 1641 communication between the parent and child, this can be achieved 1642 fairly quickly. However, one has to take into account that -- just 1643 as with a normal rollover -- the immediate disappearance of the old 1644 compromised key may lead to verification problems. Also note that 1645 until the RRSIG over the compromised ZSK has expired, the zone may be 1646 still at risk. 1648 4.2.3. Compromises of Keys Anchored in Resolvers 1650 A key can also be pre-configured in resolvers as a trust anchor. If 1651 trust anchor keys are compromised, the administrators of resolvers 1652 using these keys should be notified of this fact. Zone 1653 administrators may consider setting up a mailing list to communicate 1654 the fact that a SEP key is about to be rolled over. This 1655 communication will of course need to be authenticated by some means, 1656 e.g. by using digital signatures. 1658 End-users faced with the task of updating an anchored key should 1659 always verify the new key. New keys should be authenticated out-of- 1660 band, for example, through the use of an announcement website that is 1661 secured using Transport Layer Security (TLS) [RFC5246]. 1663 4.2.4. Stand-by Keys 1665 Stand-by keys are keys that are published in your zone, but are not 1666 used to sign RRsets. There are two reasons why someone would want to 1667 use stand-by keys. One is to speed up the emergency key rollover. 1668 The other is to recover from a disaster that leaves your production 1669 private keys inaccessible. 1671 The way to deal with stand-by keys differs for ZSKs and KSKs. To 1672 make a stand-by ZSK, you need to publish its DNSKEY RR. To make a 1673 stand-by KSK, you need to get its DS RR published at the parent. 1675 Assuming you have your normal DNS operation, to prepare stand-by keys 1676 you need to: 1678 o Generate a stand-by ZSK and KSK. Store them safely in a different 1679 location to the place where the currently used ZSK and KSK are 1680 held. 1682 o Pre-publish the DNSKEY RR of the stand-by ZSK in the zone. 1684 o Pre-publish the DS of the stand-by KSK in the parent zone. 1686 Now suppose a disaster occurs and disables access to the currently 1687 used keys. To recover from that situation, follow these procedures: 1689 o Set up your DNS operations and introduce the stand-by KSK into the 1690 zone. 1692 o Post-publish the disabled ZSK and sign the zone with the stand-by 1693 keys. 1695 o After some time, when the new signatures have been propagated, the 1696 old keys, old signatures and the old DS can be removed. 1698 o Generate a new stand-by key set at a different location and 1699 continue "normal" operation. 1701 4.3. Parent Policies 1703 4.3.1. Initial Key Exchanges and Parental Policies Considerations 1705 The initial key exchange is always subject to the policies set by the 1706 parent. It is specifically important in a registry-registrar- 1707 registrant model where a registry maintains the parent zone, and the 1708 registrant (the user of the child-domain name) deals with the 1709 registry through an intermediary called a registrar (see [RFC3375] 1710 for a comprehensive definition). The key material is to be passed 1711 from the DNS operator to the parent via a registrar, where both DNS 1712 operator and registrar are selected by the registrant and might be 1713 different organisations. When designing a key exchange policy, one 1714 should take into account that the authentication and authorization 1715 mechanisms used during a key exchange should be as strong as the 1716 authentication and authorization mechanisms used for the exchange of 1717 delegation information between parent and child. That is, there is 1718 no implicit need in DNSSEC to make the authentication process 1719 stronger than it is for regular DNS. 1721 Using the DNS itself as the source for the actual DNSKEY material has 1722 the benefit that it reduces the chances of user error. A DNSKEY 1723 query tool can make use of the SEP bit [RFC4035] to select the proper 1724 key(s) from a DNSSEC key set, thereby reducing the chance that the 1725 wrong DNSKEY is sent. It can validate the self-signature over a key; 1726 thereby verifying the ownership of the private key material. 1727 Fetching the DNSKEY from the DNS ensures that the chain of trust 1728 remains intact once the parent publishes the DS RR indicating the 1729 child is secure. 1731 Note: out-of-band verification is still needed when the key material 1732 is fetched for the first time, even via DNS. The parent can never be 1733 sure whether or not the DNSKEY RRs have been spoofed. 1735 With some type of key rollovers, the DNSKEY is not pre-published and 1736 a DNSKEY query tool is not able to retrieve the successor key. In 1737 this case, the out-of-band method is required. This also allows the 1738 child to determine the digest algorithm of the DS record. 1740 4.3.2. Storing Keys or Hashes? 1742 When designing a registry system one should consider whether to store 1743 the DNSKEYs and/or the corresponding DSes. Since a child zone might 1744 wish to have a DS published using a message digest algorithm not yet 1745 understood by the registry, the registry can't count on being able to 1746 generate the DS record from a raw DNSKEY. Thus, we suggest that 1747 registry systems should be able to store DS RRs, even if they also 1748 store DNSKEYs (see also draft-ietf-dnsop-dnssec-trust-anchor 1749 [I-D.ietf-dnsop-dnssec-trust-anchor]). 1751 The storage considerations also relate to the design of the customer 1752 interface and the method by which data is transferred between 1753 registrant and registry: will the child zone administrator be able to 1754 upload DS RRs with unknown hash algorithms or does the interface only 1755 allow DNSKEYs? When registries support the Extensible Provisioning 1756 Protocol (EPP) [RFC5910], that can be used for registrar-registry 1757 interactions since that protocol allows the transfer of both DS and, 1758 optionally, DNSKEY RRs. There is no standardized way for moving the 1759 data between the customer and the registrar. Different registrars 1760 have different mechanisms, ranging from simple web interfaces to 1761 various APIs. In some cases the use of the DNSSEC extensions to EPP 1762 may be applicable. 1764 Having an out-of-band mechanism, such as a registry directory (e.g., 1765 Whois), to find out which keys are used to generate DS Resource 1766 Records for specific owners and/or zones may also help with 1767 troubleshooting. 1769 4.3.3. Security Lameness 1771 Security lameness is defined as the state whereby the parent has a DS 1772 RR pointing to a non-existant DNSKEY RR. Security lameness may occur 1773 temporarily during a Double-DS rollover scheme. However care should 1774 be taken that not all DS RRs are pointing to a non-existing DNSKEY 1775 RR, which will cause the child's zone to be marked Bogus by verifying 1776 DNS clients. 1778 As part of a comprehensive delegation check, the parent could, at key 1779 exchange time, verify that the child's key is actually configured in 1780 the DNS. However, if a parent does not understand the hashing 1781 algorithm used by the child, the parental checks are limited to only 1782 comparing the key id. 1784 Child zones should be very careful in removing DNSKEY material, 1785 specifically SEP keys, for which a DS RR exists. 1787 Once a zone is "security lame", a fix (e.g., removing a DS RR) will 1788 take time to propagate through the DNS. 1790 4.3.4. DS Signature Validity Period 1792 Since the DS can be replayed as long as it has a valid signature, a 1793 short signature validity period for the DS RRSIG minimizes the time a 1794 child is vulnerable in the case of a compromise of the child's 1795 KSK(s). A signature validity period that is too short introduces the 1796 possibility that a zone is marked Bogus in case of a configuration 1797 error in the signer. There may not be enough time to fix the 1798 problems before signatures expire (this is a generic argument; also 1799 see Section 4.4.2). Something as mundane as zone administrator 1800 unavailability during weekends shows the need for DS signature 1801 validity periods longer than two days. Just like any signature 1802 validity period, we suggest an absolute minimum for the DS signature 1803 validity period of a few days. 1805 The maximum signature validity period of the DS record depends on how 1806 long child zones are willing to be vulnerable after a key compromise. 1807 On the other hand, shortening the DS signature validity period 1808 increases the operational risk for the parent. Therefore, the parent 1809 may have policy to use a signature validity period that is 1810 considerably longer than the child would hope for. 1812 A compromise between the policy/operational constraints of the parent 1813 and minimizing damage for the child may result in a DS signature 1814 validity period somewhere between a week and several months. 1816 In addition to the signature validity period, which sets a lower 1817 bound on the number of times the zone administrator will need to sign 1818 the zone data, and an upper bound to the time a child is vulnerable 1819 after key compromise, there is the TTL value on the DS RRs. 1820 Shortening the TTL reduces the damage of a successful replay attack. 1821 It does mean that the authoritative servers will see more queries. 1823 But on the other hand, a short TTL lowers the persistence of DS 1824 RRsets in caches thereby increasing the speed with which updated DS 1825 RRsets propagate through the DNS. 1827 4.3.5. Changing DNS Operators 1829 The parent-child relation is often described in terms of a registry- 1830 registrar-registrant model, where a registry maintains the parent 1831 zone, and the registrant (the user of the child-domain name) deals 1832 with the registry through an intermediary called a registrar 1833 [RFC3375]. Registrants may out-source the maintenance of their DNS 1834 system, including the maintenance of DNSSEC key material, to the 1835 registrar or to another third party, referred to here as the DNS 1836 operator. 1838 For various reasons, a registrant may want to move between DNS 1839 operators. How easy this move will be depends principally on the DNS 1840 operator from which the registrant is moving (the losing operator), 1841 as they have control over the DNS zone and its keys. The following 1842 sections describe the two cases: where the losing operator cooperates 1843 with the new operator (the gaining operator), and where the two do 1844 not cooperate. 1846 4.3.5.1. Cooperating DNS operators 1848 In this scenario, it is assumed that the losing operator will not 1849 pass any private key material to the gaining operator (that would 1850 constitute a trivial case) but is otherwise fully cooperative. 1852 In this environment, the change could be made with a Pre-Publish ZSK 1853 rollover whereby the losing operator pre-publishes the ZSK of the 1854 gaining operator, combined with a Double Signature KSK rollover where 1855 the two registrars exchange public keys and independently generate a 1856 signature over those key sets that they combine and both publish in 1857 their copy of the zone. Once that is done they can use their own 1858 private keys to sign any of their zone content during the transfer. 1860 ------------------------------------------------------------ 1861 initial | pre-publish | 1862 ------------------------------------------------------------ 1863 Parent: 1864 NS_A NS_A 1865 DS_A DS_A 1866 ------------------------------------------------------------ 1867 Child at A: Child at A: Child at B: 1868 SOA_A0 SOA_A1 SOA_B0 1869 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) 1871 NS_A NS_A NS_B 1872 RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) 1873 RRSIG_Z_A(NS) 1875 DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A 1876 DNSKEY_Z_B DNSKEY_Z_B 1877 DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A 1878 DNSKEY_K_B DNSKEY_K_B 1879 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) 1880 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) 1881 ------------------------------------------------------------ 1883 ------------------------------------------------------------ 1884 redelegation | post migration | 1885 ------------------------------------------------------------ 1886 Parent: 1887 NS_B NS_B 1888 DS_B DS_B 1889 ------------------------------------------------------------ 1890 Child at A: Child at B: Child at B: 1892 SOA_A1 SOA_B0 SOA_B1 1893 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) 1895 NS_A NS_B NS_B 1896 NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) 1897 RRSIG_Z_A(NS) 1899 DNSKEY_Z_A DNSKEY_Z_A 1900 DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B 1901 DNSKEY_K_A DNSKEY_K_A 1902 DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B 1903 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) 1904 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) 1905 ------------------------------------------------------------ 1907 Figure 10: Rollover for cooperating operators 1909 In this figure A denotes the losing operator and B the gaining 1910 operator. RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is 1911 produced with a KSK, the appended A or B indicates the producers of 1912 the key pair. "Child at A" is how the zone content is represented by 1913 the losing DNS operator and "Child at B" is how the zone content is 1914 represented by the gaining DNS operator. 1916 The zone is initially delegated from the parent to the name servers 1917 of operator A. Operator A uses his own ZSK and KSK to sign the zone. 1918 The cooperating operator A will pre-publish the new NS record and the 1919 ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset 1920 generated by the KSK of B. Operator B needs to publish the same 1921 DNSKEY RRset. When that DNSKEY RRset has populated the caches, the 1922 re-delegation can be made, which involves adjusting the NS and DS 1923 records in the parent zone to point to operator B. And after all 1924 DNSSEC records related to A have expired from the caches, operator B 1925 can stop publishing the keys and signatures belonging to operator A 1926 and vice versa. 1928 The requirement to exchange signatures has a couple of drawbacks. It 1929 requires more operational overhead, because not only the operators 1930 have to exchange public keys, they also have to exchange the 1931 signatures of the new DNSKEY RRset. This drawback does not exist if 1932 the Double Signature KSK rollover is replaced with a Double-DS KSK 1933 rollover. See Figure 15 in Appendix D for the diagram. 1935 Thus, if the registry and registrars allow DS records to be published 1936 that do not point to a published DNSKEY in the child zone, the 1937 Double-DS KSK rollover is preferred (see Figure 5), in combination 1938 with the Pre-Publish ZSK rollover. This does not require sharing the 1939 KSK signatures between the operators, but both operators still have 1940 to publish each others ZSKs. 1942 4.3.5.2. Non Cooperating DNS Operators 1944 In the non-cooperative case matters are more complicated. The losing 1945 operator may not cooperate and leave the data in the DNS as is. In 1946 the extreme case the losing operator may become obstructive and 1947 publish a DNSKEY RR with a high TTL and corresponding signature 1948 validity period so that registrar A's DNSKEY could end up in caches 1949 for (in theory at least) tens of years. 1951 The problem arises when a validator tries to validate with the losing 1952 operator's key and there is no signature material produced with the 1953 losing operator available in the delegation path after re-delegation 1954 from the losing operator to the gaining operator has taken place. 1955 One could imagine a rollover scenario where the gaining operator 1956 takes a copy of all RRSIGs created by the losing operator and 1957 publishes those in conjunction with its own signatures, but that 1958 would not allow any changes in the zone content. Since a re- 1959 delegation took place, the NS RRset has - by definition - changed so 1960 such rollover scenario will not work. Besides if zone transfers are 1961 not allowed by the losing operator and NSEC3 is deployed in the 1962 losing operator's zone, then the gaining operator's zone will not 1963 have certainty that all of A's RRSIGs have been copied. 1965 The only viable operation for the registrant is to have their zone go 1966 Insecure for the duration of the change. The registry should be 1967 asked to remove the DS RR pointing to the losing operator's DNSKEY 1968 and to change the NS RRset to point to the gaining operator. Once 1969 this has propagated through the DNS, the registry should be asked to 1970 insert the DS record pointing to the (newly signed) zone at operator 1971 B. 1973 Note that some behavior of resolver implementations may aid in the 1974 process of changing DNS operators: 1976 o TTL sanity checking, as described in RFC 2308 [RFC2308], will 1977 limit the impact the actions of an obstructive, losing operator. 1978 Resolvers that implement TTL sanity checking will use an upper 1979 limit for TTLs on RRsets in responses. 1981 o If RRsets at the zone cut (are about to) expire, the resolver 1982 restarts its search above the zone cut. Otherwise, the resolver 1983 risks to keep using a name server that might be un-delegated by 1984 the parent. 1986 o Limiting the time DNSKEYs that seem to be unable to validate 1987 signatures are cached and/or trying to recover from cases where 1988 DNSKEYs do not seem to be able to validate data, also reduces the 1989 effects of the problem of non-cooperating registrars. 1991 However, there is no operational methodology to work around this 1992 business issue, and proper contractual relationships between all 1993 involved parties seems to be the only solution to cope with these 1994 problems. It should be noted that in many cases, the problem with 1995 temporary broken delegations already exists when a zone changes from 1996 one DNS operator to another. Besides, it is often the case that when 1997 operators are changed, the services that that zone references also 1998 change operator, possibly involving some downtime. 2000 In any case, to minimise such problems, the classic configuration is 2001 to have relative short TTL on all involved resource records. That 2002 will solve many of the problems regarding changes to a zone 2003 regardless of whether DNSSEC is used. 2005 4.4. Time in DNSSEC 2007 Without DNSSEC, all times in the DNS are relative. The SOA fields 2008 REFRESH, RETRY, and EXPIRATION are timers used to determine the time 2009 elapsed after a slave server synchronized with a master server. The 2010 Time to Live (TTL) value and the SOA RR minimum TTL parameter 2011 [RFC2308] are used to determine how long a forwarder should cache 2012 data (or negative responses) after it has been fetched from an 2013 authoritative server. By using a signature validity period, DNSSEC 2014 introduces the notion of an absolute time in the DNS. Signatures in 2015 DNSSEC have an expiration date after which the signature is marked as 2016 invalid and the signed data is to be considered Bogus. 2018 The considerations in this section are all qualitative and focused on 2019 the operational and managerial issues. A more thorough quantitative 2020 analysis of rollover timing parameters can be found in 2021 draft-ietf-dnsop-dnssec-key-timing 2022 [I-D.ietf-dnsop-dnssec-key-timing]. 2024 4.4.1. Time Considerations 2026 Because of the expiration of signatures, one should consider the 2027 following: 2029 o We suggest the Maximum Zone TTL value of your zone data to be 2030 smaller than your signature validity period. 2032 If the TTL was of similar order as the signature validity 2033 period, then all RRsets fetched during the validity period 2034 would be cached until the signature expiration time. Section 2035 8.1 of RFC 4033 [RFC4033] suggests that "the resolver may use 2036 the time remaining before expiration of the signature validity 2037 period of a signed RRset as an upper bound for the TTL". As a 2038 result, query load on authoritative servers would peak at 2039 signature expiration time, as this is also the time at which 2040 records simultaneously expire from caches. 2042 Having a TTL that is at least a few times smaller than your 2043 signature validity period avoids query load peaks. 2045 o We suggest the signature publication period to end at least one 2046 Maximum Zone TTL duration (but preferably a minimum of a few days) 2047 before the end of the signature validity period. 2049 Re-signing a zone shortly before the end of the signature 2050 validity period may cause simultaneous expiration of data from 2051 caches. This in turn may lead to peaks in the load on 2052 authoritative servers. To avoid this, schemes are deployed 2053 whereby the zone is periodically visited for a re-signing 2054 operation and those signatures that are within a so called 2055 Refresh Period from signature expiration are recreated. Also 2056 see Section 4.4.2 below. 2058 In case of an operational error, you would have one Maximum 2059 Zone TTL duration to resolve the problem. Re-signing a zone a 2060 few days before the end of the signature validity period 2061 ensures the signatures will survive at least a (long) weekend 2062 in case of such operational havoc. This is called the Refresh 2063 Period (see Section 4.4.2). 2065 o We suggest the Minimum Zone TTL to be long enough to both fetch 2066 and verify all the RRs in the trust chain. In workshop 2067 environments, it has been demonstrated [NIST-workshop] that a low 2068 TTL (under 5 to 10 minutes) caused disruptions because of the 2069 following two problems: 2071 1. During validation, some data may expire before the 2072 validation is complete. The validator should be able to keep 2073 all data until it is completed. This applies to all RRs needed 2074 to complete the chain of trust: DS, DNSKEY, RRSIG, and the 2075 final answers, i.e., the RRset that is returned for the initial 2076 query. 2078 2. Frequent verification causes load on recursive name 2079 servers. Data at delegation points, DS, DNSKEY, and RRSIG RRs 2080 benefit from caching. The TTL on those should be relatively 2081 long. Data at the leafs in the DNS tree has less impact on 2082 recursive name servers. 2084 o Slave servers will need to be able to fetch newly signed zones 2085 well before the RRSIGs in the zone served by the slave server pass 2086 their signature expiration time. 2088 When a slave server is out of synchronization with its master 2089 and data in a zone is signed by expired signatures, it may be 2090 better for the slave server not to give out any answer. 2092 Normally, a slave server that is not able to contact a master 2093 server for an extended period will expire a zone. When that 2094 happens, the server will respond differently to queries for 2095 that zone. Some servers issue SERVFAIL, whereas others turn 2096 off the 'AA' bit in the answers. The time of expiration is set 2097 in the SOA record and is relative to the last successful 2098 refresh between the master and the slave servers. There exists 2099 no coupling between the signature expiration of RRSIGs in the 2100 zone and the expire parameter in the SOA. 2102 If the server serves a DNSSEC-secured zone, then it may happen 2103 that the signatures expire well before the SOA expiration timer 2104 counts down to zero. It is not possible to completely prevent 2105 this by modifying the SOA parameters. 2107 However, the effects can be minimized where the SOA expiration 2108 time is equal to or shorter than the Refresh Period (see 2109 Section 4.4.2). 2111 The consequence of an authoritative server not being able to 2112 update a zone for an extended period of time is that signatures 2113 may expire. In this case, non-secure resolvers will continue 2114 to be able to resolve data served by the particular slave 2115 servers while security-aware resolvers will experience problems 2116 because of answers being marked as Bogus. 2118 We suggest the SOA expiration timer being approximately one 2119 third or a quarter of the signature validity period. It will 2120 allow problems with transfers from the master server to be 2121 noticed before signatures time out. 2123 We also suggest that operators of name servers that supply 2124 secondary services develop systems to identify upcoming 2125 signature expirations in zones they slave and take appropriate 2126 action where such an event is detected. 2128 When determining the value for the expiration parameter one has 2129 to take the following into account: what are the chances that 2130 all secondaries expire the zone? How quickly can the 2131 administrators of the secondary servers be reached to load a 2132 valid zone? These questions are not DNSSEC-specific but may 2133 influence the choice of your signature validity periods. 2135 4.4.2. Signature Validity Periods 2137 4.4.2.1. Maximum Value 2139 The first consideration for choosing a maximum signature validity 2140 period is the risk of a replay attack. For low-value, long-term 2141 stable resources, the risks may be minimal and the signature validity 2142 period may be several months. Although signature validity periods of 2143 many years are allowed, the same operational habit arguments as given 2144 in Section 3.2.2 play a role: when a zone is re-signed with some 2145 regularity, then zone administrators remain conscious about the 2146 operational necessity of re-signing. 2148 4.4.2.2. Minimum Value 2150 The minimum value of the signature validity period is set for the 2151 time by which one would like to survive operational failure in 2152 provisioning: what is the time that a failure will be noticed, what 2153 is the time that action is expected to be taken? By answering these 2154 questions, availability of zone administrators during (long) weekends 2155 or time taken to access backup media can be taken into account. The 2156 result could easily suggest a minimum signature validity period of a 2157 few days. 2159 Note however, the argument above is assuming that zone data has just 2160 been signed and published when the problem occurred. In practice it 2161 may be that a zone is signed according to a frequency set by the Re- 2162 Sign Period whereby the signer visits the zone content and only 2163 refreshes signatures that are within a given amount of time (the 2164 Refresh Period) of expiration. The Re-Sign Period must be smaller 2165 than the Refresh Period in order for zone data to be signed in a 2166 timely fashion. 2168 If an operational problem occurs during re-signing, then the 2169 signatures in the zone to expire first are the ones that have been 2170 generated longest ago. In the worst case, these signatures are the 2171 Refresh Period minus the Re-Sign Period away from signature 2172 expiration. 2174 To make matters slightly more complicated, some signers vary the 2175 signature validity period over a small range (the jitter interval) so 2176 that not all signatures expire at the same time. 2178 In other words, the minimum signature validity period is set by first 2179 choosing the Refresh Period (usually a few days), then defining the 2180 Re-Sign Period in such a way that the Refresh Period minus the Re- 2181 Sign Period, minus the maximum jitter sets the time in which 2182 operational havoc can be resolved. 2184 The relationship between signature times is illustrated in Figure 11. 2186 Inception Signing Expiration 2187 time time time 2188 | | | | | 2189 |------------------|---------------------------------|.....|.....| 2190 | | | | | 2191 +/-jitter 2193 | Inception offset | | 2194 |<---------------->| Validity Period | 2195 | |<---------------------------------------->| 2197 Inception Signing Reuse Reuse Reuse New Expiration 2198 time time RRSIG time 2199 | | | | | | | 2200 |------------------|-------------------------------|-------| 2201 | | | | | | | 2202 <-----> <-----> <-----> <-----> 2203 Resign Period 2205 | Refresh | 2206 |<----------->| 2207 | Period | 2209 Figure 11: Signature Timing Parameters 2211 Note that in the figure the validity of the signature starts shortly 2212 before the signing time. That is done to deal with validators that 2213 might have some clock skew. This is called the inception offset and 2214 it should be chosen so that false negatives are minimized to a 2215 reasonable level. 2217 4.4.2.3. Differentiation between RRsets 2219 It is possible to vary signature validity periods between signatures 2220 over different RRsets in the zone. In practice, this could be done 2221 when zones contain highly volatile data (which may be the case in 2222 Dynamic Update environments). Note however that the risk of replay 2223 (e.g., by stale secondary servers) is what should be leading in 2224 determining the signature validity period, since the TTLs on the data 2225 itself are still the primary parameter for cache expiry. 2227 In some cases, the risk of replaying existing data might be different 2228 from the risk of replaying the denial of data. In those cases the 2229 signature validity period on NSEC or NSEC3 records may be tweaked 2230 accordingly. 2232 When a zone contains secure delegations, then a relatively short 2233 signature validity period protects the child against replay attacks 2234 in the case the child's key is compromised (see Section 4.3.4). 2235 Since there is a higher operational risk for the parent registry when 2236 choosing a short validity period and a higher operational risk for 2237 the child when choosing a long validity period, some (price) 2238 differentiation may occur for validity periods between individual DS 2239 RRs in a single zone. 2241 There seem to be no other arguments for differentiation in validity 2242 periods. 2244 5. Next Record type 2246 One of the design tradeoffs made during the development of DNSSEC was 2247 to separate the signing and serving operations instead of performing 2248 cryptographic operations as DNS requests are being serviced. It is 2249 therefore necessary to create records that cover the very large 2250 number of non-existent names that lie between the names that do 2251 exist. 2253 There are two mechanisms to provide authenticated proof of non- 2254 existence of domain names in DNSSEC: a clear-text one and an 2255 obfuscated-data one. Each mechanism: 2257 o includes a list of all the RRTYPEs present, which can be used to 2258 prove the non-existence of RRTYPEs at a certain name; 2260 o stores only the name for which the zone is authoritative (that is, 2261 glue in the zone is omitted); and 2263 o uses a specific RRTYPE to store information about the RRTYPEs 2264 present at the name: the clear-text mechanism uses NSEC, and the 2265 obfuscated-data mechanism uses NSEC3. 2267 5.1. Differences between NSEC and NSEC3 2269 The clear text mechanism (NSEC) is implemented using a sorted linked 2270 list of names in the zone. The obfuscated-data mechanism (NSEC3) is 2271 similar but first hashes the names using a one-way hash function, 2272 before creating a sorted linked list of the resulting (hashed) 2273 strings. 2275 The NSEC record requires no cryptographic operations aside from the 2276 validation of its associated signature record. It is human readable 2277 and can be used in manual queries to determine correct operation. 2278 The disadvantage is that it allows for "zone walking", where one can 2279 request all the entries of a zone by following the linked list of 2280 NSEC RRs via the "Next Domain Name" field. Though all agree DNS data 2281 is accessible through query mechanisms, for some zone administrators 2282 this behavior is undesirable for policy, regulatory or other reasons. 2284 Furthermore, NSEC requires a signature over every RR in the zone 2285 file, thereby ensuring that any denial of existence is 2286 cryptographically signed. However, in a large zone file containing 2287 many delegations, very few of which are to signed zones, this may 2288 produce unacceptable additional overhead, especially where insecure 2289 delegations are subject to frequent update (a typical example might 2290 be a TLD operator with few registrants using secure delegations). 2291 NSEC3 allows intervals between two secure delegations to "Opt-out" in 2292 which case they may contain one or more insecure delegations, thus 2293 reducing the size and cryptographic complexity of the zone at the 2294 expense of the ability to cryptographically deny the existence of 2295 names in a specific span. 2297 The NSEC3 record uses a hashing method of the requested name. To 2298 increase the workload required to guess entries in the zone, the 2299 number of hashing iterations can be specified in the NSEC3 record. 2300 Additionally, a salt can be specified that also modifies the hashes. 2301 Note that NSEC3 does not give full protection against information 2302 leakage from the zone (you can still derive the size of the zone, 2303 which RRtypes are in there, ...). 2305 5.2. NSEC or NSEC3 2307 The first motivation to deploy NSEC3, prevention of zone enumeration, 2308 only makes sense when zone content is not highly structured or 2309 trivially guessable. Highly structured zones such as in-addr.arpa., 2310 ip6.arpa. and e164.arpa. can be trivially enumerated using ordinary 2311 DNS properties, while for small zones that only contain records in 2312 the APEX and a few common names such as "www" or "mail", guessing 2313 zone content and proving completeness is also trivial when using 2314 NSEC3. In these cases, the use of NSEC is preferred to ease the work 2315 required by signers and validating resolvers. 2317 For large zones where there is an implication of "not readily 2318 available" names, such as those where one has to sign a non- 2319 disclosure agreement before obtaining it, NSEC3 is preferred. The 2320 second reason to consider NSEC3 is opt-out, which can reduce the 2321 number of NSEC3 records required. This is discussed further below 2322 (Section 5.3.4). 2324 5.3. NSEC3 parameters 2326 NSEC3 is controlled by a number of parameters, some of which can be 2327 varied: this section discusses the choice of those parameters. 2329 5.3.1. NSEC3 Algorithm 2331 The NSEC3 hashing algorithm is performed on the Fully Qualified 2332 Domain Name (FQDN) in its uncompressed form. This ensures brute 2333 force work done by an attacker for one FQDN cannot be re-used for 2334 another FQDN attack, as these entries are, by definition unique. 2336 At the time of writing, there is only one NSEC3 hash algorithm 2337 defined. [RFC5155] specifically states: "When a new hash algorithm 2338 for use with NSEC3 is specified, a transition mechanism MUST also be 2339 defined." Therefore this document does not consider NSEC3 hash 2340 algorithm transition. 2342 5.3.2. NSEC3 Iterations 2344 One of the concerns with NSEC3 is that a pre-calculated dictionary 2345 attack could be performed in order to assess if certain domain names 2346 exist within a zone or not. Two mechanisms are introduced in the 2347 NSEC3 specification to increase the costs of such dictionary attacks: 2348 iterations and salt. 2350 Iterations define the number of additional times the hash function 2351 has been performed. A higher value results in greater resiliency 2352 against dictionary attacks, at a higher computational cost for both 2353 the server and resolver. 2355 RFC 5155 Section 10.3 [RFC5155] considers the trade-offs between 2356 incurring cost during the signing process and imposing costs to the 2357 validating name server, while still providing a reasonable barrier 2358 against dictionary attacks. It provides useful limits of iterations 2359 for a given RSA key size. These are 150 iterations for 1024 bit 2360 keys, 500 iterations for 2048 bit keys and 2,500 iterations for 4096 2361 bit keys. Choosing a value of 100 iterations is deemed to be a 2362 sufficiently costly yet not excessive value: In the worst case 2363 scenario, the performance of name servers would be halved, regardless 2364 of key size [nsec3-hash-performance]. 2366 5.3.3. NSEC3 Salt 2368 While the NSEC3 iterations parameter increases the cost of hashing a 2369 dictionary word, the NSEC3 salt reduces the lifetime for which that 2370 calculated hash can be used. A change of the salt value by the zone 2371 administrator would cause an attacker to lose all pre-calculated work 2372 for that zone. 2374 There must be a complete NSEC3 chain using the same salt value, that 2375 matches the salt value in the NSEC3PARAM record. NSEC3 salt changes 2376 do not need special rollover procedures. Since changing the salt 2377 requires all the NSEC3 records to be regenerated, and thus requires 2378 generating new RRSIG's over these NSEC3 records, it makes sense to 2379 align the change of the salt with a change of the Zone Signing Key, 2380 as that process in itself already usually requires all RRSIG's to be 2381 regenerated. If there is no critical dependency on incremental 2382 signing and the zone can be signed with little effort, there is no 2383 need for such alignment. 2385 5.3.4. Opt-Out 2387 The Opt-Out mechanism was introduced to allow for a gradual 2388 introduction of signed records in zones that contain mostly 2389 delegation records. The use of the Opt-Out flag changes the meaning 2390 of the NSEC3 span from authoritative denial of the existence of names 2391 within the span to a proof that DNSSEC is not available for the 2392 delegations within the span. This allows for the addition or removal 2393 of the delegations covered by the span without recalculating or re- 2394 signing RRs in the NSEC3 RR chain. 2396 Opt-Out is specified to be used only over delegation points and will 2397 therefore only bring relief to zones with a large number of insecure 2398 delegations. This consideration typically holds for large top-level- 2399 domains and similar zones; in most other circumstances, Opt-Out 2400 should not be deployed. Further considerations can be found in 2401 Section 12.2 of RFC 5155 [RFC5155]. 2403 6. Security Considerations 2405 DNSSEC adds data origin authentication and data integrity to the DNS, 2406 using digital signatures over resource record sets. DNSSEC does not 2407 protect against denial of service attacks, nor does it provide 2408 confidentiality. For more general security considerations related to 2409 DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC 2410 4035 [RFC4035]. 2412 This document tries to assess the operational considerations to 2413 maintain a stable and secure DNSSEC service. When performing key 2414 rollovers, it is important to keep in mind that it takes time for the 2415 data to be propagated to the verifying clients. Also important to 2416 notice is that this data may be cached. Not taking into account the 2417 'data propagation' properties in the DNS may cause validation 2418 failures, because cached data may mismatch with data fetched from the 2419 authoritative servers. This will make secured zones unavailable to 2420 security-aware resolvers. 2422 7. IANA considerations 2424 There are no IANA considerations with respect to this document 2426 8. Contributors and Acknowledgments 2428 Significant parts of the text of this document is copied from RFC 2429 4641 [RFC4641]. That document was edited by Olaf Kolkman and Miek 2430 Gieben. Other people that contributed or where otherwise involved in 2431 that work were in random order: Rip Loomis, Olafur Gudmundsson, 2432 Wesley Griffin, Michael Richardson, Scott Rose, Rick van Rein, Tim 2433 McGinnis, Gilles Guette, Olivier Courtay, Sam Weiler, Jelte Jansen, 2434 Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, 2435 Peter Koch, Mike StJohns, Emma Bretherick, Adrian Bedford, Lindy 2436 Foster, and O. Courtay. 2438 For this version of the document we would like to acknowledge a few 2439 people for significant contributions: 2441 Paul Hoffman for his contribution on the choice of cryptographic 2442 parameters and addressing some of the trust anchor issues; 2444 Jelte Jansen who provided the initial text in Section 4.1.4; 2446 Paul Wouters who provided the initial text for Section 5 and Alex 2447 Bligh who improved it; 2449 Erik Rescorla whose blogpost on "the Security of ZSK rollovers" 2450 inspired text in Section 3.1; 2452 Stephen Morris who made a pass on English style and grammar; 2454 Olafur Gudmundsson and Ondrej Sury who provided input on 2455 Section 4.1.4 based on actual operational experience. 2457 Rickard Bellgrim reviewed the document extensively. 2459 The figure in Section 4.4.2 was adapted from the OpenDNSSEC user 2460 documentation. 2462 In addition valuable contributions in the form of text, comments, or 2463 review where provided by Mark Andrews, Patrik Faltstrom, Tony Finch, 2464 Alfred Hoenes, Bill Manning, Scott Rose, Wouter Wijngaards, Antoin 2465 Verschuren, Marc Lampo, George Barwood, Sebastian Castro and Suresh 2466 Krishnaswamy. 2468 9. References 2470 9.1. Normative References 2472 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2473 STD 13, RFC 1034, November 1987. 2475 [RFC1035] Mockapetris, P., "Domain names - implementation and 2476 specification", STD 13, RFC 1035, November 1987. 2478 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2479 Rose, "DNS Security Introduction and Requirements", 2480 RFC 4033, March 2005. 2482 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2483 Rose, "Resource Records for the DNS Security Extensions", 2484 RFC 4034, March 2005. 2486 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2487 Rose, "Protocol Modifications for the DNS Security 2488 Extensions", RFC 4035, March 2005. 2490 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 2491 (DS) Resource Records (RRs)", RFC 4509, May 2006. 2493 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 2494 Security (DNSSEC) Hashed Authenticated Denial of 2495 Existence", RFC 5155, March 2008. 2497 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 2498 and RRSIG Resource Records for DNSSEC", RFC 5702, 2499 October 2009. 2501 9.2. Informative References 2503 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 2504 August 1996. 2506 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 2507 Changes (DNS NOTIFY)", RFC 1996, August 1996. 2509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2510 Requirement Levels", BCP 14, RFC 2119, March 1997. 2512 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 2513 NCACHE)", RFC 2308, March 1998. 2515 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 2516 Update", RFC 3007, November 2000. 2518 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol 2519 Requirements", RFC 3375, September 2002. 2521 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 2522 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 2523 RFC 3766, April 2004. 2525 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2526 Requirements for Security", BCP 106, RFC 4086, June 2005. 2528 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 2529 RFC 4641, September 2006. 2531 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2532 RFC 4949, August 2007. 2534 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 2535 Trust Anchors", RFC 5011, September 2007. 2537 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 2538 Security Extensions Mapping for the Extensible 2539 Provisioning Protocol (EPP)", RFC 5910, May 2010. 2541 [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST 2542 Signature Algorithms in DNSKEY and RRSIG Resource Records 2543 for DNSSEC", RFC 5933, July 2010. 2545 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 2546 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 2547 April 2012. 2549 [NIST-workshop] 2550 Rose, S., "NIST DNSSEC workshop notes", July 2001, . 2554 [NIST-SP-800-90A] 2555 Barker, E. and J. Kelsey, "Recommendation for Random 2556 Number Generation Using Deterministic Random Bit 2557 Generators (Revised)", NIST Special Publication 800-90, 2558 March 2007. 2560 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2561 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2563 [I-D.ietf-dnsop-dnssec-key-timing] 2564 Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key 2565 Timing Considerations", 2566 draft-ietf-dnsop-dnssec-key-timing-03 (work in progress), 2567 July 2012. 2569 [I-D.ietf-dnsop-dnssec-dps-framework] 2570 Ljunggren, F., Eklund-Lowinder, A., and T. Okubo, "A 2571 Framework for DNSSEC Policies and DNSSEC Practice 2572 Statements", draft-ietf-dnsop-dnssec-dps-framework-08 2573 (work in progress), June 2012. 2575 [I-D.ietf-dnsop-dnssec-trust-anchor] 2576 Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor 2577 Configuration and Maintenance", 2578 draft-ietf-dnsop-dnssec-trust-anchor-04 (work in 2579 progress), October 2010. 2581 [nsec3-hash-performance] 2582 Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs 2583 document 2010-02, March 2010. 2585 Appendix A. Terminology 2587 In this document, there is some jargon used that is defined in other 2588 documents. In most cases, we have not copied the text from the 2589 documents defining the terms but have given a more elaborate 2590 explanation of the meaning. Note that these explanations should not 2591 be seen as authoritative. 2593 Anchored key: A DNSKEY configured in resolvers around the globe. 2594 This key is hard to update, hence the term anchored. 2596 Bogus: Also see Section 5 of RFC 4033 [RFC4033]. An RRset in DNSSEC 2597 is marked "Bogus" when a signature of an RRset does not validate 2598 against a DNSKEY. 2600 Key rollover: A key rollover (also called key supercession in some 2601 environments) is the act of replacing one key pair with another at 2602 the end of a key effectivity period. 2604 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is 2605 used exclusively for signing the apex key set. The fact that a 2606 key is a KSK is only relevant to the signing tool. 2608 Key size: The term 'key size' can be substituted by 'modulus size' 2609 throughout the document for RSA keys. It is mathematically more 2610 correct to use modulus size for RSA keys, but as this is a 2611 document directed at operators we feel more at ease with the term 2612 key size. 2614 Private and public keys: DNSSEC secures the DNS through the use of 2615 public key cryptography. Public key cryptography is based on the 2616 existence of two (mathematically related) keys, a public key and a 2617 private key. The public keys are published in the DNS by use of 2618 the DNSKEY Resource Record (DNSKEY RR). Private keys should 2619 remain private. 2621 Refresh Period: The period before the expiration time of the 2622 signature, during which the signature is refreshed by the signer. 2624 Re-Sign Period: This refers to the frequency with which a signing 2625 pass on the zone is performed. The Re-Sign Period defines when 2626 the zone is exposed to the signer. And on the signer - not all 2627 signatures in the zone have to be regenerated: that depends on the 2628 Refresh Period. 2630 Secure Entry Point (SEP) key: A KSK that has a DS record in the 2631 parent zone pointing to it or is configured as a trust anchor. 2632 Although not required by the protocol, we suggest that the SEP 2633 flag [RFC4034] is set on these keys. 2635 Self-signature: This only applies to signatures over DNSKEYs; a 2636 signature made with DNSKEY x over DNSKEY x is called a self- 2637 signature. Note: without further information, self-signatures 2638 convey no trust. They are useful to check the authenticity of the 2639 DNSKEY, i.e., they can be used as a hash. 2641 Signing Jitter: A random variation in the signature validity period 2642 of RRSIGs in a zone to prevent all of them expiring at the same 2643 time. 2645 Signer: The system that has access to the private key material and 2646 signs the Resource Record sets in a zone. A signer may be 2647 configured to sign only parts of the zone, e.g., only those RRsets 2648 for which existing signatures are about to expire. 2650 Singing the zone file: The term used for the event where an 2651 administrator joyfully signs its zone file while producing melodic 2652 sound patterns. 2654 Single Type Signing Scheme: A signing scheme whereby the distinction 2655 between Zone Signing Keys and Key Signing Keys is not made. 2657 Zone administrator: The 'role' that is responsible for signing a 2658 zone and publishing it on the primary authoritative server. 2660 Zone Signing Key (ZSK): A key that is used for signing all data in a 2661 zone (except, perhaps, the DNSKEY RRset). The fact that a key is 2662 a ZSK is only relevant to the signing tool. 2664 Appendix B. Typographic Conventions 2666 The following typographic conventions are used in this document: 2668 Key notation: A key is denoted by DNSKEY_x_y, where x is an 2669 identifier for the type of key: K for Keys Signing Key, Z for Zone 2670 Signing Key and S when there is no distinction made between KSK 2671 and ZSKs but the key is used as a secure entry point. The 'y' 2672 denotes a number or an identifier, y could be thought of as the 2673 key id. 2675 RRsets ignored: If the signatures of non-DNSKEY RRsets have the same 2676 parameters as the SOA, then those are not mentioned; e.g., in the 2677 example below, the SOA is signed with the same parameters as the 2678 foo.example.com A RRset and the latter is therefore ignored in the 2679 abbreviated notation. 2681 RRset notations: RRs are only denoted by the type. All other 2682 information -- owner, class, rdata, and TTL -- is left out. Thus: 2683 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRsets are a 2684 list of RRs. A example of this would be "A1, A2", specifying the 2685 RRset containing two "A" records. This could again be abbreviated 2686 to just "A". 2688 Signature notation: Signatures are denoted as RRSIG_x_y(type), which 2689 means that the RRset with the specific RRtype 'type' is signed 2690 with DNSKEY_x_y. Signatures in the parent zone are denoted as 2691 RRSIG_par(type). 2693 SOA representation: SOAs are represented as SOA_x, where x is the 2694 serial number. 2696 DS representation: DSs are represented as DS_x_y, where x and y are 2697 identifiers similar to the key notation: x is an an identifier for 2698 the type of key the DS record refers to, y is the 'key id' of the 2699 key it refers to. 2701 Zone representation: Using the above notation we have simplified the 2702 representation of a signed zone by leaving out all unnecessary 2703 details such as the names and by representing all data by "SOA_x" 2705 Using this notation the following signed zone: 2707 example.com. 3600 IN SOA ns1.example.com. olaf.example.net. ( 2708 2005092303 ; serial 2709 450 ; refresh (7 minutes 30 seconds) 2710 600 ; retry (10 minutes) 2711 345600 ; expire (4 days) 2712 300 ; minimum (5 minutes) 2713 ) 2714 3600 RRSIG SOA 5 2 3600 20120824013000 ( 2715 20100424013000 14 example.com. 2716 NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo 2717 ... 2718 OMY3rTMA2qorupQXjQ== ) 2719 3600 NS ns1.example.com. 2720 3600 NS ns2.example.com. 2721 3600 NS ns3.example.com. 2722 3600 RRSIG NS 5 2 3600 20120824013000 ( 2723 20100424013000 14 example.com. 2724 p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz 2725 ... 2726 +SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4 2727 zAgaJM/MeG08KpeHhg== ) 2728 3600 TXT "Net::DNS domain" 2729 3600 RRSIG TXT 5 2 3600 20120824013000 ( 2730 20100424013000 14 example.com. 2731 o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp 2732 ... 2733 BcQ1o99vwn+IS4+J1g== ) 2734 300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY 2735 300 RRSIG NSEC 5 2 300 20120824013000 ( 2736 20100424013000 14 example.com. 2737 JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+ 2738 ... 2739 PkXNI/Vgf4t3xZaIyw== ) 2740 3600 DNSKEY 256 3 5 ( 2741 AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX 2742 ... 2743 sAuryjQ/HFa5r4mrbhkJ 2744 ) ; key id = 14 2745 3600 DNSKEY 257 3 5 ( 2746 AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO 2747 ... 2748 oy88Nh+u2c9HF1tw0naH 2749 ) ; key id = 15 2750 3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 2751 20100424013000 14 example.com. 2752 HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U 2753 ... 2754 QhhmMwV3tIxJk2eDRQ== ) 2755 3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 2756 20100424013000 15 example.com. 2757 P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE 2758 ... 2759 JWL70YiUnUG3m9OL9w== ) 2761 foo.example.com. 3600 IN A 192.0.2.2 2762 3600 RRSIG A 5 3 3600 20120824013000 ( 2763 20100424013000 14 example.com. 2764 xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO 2765 ... 2766 JPV/SA4BkoFxIcPrDQ== ) 2767 300 NSEC example.com. A RRSIG NSEC 2768 300 RRSIG NSEC 5 3 300 20120824013000 ( 2769 20100424013000 14 example.com. 2770 Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF 2771 ... 2772 Qe000JyzObxx27pY8A== ) 2774 is reduced to the following representation: 2776 SOA_2005092303 2777 RRSIG_Z_14(SOA_2005092303) 2778 DNSKEY_K_14 2779 DNSKEY_Z_15 2780 RRSIG_K_14(DNSKEY) 2781 RRSIG_Z_15(DNSKEY) 2783 The rest of the zone data has the same signature as the SOA record, 2784 i.e., an RRSIG created with DNSKEY 14. 2786 Appendix C. Transition Figures for Special Case Algorithm Rollovers 2788 The figures in this Appendix complement and illustrate the special 2789 cases of algorithm rollovers as described in Section 4.1.4. 2791 ---------------------------------------------------------------- 2792 initial new RRSIGs new DNSKEY 2793 ---------------------------------------------------------------- 2794 Parent: 2795 SOA_0 --------------------------------------------------------> 2796 RRSIG_par(SOA) -----------------------------------------------> 2797 DS_S_1 -------------------------------------------------------> 2798 RRSIG_par(DS_S_1) --------------------------------------------> 2800 Child: 2801 SOA_0 SOA_1 SOA_2 2802 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA) 2803 RRSIG_S_2(SOA) RRSIG_S_2(SOA) 2805 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 2806 DNSKEY_S_2 2807 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) 2808 RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) 2810 ---------------------------------------------------------------- 2811 new DS DNSKEY removal RRSIGs removal 2812 ---------------------------------------------------------------- 2813 Parent: 2814 SOA_1 -------------------------------------------------------> 2815 RRSIG_par(SOA) ----------------------------------------------> 2816 DS_S_2 ------------------------------------------------------> 2817 RRSIG_par(DS_S_2) -------------------------------------------> 2819 Child: 2820 -------------------> SOA_3 SOA_4 2821 -------------------> RRSIG_S_1(SOA) 2822 -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA) 2824 -------------------> 2825 -------------------> DNSKEY_S_2 DNSKEY_S_2 2826 -------------------> RRSIG_S_1(DNSKEY) 2827 -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) 2828 ---------------------------------------------------------------- 2830 Figure 12: Single Type Signing Scheme Algorithm Roll 2832 Also see Section 4.1.4.1. 2834 ---------------------------------------------------------------- 2835 initial new RRSIGs new DNSKEY 2836 ---------------------------------------------------------------- 2837 Parent: 2838 SOA_0 --------------------------------------------------------> 2839 RRSIG_par(SOA) -----------------------------------------------> 2840 DS_K_1 -------------------------------------------------------> 2841 RRSIG_par(DS_K_1) --------------------------------------------> 2843 Child: 2844 SOA_0 SOA_1 SOA_2 2845 RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) 2846 RRSIG_Z_2(SOA) RRSIG_Z_2(SOA) 2848 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 2849 DNSKEY_K_2 2850 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1 2851 DNSKEY_Z_2 2852 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) 2853 RRSIG_K_2(DNSKEY) 2855 ---------------------------------------------------------------- 2856 new DS revoke DNSKEY DNSKEY removal 2857 ---------------------------------------------------------------- 2858 Parent: 2859 SOA_1 -------------------------------------------------------> 2860 RRSIG_par(SOA) ----------------------------------------------> 2861 DS_K_2 ------------------------------------------------------> 2862 RRSIG_par(DS_K_2) -------------------------------------------> 2864 Child: 2865 -------------------> SOA_3 SOA_4 2866 -------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) 2867 -------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA) 2869 -------------------> DNSKEY_K_1_REVOKED 2870 -------------------> DNSKEY_K_2 DNSKEY_K_2 2871 -------------------> 2872 -------------------> DNSKEY_Z_2 DNSKEY_Z_2 2873 -------------------> RRSIG_K_1(DNSKEY) 2874 -------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY) 2876 ---------------------------------------------------------------- 2877 RRSIGs removal 2878 ---------------------------------------------------------------- 2879 Parent: 2880 -------------------------------------> 2881 -------------------------------------> 2882 -------------------------------------> 2883 -------------------------------------> 2885 Child: 2886 SOA_5 2887 RRSIG_Z_2(SOA) 2889 DNSKEY_K_2 2891 DNSKEY_Z_2 2893 RRSIG_K_2(DNSKEY) 2894 ---------------------------------------------------------------- 2896 Figure 13: RFC 5011 Style algorithm roll 2898 Also see Section 4.1.4.2. 2900 ---------------------------------------------------------------- 2901 initial new RRSIGs new DNSKEY 2902 ---------------------------------------------------------------- 2903 Parent: 2904 SOA_0 --------------------------------------------------------> 2905 RRSIG_par(SOA) -----------------------------------------------> 2906 DS_S_1 -------------------------------------------------------> 2907 RRSIG_par(DS_S_1) --------------------------------------------> 2909 Child: 2910 SOA_0 SOA_1 SOA_2 2911 RRSIG_S_1(SOA) 2912 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) 2913 RRSIG_S_2(SOA) RRSIG_S_2(SOA) 2915 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 2916 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 2917 DNSKEY_S_2 2918 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) 2919 RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) 2921 ---------------------------------------------------------------- 2922 new DS revoke DNSKEY DNSKEY removal 2923 ---------------------------------------------------------------- 2924 Parent: 2925 SOA_1 -------------------------------------------------------> 2926 RRSIG_par(SOA) ----------------------------------------------> 2927 DS_S_2 ------------------------------------------------------> 2928 RRSIG_par(DS_S_2) -------------------------------------------> 2930 Child: 2931 -------------------> SOA_3 SOA_4 2933 -------------------> RRSIG_Z_10(SOA) 2934 -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA) 2936 -------------------> DNSKEY_S_1_REVOKED 2937 -------------------> DNSKEY_Z_10 2938 -------------------> DNSKEY_S_2 DNSKEY_S_2 2939 -------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) 2940 -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) 2942 ---------------------------------------------------------------- 2943 RRSIGs removal 2944 ---------------------------------------------------------------- 2945 Parent: 2946 -------------------------------------> 2947 -------------------------------------> 2948 -------------------------------------> 2949 -------------------------------------> 2951 Child: 2952 SOA_5 2954 RRSIG_S_2(SOA) 2956 DNSKEY_S_2 2958 RRSIG_S_2(DNSKEY) 2959 ---------------------------------------------------------------- 2961 Figure 14: RFC 5011 algorithm roll in a Single Type Signing Scheme 2962 Environment 2964 Also see Section 4.1.4.3. 2966 Appendix D. Transition Figure for Changing DNS Operators 2968 The figure in this Appendix complements and illustrates the special 2969 case of changing DNS operators as described in Section 4.3.5.1. 2971 ------------------------------------------------------------ 2972 new DS | pre-publish | 2973 ------------------------------------------------------------ 2974 Parent: 2975 NS_A NS_A 2976 DS_A DS_B DS_A DS_B 2977 ------------------------------------------------------------ 2978 Child at A: Child at A: Child at B: 2979 SOA_A0 SOA_A1 SOA_B0 2980 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) 2982 NS_A NS_A NS_B 2983 RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) 2984 RRSIG_Z_A(NS) 2986 DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A 2987 DNSKEY_Z_B DNSKEY_Z_B 2988 DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B 2989 RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) 2990 RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) 2991 ------------------------------------------------------------ 2993 ------------------------------------------------------------ 2994 redelegation | post migration | 2995 ------------------------------------------------------------ 2996 Parent: 2997 NS_B NS_B 2998 DS_A DS_B DS_B 2999 ------------------------------------------------------------ 3000 Child at A: Child at B: Child at B: 3002 SOA_A1 SOA_B0 SOA_B1 3003 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) 3005 NS_A NS_B NS_B 3006 NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) 3007 RRSIG_Z_A(NS) 3009 DNSKEY_Z_A DNSKEY_Z_A 3010 DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B 3011 DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B 3012 RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) 3014 ------------------------------------------------------------ 3016 Figure 15: An alternative rollover approach for cooperating operators 3018 Appendix E. Summary of Changes from RFC 4641 3020 This document differs from RFC 4641 [RFC4641] in the following ways: 3022 o Applied the errata from 3023 http://www.rfc-editor.org/errata_search.php?rfc=4641 3025 o RSA/SHA256 is being recommended in addition to RSA/SHA1. 3027 o Complete rewrite of Section 3.4.2 removing the table and 3028 suggesting a keysize of 1024 for keys in use for less than 8 3029 years, issued up to at least 2015. 3031 o Removed the KSK for high level zones consideration. 3033 o Added text on Algorithm Rollover. 3035 o Added text on Changing (non cooperating) DNS Registrars. 3037 o Significant rewrite of Section 3 whereby the argument is made that 3038 the timescales for rollovers are made purely on operational 3039 arguments. 3041 o Added Section 5. 3043 o Introduced Single Type Signing Scheme terminology and made the 3044 arguments for the choice of a Single Type Signing Scheme more 3045 explicit. 3047 o Added a section about Stand-by keys 3049 Appendix F. Document Editing History 3051 [To be removed prior to publication as an RFC] 3053 F.1. draft-ietf-dnsop-rfc4641-00 3055 Version 0 was differs from RFC 4641 in the following ways. 3057 o Status of this memo appropriate for I-D 3059 o TOC formatting differs. 3061 o Whitespaces, linebreaks, and pagebreaks may be slightly different 3062 because of xml2rfc generation. 3064 o References slightly reordered. 3066 o Applied the errata from 3067 http://www.rfc-editor.org/errata_search.php?rfc=4641 3069 o Inserted trivial "IANA considerations" section. 3071 In other words it should not contain substantive changes in content 3072 as intended by the working group for the original RFC 4641. 3074 F.2. version 0->1 3076 Cryptography details rewritten. (See http://www.nlnetlabs.nl/svn/ 3077 rfc4641bis/trunk/open-issues/cryptography_flawed) 3079 o Reference to NIST 800-90 added 3081 o RSA/SHA256 is being recommended in addition to RSA/SHA1. 3083 o Complete rewrite of Section 3.4.2 removing the table and 3084 suggesting a keysize of 1024 for keys in use for less than 8 3085 years, issued up to at least 2015. 3087 o Replaced the reference to Schneiers' applied cryptography with a 3088 reference to RFC 4949. 3090 o Removed the KSK for high level zones consideration 3092 Applied some differentiation with respect of the use of a KSK for 3093 parent or trust anchor relation http://www.nlnetlabs.nl/svn/ 3094 rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent 3096 http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 3097 rollover_assumptions 3099 Added Section 4.1.4 as suggested by Jelte Jansen in http:// 3100 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll 3102 Added Section 4.3.5.2 Issue identified by Antoin Verschuren http:// 3103 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 3104 non-cooperative-registrars 3106 In Appendix A: ZSK does not necessarily sign the DNSKEY RRset. 3108 F.3. version 1->2 3110 o Significant rewrite of Section 3 whereby the argument is made that 3111 the timescales for rollovers are made purely on operational 3112 arguments hopefully resolving http://www.nlnetlabs.nl/svn/ 3113 rfc4641bis/trunk/open-issues/discussion_of_timescales 3115 o Added Section 5 based on http://www.nlnetlabs.nl/svn/rfc4641bis/ 3116 trunk/open-issues/NSEC-NSEC3 3118 o Added a reference to draft-morris-dnsop-dnssec-key-timing 3119 [I-D.ietf-dnsop-dnssec-key-timing] for the quantitative analysis 3120 on keyrolls 3122 o Updated Section 4.3.5 to reflect that the problem occurs when 3123 changing DNS operators, and not DNS registrars, also added the 3124 table indicating the redelegation procedure. Added text about the 3125 fact that implementations will dismiss keys that fail to validate 3126 at some point. 3128 o Updated a number of references. 3130 F.4. version 2->3 3132 o Added bulleted list to serve as an introduction on the decision 3133 tree in Section 3. 3135 o In section Section 3.1: 3137 * tried to motivate that key length is not a strong motivation 3138 for KSK ZSK split (based on http://www.educatedguesswork.org/ 3139 2009/10/on_the_security_of_zsk_rollove.html) 3141 * Introduced Common Signing Key terminology and made the 3142 arguments for the choice of a Common Signing Key more explicit. 3144 * Moved the SEP flag considerations to its own paragraph 3146 o In a few places in the document, but section Section 4 in 3147 particular the comments from Patrik Faltstrom (On Mar 24, 2010) on 3148 the clarity on the roles of the registrant, dns operator, 3149 registrar and registry was addressed. 3151 o Added some terms based on http://www.nlnetlabs.nl/svn/rfc4641bis/ 3152 trunk/open-issues/timing_terminology 3154 o Added paragraph 2 and clarified the second but last paragraph of 3155 Section 3.2.2. 3157 o Clarified the table and some text in Section 4.1.4. Also added 3158 some text on what happens when the algorithm rollover also 3159 involves a roll from NSEC to NSEC3. 3161 o Added a paragraph about rolling KSKs that are also configured as 3162 trust anchors in Section 4.1.2 3164 o Added Section 4.1.3. 3166 o Added Section 4.4.2 to address issue "Signature_validity" 3168 F.5. version 3->4 3170 o Stephen Morris submitted a large number of language, style and 3171 editorial nits. 3173 o Section 4.1.4 improved based on comments from Olafur Gudmundsson 3174 and Ondrej Sury. 3176 o Tried to improve consistency of notation in the various rollover 3177 figures 3179 F.6. version 4->5 3181 o Improved consistency of notation 3183 o Matthijs Mekking provided substantive feedback on algorithm 3184 rollover and suggested the content of the subsections of 3185 Section 4.1.4 and the content of the figures in Appendix C 3187 F.7. version 5->6 3189 o More improved consistency of notation and some other nits 3190 o Review of Rickard Bellgrim 3192 o Review of Sebastian Castro 3194 o Added a section about Stand-by keys 3196 o Algorithm rollover: Conservative or Liberal Approach 3198 o Added a reference to NSEC3 hash performance report 3200 o More clarifications on the topic of non cooperating operators 3202 F.8. version 6->7 3204 o Fixed minor nits. 3206 o Clarified the Double DS Rollover in Changing DNS Operator 3207 sections. 3209 o Adjusted STSS Rollover Figures. 3211 o Remove the ZSK RRSIGs over DNSKEY RRset in Figures. 3213 o Added text: second variety on STSS Double DS Rollover. 3215 o Reviewed by Antoin Verschuren, Marc Lampo, George Barwood. 3217 F.9. version 7->8 3219 o Signatures over DNSKEY RRset does not need to be propagated in the 3220 new RRSIGS step. 3222 F.10. version 8->9 3224 o Peter Koch and Stephen Morris review 3226 o Editorial changes 3228 o Added Appendix D for clarifying the alternative approach on 3229 rollover for cooperating operators. 3231 o Added a paragraph to explain the rollover described in the figure 3232 in a bit more detail, in Section 4.3.5. 3234 F.11. version 9->10 3236 o Final nits 3238 o Symbolic references 3240 F.12. version 10->11 3242 o More review (Alfred Hoenes, Marc Lampo, Miek Gieben, Stephen 3243 Morris) 3245 o Style, language and layout changes to improve consistency and 3246 resolving ambiguity and removing duplicate sentences. 3248 o More clarifications 3250 o Small restructuring of paragraphs that fit better in other 3251 sections 3253 F.13. version 11->12 3255 o WG chairs review 3257 F.14. version 12->13 3259 o Fixed editors name (Miek Gieben) 3261 o Review Yuri Schaeffer, Ed Lewis 3263 o IESG, Gen-ART, secdir reviews 3265 F.15. Subversion information 3267 www.nlnetlabs.nl/svn/rfc4641bis/ 3269 $Id: draft-ietf-dnsop-rfc4641bis.xml 127 2012-08-30 10:02:15Z matje $ 3271 Authors' Addresses 3273 Olaf M. Kolkman 3274 NLnet Labs 3275 Science Park 400 3276 Amsterdam 1098 XH 3277 The Netherlands 3279 Email: olaf@nlnetlabs.nl 3280 URI: http://www.nlnetlabs.nl 3282 W. (Matthijs) Mekking 3283 NLnet Labs 3284 Science Park 400 3285 Amsterdam 1098 XH 3286 The Netherlands 3288 Email: matthijs@nlnetlabs.nl 3289 URI: http://www.nlnetlabs.nl 3291 R. (Miek) Gieben 3292 SIDN Labs 3293 Meander 501 3294 Arnhem 6825 MD 3295 The Netherlands 3297 Email: miek.gieben@sidn.nl 3298 URI: http://www.sidn.nl