1 2 3 4 5 6 7Network Working Group O. Kolkman 8Request for Comments: 4641 R. Gieben 9Obsoletes: 2541 NLnet Labs 10Category: Informational September 2006 11 12 13 DNSSEC Operational Practices 14 15Status of This Memo 16 17 This memo provides information for the Internet community. It does 18 not specify an Internet standard of any kind. Distribution of this 19 memo is unlimited. 20 21Copyright Notice 22 23 Copyright (C) The Internet Society (2006). 24 25Abstract 26 27 This document describes a set of practices for operating the DNS with 28 security extensions (DNSSEC). The target audience is zone 29 administrators deploying DNSSEC. 30 31 The document discusses operational aspects of using keys and 32 signatures in the DNS. It discusses issues of key generation, key 33 storage, signature generation, key rollover, and related policies. 34 35 This document obsoletes RFC 2541, as it covers more operational 36 ground and gives more up-to-date requirements with respect to key 37 sizes and the new DNSSEC specification. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Kolkman & Gieben Informational [Page 1] 59 60RFC 4641 DNSSEC Operational Practices September 2006 61 62 63Table of Contents 64 65 1. Introduction ....................................................3 66 1.1. The Use of the Term 'key' ..................................4 67 1.2. Time Definitions ...........................................4 68 2. Keeping the Chain of Trust Intact ...............................5 69 3. Keys Generation and Storage .....................................6 70 3.1. Zone and Key Signing Keys ..................................6 71 3.1.1. Motivations for the KSK and ZSK Separation ..........6 72 3.1.2. KSKs for High-Level Zones ...........................7 73 3.2. Key Generation .............................................8 74 3.3. Key Effectivity Period .....................................8 75 3.4. Key Algorithm ..............................................9 76 3.5. Key Sizes ..................................................9 77 3.6. Private Key Storage .......................................11 78 4. Signature Generation, Key Rollover, and Related Policies .......12 79 4.1. Time in DNSSEC ............................................12 80 4.1.1. Time Considerations ................................12 81 4.2. Key Rollovers .............................................14 82 4.2.1. Zone Signing Key Rollovers .........................14 83 4.2.1.1. Pre-Publish Key Rollover ..................15 84 4.2.1.2. Double Signature Zone Signing Key 85 Rollover ..................................17 86 4.2.1.3. Pros and Cons of the Schemes ..............18 87 4.2.2. Key Signing Key Rollovers ..........................18 88 4.2.3. Difference Between ZSK and KSK Rollovers ...........20 89 4.2.4. Automated Key Rollovers ............................21 90 4.3. Planning for Emergency Key Rollover .......................21 91 4.3.1. KSK Compromise .....................................22 92 4.3.1.1. Keeping the Chain of Trust Intact .........22 93 4.3.1.2. Breaking the Chain of Trust ...............23 94 4.3.2. ZSK Compromise .....................................23 95 4.3.3. Compromises of Keys Anchored in Resolvers ..........24 96 4.4. Parental Policies .........................................24 97 4.4.1. Initial Key Exchanges and Parental Policies 98 Considerations .....................................24 99 4.4.2. Storing Keys or Hashes? ............................25 100 4.4.3. Security Lameness ..................................25 101 4.4.4. DS Signature Validity Period .......................26 102 5. Security Considerations ........................................26 103 6. Acknowledgments ................................................26 104 7. References .....................................................27 105 7.1. Normative References ......................................27 106 7.2. Informative References ....................................28 107 Appendix A. Terminology ...........................................30 108 Appendix B. Zone Signing Key Rollover How-To ......................31 109 Appendix C. Typographic Conventions ...............................32 110 111 112 113 114Kolkman & Gieben Informational [Page 2] 115 116RFC 4641 DNSSEC Operational Practices September 2006 117 118 1191. Introduction 120 121 This document describes how to run a DNS Security (DNSSEC)-enabled 122 environment. It is intended for operators who have knowledge of the 123 DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. 124 See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the 125 newly introduced Resource Records (RRs), and RFC 4035 [6] for the 126 protocol changes. 127 128 During workshops and early operational deployment tests, operators 129 and system administrators have gained experience about operating the 130 DNS with security extensions (DNSSEC). This document translates 131 these experiences into a set of practices for zone administrators. 132 At the time of writing, there exists very little experience with 133 DNSSEC in production environments; this document should therefore 134 explicitly not be seen as representing 'Best Current Practices'. 135 136 The procedures herein are focused on the maintenance of signed zones 137 (i.e., signing and publishing zones on authoritative servers). It is 138 intended that maintenance of zones such as re-signing or key 139 rollovers be transparent to any verifying clients on the Internet. 140 141 The structure of this document is as follows. In Section 2, we 142 discuss the importance of keeping the "chain of trust" intact. 143 Aspects of key generation and storage of private keys are discussed 144 in Section 3; the focus in this section is mainly on the private part 145 of the key(s). Section 4 describes considerations concerning the 146 public part of the keys. Since these public keys appear in the DNS 147 one has to take into account all kinds of timing issues, which are 148 discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the 149 rollover, or supercession, of keys. Finally, Section 4.4 discusses 150 considerations on how parents deal with their children's public keys 151 in order to maintain chains of trust. 152 153 The typographic conventions used in this document are explained in 154 Appendix C. 155 156 Since this is a document with operational suggestions and there are 157 no protocol specifications, the RFC 2119 [7] language does not apply. 158 159 This document obsoletes RFC 2541 [12] to reflect the evolution of the 160 underlying DNSSEC protocol since then. Changes in the choice of 161 cryptographic algorithms, DNS record types and type names, and the 162 parent-child key and signature exchange demanded a major rewrite and 163 additional information and explanation. 164 165 166 167 168 169 170Kolkman & Gieben Informational [Page 3] 171 172RFC 4641 DNSSEC Operational Practices September 2006 173 174 1751.1. The Use of the Term 'key' 176 177 It is assumed that the reader is familiar with the concept of 178 asymmetric keys on which DNSSEC is based (public key cryptography 179 [17]). Therefore, this document will use the term 'key' rather 180 loosely. Where it is written that 'a key is used to sign data' it is 181 assumed that the reader understands that it is the private part of 182 the key pair that is used for signing. It is also assumed that the 183 reader understands that the public part of the key pair is published 184 in the DNSKEY Resource Record and that it is the public part that is 185 used in key exchanges. 186 1871.2. Time Definitions 188 189 In this document, we will be using a number of time-related terms. 190 The following definitions apply: 191 192 o "Signature validity period" The period that a signature is valid. 193 It starts at the time specified in the signature inception field 194 of the RRSIG RR and ends at the time specified in the expiration 195 field of the RRSIG RR. 196 197 o "Signature publication period" Time after which a signature (made 198 with a specific key) is replaced with a new signature (made with 199 the same key). This replacement takes place by publishing the 200 relevant RRSIG in the master zone file. After one stops 201 publishing an RRSIG in a zone, it may take a while before the 202 RRSIG has expired from caches and has actually been removed from 203 the DNS. 204 205 o "Key effectivity period" The period during which a key pair is 206 expected to be effective. This period is defined as the time 207 between the first inception time stamp and the last expiration 208 date of any signature made with this key, regardless of any 209 discontinuity in the use of the key. The key effectivity period 210 can span multiple signature validity periods. 211 212 o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum 213 value of the TTLs from the complete set of RRs in a zone. Note 214 that the minimum TTL is not the same as the MINIMUM field in the 215 SOA RR. See [11] for more information. 216 217 218 219 220 221 222 223 224 225 226Kolkman & Gieben Informational [Page 4] 227 228RFC 4641 DNSSEC Operational Practices September 2006 229 230 2312. Keeping the Chain of Trust Intact 232 233 Maintaining a valid chain of trust is important because broken chains 234 of trust will result in data being marked as Bogus (as defined in [4] 235 Section 5), which may cause entire (sub)domains to become invisible 236 to verifying clients. The administrators of secured zones have to 237 realize that their zone is, to verifying clients, part of a chain of 238 trust. 239 240 As mentioned in the introduction, the procedures herein are intended 241 to ensure that maintenance of zones, such as re-signing or key 242 rollovers, will be transparent to the verifying clients on the 243 Internet. 244 245 Administrators of secured zones will have to keep in mind that data 246 published on an authoritative primary server will not be immediately 247 seen by verifying clients; it may take some time for the data to be 248 transferred to other secondary authoritative nameservers and clients 249 may be fetching data from caching non-authoritative servers. In this 250 light, note that the time for a zone transfer from master to slave is 251 negligible when using NOTIFY [9] and incremental transfer (IXFR) [8]. 252 It increases when full zone transfers (AXFR) are used in combination 253 with NOTIFY. It increases even more if you rely on full zone 254 transfers based on only the SOA timing parameters for refresh. 255 256 For the verifying clients, it is important that data from secured 257 zones can be used to build chains of trust regardless of whether the 258 data came directly from an authoritative server, a caching 259 nameserver, or some middle box. Only by carefully using the 260 available timing parameters can a zone administrator ensure that the 261 data necessary for verification can be obtained. 262 263 The responsibility for maintaining the chain of trust is shared by 264 administrators of secured zones in the chain of trust. This is most 265 obvious in the case of a 'key compromise' when a trade-off between 266 maintaining a valid chain of trust and replacing the compromised keys 267 as soon as possible must be made. Then zone administrators will have 268 to make a trade-off, between keeping the chain of trust intact -- 269 thereby allowing for attacks with the compromised key -- or 270 deliberately breaking the chain of trust and making secured 271 subdomains invisible to security-aware resolvers. Also see Section 272 4.3. 273 274 275 276 277 278 279 280 281 282Kolkman & Gieben Informational [Page 5] 283 284RFC 4641 DNSSEC Operational Practices September 2006 285 286 2873. Keys Generation and Storage 288 289 This section describes a number of considerations with respect to the 290 security of keys. It deals with the generation, effectivity period, 291 size, and storage of private keys. 292 2933.1. Zone and Key Signing Keys 294 295 The DNSSEC validation protocol does not distinguish between different 296 types of DNSKEYs. All DNSKEYs can be used during the validation. In 297 practice, operators use Key Signing and Zone Signing Keys and use the 298 so-called Secure Entry Point (SEP) [3] flag to distinguish between 299 them during operations. The dynamics and considerations are 300 discussed below. 301 302 To make zone re-signing and key rollover procedures easier to 303 implement, it is possible to use one or more keys as Key Signing Keys 304 (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. 305 Other keys can be used to sign all the RRSets in a zone and are 306 referred to as Zone Signing Keys (ZSKs). In this document, we assume 307 that KSKs are the subset of keys that are used for key exchanges with 308 the parent and potentially for configuration as trusted anchors -- 309 the SEP keys. In this document, we assume a one-to-one mapping 310 between KSK and SEP keys and we assume the SEP flag to be set on all 311 KSKs. 312 3133.1.1. Motivations for the KSK and ZSK Separation 314 315 Differentiating between the KSK and ZSK functions has several 316 advantages: 317 318 o No parent/child interaction is required when ZSKs are updated. 319 320 o The KSK can be made stronger (i.e., using more bits in the key 321 material). This has little operational impact since it is only 322 used to sign a small fraction of the zone data. Also, the KSK is 323 only used to verify the zone's key set, not for other RRSets in 324 the zone. 325 326 o As the KSK is only used to sign a key set, which is most probably 327 updated less frequently than other data in the zone, it can be 328 stored separately from and in a safer location than the ZSK. 329 330 o A KSK can have a longer key effectivity period. 331 332 For almost any method of key management and zone signing, the KSK is 333 used less frequently than the ZSK. Once a key set is signed with the 334 KSK, all the keys in the key set can be used as ZSKs. If a ZSK is 335 336 337 338Kolkman & Gieben Informational [Page 6] 339 340RFC 4641 DNSSEC Operational Practices September 2006 341 342 343 compromised, it can be simply dropped from the key set. The new key 344 set is then re-signed with the KSK. 345 346 Given the assumption that for KSKs the SEP flag is set, the KSK can 347 be distinguished from a ZSK by examining the flag field in the DNSKEY 348 RR. If the flag field is an odd number it is a KSK. If it is an 349 even number it is a ZSK. 350 351 The Zone Signing Key can be used to sign all the data in a zone on a 352 regular basis. When a Zone Signing Key is to be rolled, no 353 interaction with the parent is needed. This allows for signature 354 validity periods on the order of days. 355 356 The Key Signing Key is only to be used to sign the DNSKEY RRs in a 357 zone. If a Key Signing Key is to be rolled over, there will be 358 interactions with parties other than the zone administrator. These 359 can include the registry of the parent zone or administrators of 360 verifying resolvers that have the particular key configured as secure 361 entry points. Hence, the key effectivity period of these keys can 362 and should be made much longer. Although, given a long enough key, 363 the key effectivity period can be on the order of years, we suggest 364 planning for a key effectivity on the order of a few months so that a 365 key rollover remains an operational routine. 366 3673.1.2. KSKs for High-Level Zones 368 369 Higher-level zones are generally more sensitive than lower-level 370 zones. Anyone controlling or breaking the security of a zone thereby 371 obtains authority over all of its subdomains (except in the case of 372 resolvers that have locally configured the public key of a subdomain, 373 in which case this, and only this, subdomain wouldn't be affected by 374 the compromise of the parent zone). Therefore, extra care should be 375 taken with high-level zones, and strong keys should be used. 376 377 The root zone is the most critical of all zones. Someone controlling 378 or compromising the security of the root zone would control the 379 entire DNS namespace of all resolvers using that root zone (except in 380 the case of resolvers that have locally configured the public key of 381 a subdomain). Therefore, the utmost care must be taken in the 382 securing of the root zone. The strongest and most carefully handled 383 keys should be used. The root zone private key should always be kept 384 off-line. 385 386 Many resolvers will start at a root server for their access to and 387 authentication of DNS data. Securely updating the trust anchors in 388 an enormous population of resolvers around the world will be 389 extremely difficult. 390 391 392 393 394Kolkman & Gieben Informational [Page 7] 395 396RFC 4641 DNSSEC Operational Practices September 2006 397 398 3993.2. Key Generation 400 401 Careful generation of all keys is a sometimes overlooked but 402 absolutely essential element in any cryptographically secure system. 403 The strongest algorithms used with the longest keys are still of no 404 use if an adversary can guess enough to lower the size of the likely 405 key space so that it can be exhaustively searched. Technical 406 suggestions for the generation of random keys will be found in RFC 407 4086 [14]. One should carefully assess if the random number 408 generator used during key generation adheres to these suggestions. 409 410 Keys with a long effectivity period are particularly sensitive as 411 they will represent a more valuable target and be subject to attack 412 for a longer time than short-period keys. It is strongly recommended 413 that long-term key generation occur off-line in a manner isolated 414 from the network via an air gap or, at a minimum, high-level secure 415 hardware. 416 4173.3. Key Effectivity Period 418 419 For various reasons, keys in DNSSEC need to be changed once in a 420 while. The longer a key is in use, the greater the probability that 421 it will have been compromised through carelessness, accident, 422 espionage, or cryptanalysis. Furthermore, when key rollovers are too 423 rare an event, they will not become part of the operational habit and 424 there is risk that nobody on-site will remember the procedure for 425 rollover when the need is there. 426 427 From a purely operational perspective, a reasonable key effectivity 428 period for Key Signing Keys is 13 months, with the intent to replace 429 them after 12 months. An intended key effectivity period of a month 430 is reasonable for Zone Signing Keys. 431 432 For key sizes that match these effectivity periods, see Section 3.5. 433 434 As argued in Section 3.1.2, securely updating trust anchors will be 435 extremely difficult. On the other hand, the "operational habit" 436 argument does also apply to trust anchor reconfiguration. If a short 437 key effectivity period is used and the trust anchor configuration has 438 to be revisited on a regular basis, the odds that the configuration 439 tends to be forgotten is smaller. The trade-off is against a system 440 that is so dynamic that administrators of the validating clients will 441 not be able to follow the modifications. 442 443 Key effectivity periods can be made very short, as in a few minutes. 444 But when replacing keys one has to take the considerations from 445 Section 4.1 and Section 4.2 into account. 446 447 448 449 450Kolkman & Gieben Informational [Page 8] 451 452RFC 4641 DNSSEC Operational Practices September 2006 453 454 4553.4. Key Algorithm 456 457 There are currently three different types of algorithms that can be 458 used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The 459 latter is fairly new and has yet to be standardized for usage in 460 DNSSEC. 461 462 RSA has been developed in an open and transparent manner. As the 463 patent on RSA expired in 2000, its use is now also free. 464 465 DSA has been developed by the National Institute of Standards and 466 Technology (NIST). The creation of signatures takes roughly the same 467 time as with RSA, but is 10 to 40 times as slow for verification 468 [17]. 469 470 We suggest the use of RSA/SHA-1 as the preferred algorithm for the 471 key. The current known attacks on RSA can be defeated by making your 472 key longer. As the MD5 hashing algorithm is showing cracks, we 473 recommend the usage of SHA-1. 474 475 At the time of publication, it is known that the SHA-1 hash has 476 cryptanalysis issues. There is work in progress on addressing these 477 issues. We recommend the use of public key algorithms based on 478 hashes stronger than SHA-1 (e.g., SHA-256), as soon as these 479 algorithms are available in protocol specifications (see [19] and 480 [20]) and implementations. 481 4823.5. Key Sizes 483 484 When choosing key sizes, zone administrators will need to take into 485 account how long a key will be used, how much data will be signed 486 during the key publication period (see Section 8.10 of [17]), and, 487 optionally, how large the key size of the parent is. As the chain of 488 trust really is "a chain", there is not much sense in making one of 489 the keys in the chain several times larger then the others. As 490 always, it's the weakest link that defines the strength of the entire 491 chain. Also see Section 3.1.1 for a discussion of how keys serving 492 different roles (ZSK vs. KSK) may need different key sizes. 493 494 Generating a key of the correct size is a difficult problem; RFC 3766 495 [13] tries to deal with that problem. The first part of the 496 selection procedure in Section 1 of the RFC states: 497 498 1. Determine the attack resistance necessary to satisfy the 499 security requirements of the application. Do this by 500 estimating the minimum number of computer operations that the 501 attacker will be forced to do in order to compromise the 502 503 504 505 506Kolkman & Gieben Informational [Page 9] 507 508RFC 4641 DNSSEC Operational Practices September 2006 509 510 511 security of the system and then take the logarithm base two of 512 that number. Call that logarithm value "n". 513 514 A 1996 report recommended 90 bits as a good all-around choice 515 for system security. The 90 bit number should be increased by 516 about 2/3 bit/year, or about 96 bits in 2005. 517 518 [13] goes on to explain how this number "n" can be used to calculate 519 the key sizes in public key cryptography. This culminated in the 520 table given below (slightly modified for our purpose): 521 522 +-------------+-----------+--------------+ 523 | System | | | 524 | requirement | Symmetric | RSA or DSA | 525 | for attack | key size | modulus size | 526 | resistance | (bits) | (bits) | 527 | (bits) | | | 528 +-------------+-----------+--------------+ 529 | 70 | 70 | 947 | 530 | 80 | 80 | 1228 | 531 | 90 | 90 | 1553 | 532 | 100 | 100 | 1926 | 533 | 150 | 150 | 4575 | 534 | 200 | 200 | 8719 | 535 | 250 | 250 | 14596 | 536 +-------------+-----------+--------------+ 537 538 The key sizes given are rather large. This is because these keys are 539 resilient against a trillionaire attacker. Assuming this rich 540 attacker will not attack your key and that the key is rolled over 541 once a year, we come to the following recommendations about KSK 542 sizes: 1024 bits for low-value domains, 1300 bits for medium-value 543 domains, and 2048 bits for high-value domains. 544 545 Whether a domain is of low, medium, or high value depends solely on 546 the views of the zone owner. One could, for instance, view leaf 547 nodes in the DNS as of low value, and top-level domains (TLDs) or the 548 root zone of high value. The suggested key sizes should be safe for 549 the next 5 years. 550 551 As ZSKs can be rolled over more easily (and thus more often), the key 552 sizes can be made smaller. But as said in the introduction of this 553 paragraph, making the ZSKs' key sizes too small (in relation to the 554 KSKs' sizes) doesn't make much sense. Try to limit the difference in 555 size to about 100 bits. 556 557 558 559 560 561 562Kolkman & Gieben Informational [Page 10] 563 564RFC 4641 DNSSEC Operational Practices September 2006 565 566 567 Note that nobody can see into the future and that these key sizes are 568 only provided here as a guide. Further information can be found in 569 [16] and Section 7.5 of [17]. It should be noted though that [16] is 570 already considered overly optimistic about what key sizes are 571 considered safe. 572 573 One final note concerning key sizes. Larger keys will increase the 574 sizes of the RRSIG and DNSKEY records and will therefore increase the 575 chance of DNS UDP packet overflow. Also, the time it takes to 576 validate and create RRSIGs increases with larger keys, so don't 577 needlessly double your key sizes. 578 5793.6. Private Key Storage 580 581 It is recommended that, where possible, zone private keys and the 582 zone file master copy that is to be signed be kept and used in off- 583 line, non-network-connected, physically secure machines only. 584 Periodically, an application can be run to add authentication to a 585 zone by adding RRSIG and NSEC RRs. Then the augmented file can be 586 transferred. 587 588 When relying on dynamic update to manage a signed zone [10], be aware 589 that at least one private key of the zone will have to reside on the 590 master server. This key is only as secure as the amount of exposure 591 the server receives to unknown clients and the security of the host. 592 Although not mandatory, one could administer the DNS in the following 593 way. The master that processes the dynamic updates is unavailable 594 from generic hosts on the Internet, it is not listed in the NS RR 595 set, although its name appears in the SOA RRs MNAME field. The 596 nameservers in the NS RRSet are able to receive zone updates through 597 NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This 598 approach is known as the "hidden master" setup. 599 600 The ideal situation is to have a one-way information flow to the 601 network to avoid the possibility of tampering from the network. 602 Keeping the zone master file on-line on the network and simply 603 cycling it through an off-line signer does not do this. The on-line 604 version could still be tampered with if the host it resides on is 605 compromised. For maximum security, the master copy of the zone file 606 should be off-net and should not be updated based on an unsecured 607 network mediated communication. 608 609 In general, keeping a zone file off-line will not be practical and 610 the machines on which zone files are maintained will be connected to 611 a network. Operators are advised to take security measures to shield 612 unauthorized access to the master copy. 613 614 615 616 617 618Kolkman & Gieben Informational [Page 11] 619 620RFC 4641 DNSSEC Operational Practices September 2006 621 622 623 For dynamically updated secured zones [10], both the master copy and 624 the private key that is used to update signatures on updated RRs will 625 need to be on-line. 626 6274. Signature Generation, Key Rollover, and Related Policies 628 6294.1. Time in DNSSEC 630 631 Without DNSSEC, all times in the DNS are relative. The SOA fields 632 REFRESH, RETRY, and EXPIRATION are timers used to determine the time 633 elapsed after a slave server synchronized with a master server. The 634 Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] 635 are used to determine how long a forwarder should cache data after it 636 has been fetched from an authoritative server. By using a signature 637 validity period, DNSSEC introduces the notion of an absolute time in 638 the DNS. Signatures in DNSSEC have an expiration date after which 639 the signature is marked as invalid and the signed data is to be 640 considered Bogus. 641 6424.1.1. Time Considerations 643 644 Because of the expiration of signatures, one should consider the 645 following: 646 647 o We suggest the Maximum Zone TTL of your zone data to be a fraction 648 of your signature validity period. 649 650 If the TTL would be of similar order as the signature validity 651 period, then all RRSets fetched during the validity period 652 would be cached until the signature expiration time. Section 653 7.1 of [4] suggests that "the resolver may use the time 654 remaining before expiration of the signature validity period of 655 a signed RRSet as an upper bound for the TTL". As a result, 656 query load on authoritative servers would peak at signature 657 expiration time, as this is also the time at which records 658 simultaneously expire from caches. 659 660 To avoid query load peaks, we suggest the TTL on all the RRs in 661 your zone to be at least a few times smaller than your 662 signature validity period. 663 664 o We suggest the signature publication period to end at least one 665 Maximum Zone TTL duration before the end of the signature validity 666 period. 667 668 669 670 671 672 673 674Kolkman & Gieben Informational [Page 12] 675 676RFC 4641 DNSSEC Operational Practices September 2006 677 678 679 Re-signing a zone shortly before the end of the signature 680 validity period may cause simultaneous expiration of data from 681 caches. This in turn may lead to peaks in the load on 682 authoritative servers. 683 684 o We suggest the Minimum Zone TTL to be long enough to both fetch 685 and verify all the RRs in the trust chain. In workshop 686 environments, it has been demonstrated [18] that a low TTL (under 687 5 to 10 minutes) caused disruptions because of the following two 688 problems: 689 690 1. During validation, some data may expire before the 691 validation is complete. The validator should be able to 692 keep all data until it is completed. This applies to all 693 RRs needed to complete the chain of trust: DSes, DNSKEYs, 694 RRSIGs, and the final answers, i.e., the RRSet that is 695 returned for the initial query. 696 697 2. Frequent verification causes load on recursive nameservers. 698 Data at delegation points, DSes, DNSKEYs, and RRSIGs 699 benefit from caching. The TTL on those should be 700 relatively long. 701 702 o Slave servers will need to be able to fetch newly signed zones 703 well before the RRSIGs in the zone served by the slave server pass 704 their signature expiration time. 705 706 When a slave server is out of sync with its master and data in 707 a zone is signed by expired signatures, it may be better for 708 the slave server not to give out any answer. 709 710 Normally, a slave server that is not able to contact a master 711 server for an extended period will expire a zone. When that 712 happens, the server will respond differently to queries for 713 that zone. Some servers issue SERVFAIL, whereas others turn 714 off the 'AA' bit in the answers. The time of expiration is set 715 in the SOA record and is relative to the last successful 716 refresh between the master and the slave servers. There exists 717 no coupling between the signature expiration of RRSIGs in the 718 zone and the expire parameter in the SOA. 719 720 If the server serves a DNSSEC zone, then it may well happen 721 that the signatures expire well before the SOA expiration timer 722 counts down to zero. It is not possible to completely prevent 723 this from happening by tweaking the SOA parameters. However, 724 the effects can be minimized where the SOA expiration time is 725 equal to or shorter than the signature validity period. The 726 consequence of an authoritative server not being able to update 727 728 729 730Kolkman & Gieben Informational [Page 13] 731 732RFC 4641 DNSSEC Operational Practices September 2006 733 734 735 a zone, whilst that zone includes expired signatures, is that 736 non-secure resolvers will continue to be able to resolve data 737 served by the particular slave servers while security-aware 738 resolvers will experience problems because of answers being 739 marked as Bogus. 740 741 We suggest the SOA expiration timer being approximately one 742 third or one fourth of the signature validity period. It will 743 allow problems with transfers from the master server to be 744 noticed before the actual signature times out. We also suggest 745 that operators of nameservers that supply secondary services 746 develop 'watch dogs' to spot upcoming signature expirations in 747 zones they slave, and take appropriate action. 748 749 When determining the value for the expiration parameter one has 750 to take the following into account: What are the chances that 751 all my secondaries expire the zone? How quickly can I reach an 752 administrator of secondary servers to load a valid zone? These 753 questions are not DNSSEC specific but may influence the choice 754 of your signature validity intervals. 755 7564.2. Key Rollovers 757 758 A DNSSEC key cannot be used forever (see Section 3.3). So key 759 rollovers -- or supercessions, as they are sometimes called -- are a 760 fact of life when using DNSSEC. Zone administrators who are in the 761 process of rolling their keys have to take into account that data 762 published in previous versions of their zone still lives in caches. 763 When deploying DNSSEC, this becomes an important consideration; 764 ignoring data that may be in caches may lead to loss of service for 765 clients. 766 767 The most pressing example of this occurs when zone material signed 768 with an old key is being validated by a resolver that does not have 769 the old zone key cached. If the old key is no longer present in the 770 current zone, this validation fails, marking the data "Bogus". 771 Alternatively, an attempt could be made to validate data that is 772 signed with a new key against an old key that lives in a local cache, 773 also resulting in data being marked "Bogus". 774 7754.2.1. Zone Signing Key Rollovers 776 777 For "Zone Signing Key rollovers", there are two ways to make sure 778 that during the rollover data still cached can be verified with the 779 new key sets or newly generated signatures can be verified with the 780 keys still in caches. One schema, described in Section 4.2.1.2, uses 781 782 783 784 785 786Kolkman & Gieben Informational [Page 14] 787 788RFC 4641 DNSSEC Operational Practices September 2006 789 790 791 double signatures; the other uses key pre-publication (Section 792 4.2.1.1). The pros, cons, and recommendations are described in 793 Section 4.2.1.3. 794 7954.2.1.1. Pre-Publish Key Rollover 796 797 This section shows how to perform a ZSK rollover without the need to 798 sign all the data in a zone twice -- the "pre-publish key rollover". 799 This method has advantages in the case of a key compromise. If the 800 old key is compromised, the new key has already been distributed in 801 the DNS. The zone administrator is then able to quickly switch to 802 the new key and remove the compromised key from the zone. Another 803 major advantage is that the zone size does not double, as is the case 804 with the double signature ZSK rollover. A small "how-to" for this 805 kind of rollover can be found in Appendix B. 806 807 Pre-publish key rollover involves four stages as follows: 808 809 ---------------------------------------------------------------- 810 initial new DNSKEY new RRSIGs DNSKEY removal 811 ---------------------------------------------------------------- 812 SOA0 SOA1 SOA2 SOA3 813 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 814 815 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 816 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 817 DNSKEY11 DNSKEY11 818 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 819 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 820 ---------------------------------------------------------------- 821 822 Pre-Publish Key Rollover 823 824 initial: Initial version of the zone: DNSKEY 1 is the Key Signing 825 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 826 Signing Key. 827 828 new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no 829 signatures are generated with this key yet, but this does not 830 secure against brute force attacks on the public key. The minimum 831 duration of this pre-roll phase is the time it takes for the data 832 to propagate to the authoritative servers plus TTL value of the 833 key set. 834 835 new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is 836 used to sign the data in the zone exclusively (i.e., all the 837 signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 838 remains published in the key set. This way data that was loaded 839 840 841 842Kolkman & Gieben Informational [Page 15] 843 844RFC 4641 DNSSEC Operational Practices September 2006 845 846 847 into caches from version 1 of the zone can still be verified with 848 key sets fetched from version 2 of the zone. The minimum time 849 that the key set including DNSKEY 10 is to be published is the 850 time that it takes for zone data from the previous version of the 851 zone to expire from old caches, i.e., the time it takes for this 852 zone to propagate to all authoritative servers plus the Maximum 853 Zone TTL value of any of the data in the previous version of the 854 zone. 855 856 DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now 857 only containing DNSKEY 1 and DNSKEY 11, is re-signed with the 858 DNSKEY 1. 859 860 The above scheme can be simplified by always publishing the "future" 861 key immediately after the rollover. The scheme would look as follows 862 (we show two rollovers); the future key is introduced in "new DNSKEY" 863 as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY 864 (II)": 865 866 ---------------------------------------------------------------- 867 initial new RRSIGs new DNSKEY 868 ---------------------------------------------------------------- 869 SOA0 SOA1 SOA2 870 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) 871 872 DNSKEY1 DNSKEY1 DNSKEY1 873 DNSKEY10 DNSKEY10 DNSKEY11 874 DNSKEY11 DNSKEY11 DNSKEY12 875 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 876 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 877 ---------------------------------------------------------------- 878 879 ---------------------------------------------------------------- 880 new RRSIGs (II) new DNSKEY (II) 881 ---------------------------------------------------------------- 882 SOA3 SOA4 883 RRSIG12(SOA3) RRSIG12(SOA4) 884 885 DNSKEY1 DNSKEY1 886 DNSKEY11 DNSKEY12 887 DNSKEY12 DNSKEY13 888 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 889 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 890 ---------------------------------------------------------------- 891 892 Pre-Publish Key Rollover, Showing Two Rollovers 893 894 895 896 897 898Kolkman & Gieben Informational [Page 16] 899 900RFC 4641 DNSSEC Operational Practices September 2006 901 902 903 Note that the key introduced in the "new DNSKEY" phase is not used 904 for production yet; the private key can thus be stored in a 905 physically secure manner and does not need to be 'fetched' every time 906 a zone needs to be signed. 907 9084.2.1.2. Double Signature Zone Signing Key Rollover 909 910 This section shows how to perform a ZSK key rollover using the double 911 zone data signature scheme, aptly named "double signature rollover". 912 913 During the "new DNSKEY" stage the new version of the zone file will 914 need to propagate to all authoritative servers and the data that 915 exists in (distant) caches will need to expire, requiring at least 916 the Maximum Zone TTL. 917 918 Double signature ZSK rollover involves three stages as follows: 919 920 ---------------------------------------------------------------- 921 initial new DNSKEY DNSKEY removal 922 ---------------------------------------------------------------- 923 SOA0 SOA1 SOA2 924 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 925 RRSIG11(SOA1) 926 927 DNSKEY1 DNSKEY1 DNSKEY1 928 DNSKEY10 DNSKEY10 DNSKEY11 929 DNSKEY11 930 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 931 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 932 RRSIG11(DNSKEY) 933 ---------------------------------------------------------------- 934 935 Double Signature Zone Signing Key Rollover 936 937 initial: Initial Version of the zone: DNSKEY 1 is the Key Signing 938 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 939 Signing Key. 940 941 new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is 942 introduced into the key set and all the data in the zone is signed 943 with DNSKEY 10 and DNSKEY 11. The rollover period will need to 944 continue until all data from version 0 of the zone has expired 945 from remote caches. This will take at least the Maximum Zone TTL 946 of version 0 of the zone. 947 948 DNSKEY removal: DNSKEY 10 is removed from the zone. All the 949 signatures from DNSKEY 10 are removed from the zone. The key set, 950 now only containing DNSKEY 11, is re-signed with DNSKEY 1. 951 952 953 954Kolkman & Gieben Informational [Page 17] 955 956RFC 4641 DNSSEC Operational Practices September 2006 957 958 959 At every instance, RRSIGs from the previous version of the zone can 960 be verified with the DNSKEY RRSet from the current version and the 961 other way around. The data from the current version can be verified 962 with the data from the previous version of the zone. The duration of 963 the "new DNSKEY" phase and the period between rollovers should be at 964 least the Maximum Zone TTL. 965 966 Making sure that the "new DNSKEY" phase lasts until the signature 967 expiration time of the data in initial version of the zone is 968 recommended. This way all caches are cleared of the old signatures. 969 However, this duration could be considerably longer than the Maximum 970 Zone TTL, making the rollover a lengthy procedure. 971 972 Note that in this example we assumed that the zone was not modified 973 during the rollover. New data can be introduced in the zone as long 974 as it is signed with both keys. 975 9764.2.1.3. Pros and Cons of the Schemes 977 978 Pre-publish key rollover: This rollover does not involve signing the 979 zone data twice. Instead, before the actual rollover, the new key 980 is published in the key set and thus is available for 981 cryptanalysis attacks. A small disadvantage is that this process 982 requires four steps. Also the pre-publish scheme involves more 983 parental work when used for KSK rollovers as explained in Section 984 4.2.3. 985 986 Double signature ZSK rollover: The drawback of this signing scheme is 987 that during the rollover the number of signatures in your zone 988 doubles; this may be prohibitive if you have very big zones. An 989 advantage is that it only requires three steps. 990 9914.2.2. Key Signing Key Rollovers 992 993 For the rollover of a Key Signing Key, the same considerations as for 994 the rollover of a Zone Signing Key apply. However, we can use a 995 double signature scheme to guarantee that old data (only the apex key 996 set) in caches can be verified with a new key set and vice versa. 997 Since only the key set is signed with a KSK, zone size considerations 998 do not apply. 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010Kolkman & Gieben Informational [Page 18] 1011 1012RFC 4641 DNSSEC Operational Practices September 2006 1013 1014 1015 -------------------------------------------------------------------- 1016 initial new DNSKEY DS change DNSKEY removal 1017 -------------------------------------------------------------------- 1018 Parent: 1019 SOA0 --------> SOA1 --------> 1020 RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> 1021 DS1 --------> DS2 --------> 1022 RRSIGpar(DS) --------> RRSIGpar(DS) --------> 1023 1024 1025 Child: 1026 SOA0 SOA1 --------> SOA2 1027 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) 1028 --------> 1029 DNSKEY1 DNSKEY1 --------> DNSKEY2 1030 DNSKEY2 --------> 1031 DNSKEY10 DNSKEY10 --------> DNSKEY10 1032 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) 1033 RRSIG2 (DNSKEY) --------> 1034 RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) 1035 -------------------------------------------------------------------- 1036 1037 Stages of Deployment for a Double Signature Key Signing Key Rollover 1038 1039 initial: Initial version of the zone. The parental DS points to 1040 DNSKEY1. Before the rollover starts, the child will have to 1041 verify what the TTL is of the DS RR that points to DNSKEY1 -- it 1042 is needed during the rollover and we refer to the value as TTL_DS. 1043 1044 new DNSKEY: During the "new DNSKEY" phase, the zone administrator 1045 generates a second KSK, DNSKEY2. The key is provided to the 1046 parent, and the child will have to wait until a new DS RR has been 1047 generated that points to DNSKEY2. After that DS RR has been 1048 published on all servers authoritative for the parent's zone, the 1049 zone administrator has to wait at least TTL_DS to make sure that 1050 the old DS RR has expired from caches. 1051 1052 DS change: The parent replaces DS1 with DS2. 1053 1054 DNSKEY removal: DNSKEY1 has been removed. 1055 1056 The scenario above puts the responsibility for maintaining a valid 1057 chain of trust with the child. It also is based on the premise that 1058 the parent only has one DS RR (per algorithm) per zone. An 1059 alternative mechanism has been considered. Using an established 1060 trust relation, the interaction can be performed in-band, and the 1061 removal of the keys by the child can possibly be signaled by the 1062 parent. In this mechanism, there are periods where there are two DS 1063 1064 1065 1066Kolkman & Gieben Informational [Page 19] 1067 1068RFC 4641 DNSSEC Operational Practices September 2006 1069 1070 1071 RRs at the parent. Since at the moment of writing the protocol for 1072 this interaction has not been developed, further discussion is out of 1073 scope for this document. 1074 10754.2.3. Difference Between ZSK and KSK Rollovers 1076 1077 Note that KSK rollovers and ZSK rollovers are different in the sense 1078 that a KSK rollover requires interaction with the parent (and 1079 possibly replacing of trust anchors) and the ensuing delay while 1080 waiting for it. 1081 1082 A zone key rollover can be handled in two different ways: pre-publish 1083 (Section 4.2.1.1) and double signature (Section 4.2.1.2). 1084 1085 As the KSK is used to validate the key set and because the KSK is not 1086 changed during a ZSK rollover, a cache is able to validate the new 1087 key set of the zone. The pre-publish method would also work for a 1088 KSK rollover. The records that are to be pre-published are the 1089 parental DS RRs. The pre-publish method has some drawbacks for KSKs. 1090 We first describe the rollover scheme and then indicate these 1091 drawbacks. 1092 1093 -------------------------------------------------------------------- 1094 initial new DS new DNSKEY DS/DNSKEY removal 1095 -------------------------------------------------------------------- 1096 Parent: 1097 SOA0 SOA1 --------> SOA2 1098 RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) 1099 DS1 DS1 --------> DS2 1100 DS2 --------> 1101 RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) 1102 1103 1104 Child: 1105 SOA0 --------> SOA1 SOA1 1106 RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) 1107 --------> 1108 DNSKEY1 --------> DNSKEY2 DNSKEY2 1109 --------> 1110 DNSKEY10 --------> DNSKEY10 DNSKEY10 1111 RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 1112 RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) 1113 -------------------------------------------------------------------- 1114 1115 Stages of Deployment for a Pre-Publish Key Signing Key Rollover 1116 1117 1118 1119 1120 1121 1122Kolkman & Gieben Informational [Page 20] 1123 1124RFC 4641 DNSSEC Operational Practices September 2006 1125 1126 1127 When the child zone wants to roll, it notifies the parent during the 1128 "new DS" phase and submits the new key (or the corresponding DS) to 1129 the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 1130 and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), 1131 which can take place as soon as the new DS set propagated through the 1132 DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that 1133 ("DS/DNSKEY removal" phase), it can notify the parent that the old DS 1134 record can be deleted. 1135 1136 The drawbacks of this scheme are that during the "new DS" phase the 1137 parent cannot verify the match between the DS2 RR and DNSKEY2 using 1138 the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a 1139 "security lame" key (see Section 4.4.3). Finally, the child-parent 1140 interaction consists of two steps. The "double signature" method 1141 only needs one interaction. 1142 11434.2.4. Automated Key Rollovers 1144 1145 As keys must be renewed periodically, there is some motivation to 1146 automate the rollover process. Consider the following: 1147 1148 o ZSK rollovers are easy to automate as only the child zone is 1149 involved. 1150 1151 o A KSK rollover needs interaction between parent and child. Data 1152 exchange is needed to provide the new keys to the parent; 1153 consequently, this data must be authenticated and integrity must 1154 be guaranteed in order to avoid attacks on the rollover. 1155 11564.3. Planning for Emergency Key Rollover 1157 1158 This section deals with preparation for a possible key compromise. 1159 Our advice is to have a documented procedure ready for when a key 1160 compromise is suspected or confirmed. 1161 1162 When the private material of one of your keys is compromised it can 1163 be used for as long as a valid trust chain exists. A trust chain 1164 remains intact for 1165 1166 o as long as a signature over the compromised key in the trust chain 1167 is valid, 1168 1169 o as long as a parental DS RR (and signature) points to the 1170 compromised key, 1171 1172 o as long as the key is anchored in a resolver and is used as a 1173 starting point for validation (this is generally the hardest to 1174 update). 1175 1176 1177 1178Kolkman & Gieben Informational [Page 21] 1179 1180RFC 4641 DNSSEC Operational Practices September 2006 1181 1182 1183 While a trust chain to your compromised key exists, your namespace is 1184 vulnerable to abuse by anyone who has obtained illegitimate 1185 possession of the key. Zone operators have to make a trade-off if 1186 the abuse of the compromised key is worse than having data in caches 1187 that cannot be validated. If the zone operator chooses to break the 1188 trust chain to the compromised key, data in caches signed with this 1189 key cannot be validated. However, if the zone administrator chooses 1190 to take the path of a regular rollover, the malicious key holder can 1191 spoof data so that it appears to be valid. 1192 11934.3.1. KSK Compromise 1194 1195 A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable 1196 as long as the compromised KSK is configured as trust anchor or a 1197 parental DS points to it. 1198 1199 A compromised KSK can be used to sign the key set of an attacker's 1200 zone. That zone could be used to poison the DNS. 1201 1202 Therefore, when the KSK has been compromised, the trust anchor or the 1203 parental DS should be replaced as soon as possible. It is local 1204 policy whether to break the trust chain during the emergency 1205 rollover. The trust chain would be broken when the compromised KSK 1206 is removed from the child's zone while the parent still has a DS 1207 pointing to the compromised KSK (the assumption is that there is only 1208 one DS at the parent. If there are multiple DSes this does not apply 1209 -- however the chain of trust of this particular key is broken). 1210 1211 Note that an attacker's zone still uses the compromised KSK and the 1212 presence of a parental DS would cause the data in this zone to appear 1213 as valid. Removing the compromised key would cause the attacker's 1214 zone to appear as valid and the child's zone as Bogus. Therefore, we 1215 advise not to remove the KSK before the parent has a DS to a new KSK 1216 in place. 1217 12184.3.1.1. Keeping the Chain of Trust Intact 1219 1220 If we follow this advice, the timing of the replacement of the KSK is 1221 somewhat critical. The goal is to remove the compromised KSK as soon 1222 as the new DS RR is available at the parent. And also make sure that 1223 the signature made with a new KSK over the key set with the 1224 compromised KSK in it expires just after the new DS appears at the 1225 parent, thus removing the old cruft in one swoop. 1226 1227 The procedure is as follows: 1228 1229 1. Introduce a new KSK into the key set, keep the compromised KSK in 1230 the key set. 1231 1232 1233 1234Kolkman & Gieben Informational [Page 22] 1235 1236RFC 4641 DNSSEC Operational Practices September 2006 1237 1238 1239 2. Sign the key set, with a short validity period. The validity 1240 period should expire shortly after the DS is expected to appear 1241 in the parent and the old DSes have expired from caches. 1242 1243 3. Upload the DS for this new key to the parent. 1244 1245 4. Follow the procedure of the regular KSK rollover: Wait for the DS 1246 to appear in the authoritative servers and then wait as long as 1247 the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet 1248 and modify/extend the expiration time. 1249 1250 5. Remove the compromised DNSKEY RR from the zone and re-sign the 1251 key set using your "normal" validity interval. 1252 1253 An additional danger of a key compromise is that the compromised key 1254 could be used to facilitate a legitimate DNSKEY/DS rollover and/or 1255 nameserver changes at the parent. When that happens, the domain may 1256 be in dispute. An authenticated out-of-band and secure notify 1257 mechanism to contact a parent is needed in this case. 1258 1259 Note that this is only a problem when the DNSKEY and or DS records 1260 are used for authentication at the parent. 1261 12624.3.1.2. Breaking the Chain of Trust 1263 1264 There are two methods to break the chain of trust. The first method 1265 causes the child zone to appear 'Bogus' to validating resolvers. The 1266 other causes the child zone to appear 'insecure'. These are 1267 described below. 1268 1269 In the method that causes the child zone to appear 'Bogus' to 1270 validating resolvers, the child zone replaces the current KSK with a 1271 new one and re-signs the key set. Next it sends the DS of the new 1272 key to the parent. Only after the parent has placed the new DS in 1273 the zone is the child's chain of trust repaired. 1274 1275 An alternative method of breaking the chain of trust is by removing 1276 the DS RRs from the parent zone altogether. As a result, the child 1277 zone would become insecure. 1278 12794.3.2. ZSK Compromise 1280 1281 Primarily because there is no parental interaction required when a 1282 ZSK is compromised, the situation is less severe than with a KSK 1283 compromise. The zone must still be re-signed with a new ZSK as soon 1284 as possible. As this is a local operation and requires no 1285 communication between the parent and child, this can be achieved 1286 fairly quickly. However, one has to take into account that just as 1287 1288 1289 1290Kolkman & Gieben Informational [Page 23] 1291 1292RFC 4641 DNSSEC Operational Practices September 2006 1293 1294 1295 with a normal rollover the immediate disappearance of the old 1296 compromised key may lead to verification problems. Also note that as 1297 long as the RRSIG over the compromised ZSK is not expired the zone 1298 may be still at risk. 1299 13004.3.3. Compromises of Keys Anchored in Resolvers 1301 1302 A key can also be pre-configured in resolvers. For instance, if 1303 DNSSEC is successfully deployed the root key may be pre-configured in 1304 most security aware resolvers. 1305 1306 If trust-anchor keys are compromised, the resolvers using these keys 1307 should be notified of this fact. Zone administrators may consider 1308 setting up a mailing list to communicate the fact that a SEP key is 1309 about to be rolled over. This communication will of course need to 1310 be authenticated, e.g., by using digital signatures. 1311 1312 End-users faced with the task of updating an anchored key should 1313 always validate the new key. New keys should be authenticated out- 1314 of-band, for example, through the use of an announcement website that 1315 is secured using secure sockets (TLS) [21]. 1316 13174.4. Parental Policies 1318 13194.4.1. Initial Key Exchanges and Parental Policies Considerations 1320 1321 The initial key exchange is always subject to the policies set by the 1322 parent. When designing a key exchange policy one should take into 1323 account that the authentication and authorization mechanisms used 1324 during a key exchange should be as strong as the authentication and 1325 authorization mechanisms used for the exchange of delegation 1326 information between parent and child. That is, there is no implicit 1327 need in DNSSEC to make the authentication process stronger than it 1328 was in DNS. 1329 1330 Using the DNS itself as the source for the actual DNSKEY material, 1331 with an out-of-band check on the validity of the DNSKEY, has the 1332 benefit that it reduces the chances of user error. A DNSKEY query 1333 tool can make use of the SEP bit [3] to select the proper key from a 1334 DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is 1335 sent. It can validate the self-signature over a key; thereby 1336 verifying the ownership of the private key material. Fetching the 1337 DNSKEY from the DNS ensures that the chain of trust remains intact 1338 once the parent publishes the DS RR indicating the child is secure. 1339 1340 Note: the out-of-band verification is still needed when the key 1341 material is fetched via the DNS. The parent can never be sure 1342 whether or not the DNSKEY RRs have been spoofed. 1343 1344 1345 1346Kolkman & Gieben Informational [Page 24] 1347 1348RFC 4641 DNSSEC Operational Practices September 2006 1349 1350 13514.4.2. Storing Keys or Hashes? 1352 1353 When designing a registry system one should consider which of the 1354 DNSKEYs and/or the corresponding DSes to store. Since a child zone 1355 might wish to have a DS published using a message digest algorithm 1356 not yet understood by the registry, the registry can't count on being 1357 able to generate the DS record from a raw DNSKEY. Thus, we recommend 1358 that registry systems at least support storing DS records. 1359 1360 It may also be useful to store DNSKEYs, since having them may help 1361 during troubleshooting and, as long as the child's chosen message 1362 digest is supported, the overhead of generating DS records from them 1363 is minimal. Having an out-of-band mechanism, such as a registry 1364 directory (e.g., Whois), to find out which keys are used to generate 1365 DS Resource Records for specific owners and/or zones may also help 1366 with troubleshooting. 1367 1368 The storage considerations also relate to the design of the customer 1369 interface and the method by which data is transferred between 1370 registrant and registry; Will the child zone administrator be able to 1371 upload DS RRs with unknown hash algorithms or does the interface only 1372 allow DNSKEYs? In the registry-registrar model, one can use the 1373 DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], 1374 which allows transfer of DS RRs and optionally DNSKEY RRs. 1375 13764.4.3. Security Lameness 1377 1378 Security lameness is defined as what happens when a parent has a DS 1379 RR pointing to a non-existing DNSKEY RR. When this happens, the 1380 child's zone may be marked "Bogus" by verifying DNS clients. 1381 1382 As part of a comprehensive delegation check, the parent could, at key 1383 exchange time, verify that the child's key is actually configured in 1384 the DNS. However, if a parent does not understand the hashing 1385 algorithm used by child, the parental checks are limited to only 1386 comparing the key id. 1387 1388 Child zones should be very careful in removing DNSKEY material, 1389 specifically SEP keys, for which a DS RR exists. 1390 1391 Once a zone is "security lame", a fix (e.g., removing a DS RR) will 1392 take time to propagate through the DNS. 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402Kolkman & Gieben Informational [Page 25] 1403 1404RFC 4641 DNSSEC Operational Practices September 2006 1405 1406 14074.4.4. DS Signature Validity Period 1408 1409 Since the DS can be replayed as long as it has a valid signature, a 1410 short signature validity period over the DS minimizes the time a 1411 child is vulnerable in the case of a compromise of the child's 1412 KSK(s). A signature validity period that is too short introduces the 1413 possibility that a zone is marked "Bogus" in case of a configuration 1414 error in the signer. There may not be enough time to fix the 1415 problems before signatures expire. Something as mundane as operator 1416 unavailability during weekends shows the need for DS signature 1417 validity periods longer than 2 days. We recommend an absolute 1418 minimum for a DS signature validity period of a few days. 1419 1420 The maximum signature validity period of the DS record depends on how 1421 long child zones are willing to be vulnerable after a key compromise. 1422 On the other hand, shortening the DS signature validity interval 1423 increases the operational risk for the parent. Therefore, the parent 1424 may have policy to use a signature validity interval that is 1425 considerably longer than the child would hope for. 1426 1427 A compromise between the operational constraints of the parent and 1428 minimizing damage for the child may result in a DS signature validity 1429 period somewhere between a week and months. 1430 1431 In addition to the signature validity period, which sets a lower 1432 bound on the number of times the zone owner will need to sign the 1433 zone data and which sets an upper bound to the time a child is 1434 vulnerable after key compromise, there is the TTL value on the DS 1435 RRs. Shortening the TTL means that the authoritative servers will 1436 see more queries. But on the other hand, a short TTL lowers the 1437 persistence of DS RRSets in caches thereby increasing the speed with 1438 which updated DS RRSets propagate through the DNS. 1439 14405. Security Considerations 1441 1442 DNSSEC adds data integrity to the DNS. This document tries to assess 1443 the operational considerations to maintain a stable and secure DNSSEC 1444 service. Not taking into account the 'data propagation' properties 1445 in the DNS will cause validation failures and may make secured zones 1446 unavailable to security-aware resolvers. 1447 14486. Acknowledgments 1449 1450 Most of the ideas in this document were the result of collective 1451 efforts during workshops, discussions, and tryouts. 1452 1453 At the risk of forgetting individuals who were the original 1454 contributors of the ideas, we would like to acknowledge people who 1455 1456 1457 1458Kolkman & Gieben Informational [Page 26] 1459 1460RFC 4641 DNSSEC Operational Practices September 2006 1461 1462 1463 were actively involved in the compilation of this document. In 1464 random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael 1465 Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette 1466 Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger 1467 Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch. 1468 1469 Some material in this document has been copied from RFC 2541 [12]. 1470 1471 Mike StJohns designed the key exchange between parent and child 1472 mentioned in the last paragraph of Section 4.2.2 1473 1474 Section 4.2.4 was supplied by G. Guette and O. Courtay. 1475 1476 Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of 1477 the spelling and style issues. 1478 1479 Kolkman and Gieben take the blame for introducing all miscakes (sic). 1480 1481 While working on this document, Kolkman was employed by the RIPE NCC 1482 and Gieben was employed by NLnet Labs. 1483 14847. References 1485 14867.1. Normative References 1487 1488 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 1489 13, RFC 1034, November 1987. 1490 1491 [2] Mockapetris, P., "Domain names - implementation and 1492 specification", STD 13, RFC 1035, November 1987. 1493 1494 [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System 1495 KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) 1496 Flag", RFC 3757, May 2004. 1497 1498 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1499 "DNS Security Introduction and Requirements", RFC 4033, March 1500 2005. 1501 1502 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1503 "Resource Records for the DNS Security Extensions", RFC 4034, 1504 March 2005. 1505 1506 [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1507 "Protocol Modifications for the DNS Security Extensions", RFC 1508 4035, March 2005. 1509 1510 1511 1512 1513 1514Kolkman & Gieben Informational [Page 27] 1515 1516RFC 4641 DNSSEC Operational Practices September 2006 1517 1518 15197.2. Informative References 1520 1521 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1522 Levels", BCP 14, RFC 2119, March 1997. 1523 1524 [8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1525 1996. 1526 1527 [9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 1528 (DNS NOTIFY)", RFC 1996, August 1996. 1529 1530 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1531 Update", RFC 3007, November 2000. 1532 1533 [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1534 RFC 2308, March 1998. 1535 1536 [12] Eastlake, D., "DNS Security Operational Considerations", RFC 1537 2541, March 1999. 1538 1539 [13] Orman, H. and P. Hoffman, "Determining Strengths For Public 1540 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 1541 April 2004. 1542 1543 [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1544 Requirements for Security", BCP 106, RFC 4086, June 2005. 1545 1546 [15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 1547 Mapping for the Extensible Provisioning Protocol (EPP)", RFC 1548 4310, December 2005. 1549 1550 [16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1551 Sizes", The Journal of Cryptology 14 (255-293), 2001. 1552 1553 [17] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and 1554 Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN 1555 (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., 1556 1996. 1557 1558 [18] Rose, S., "NIST DNSSEC workshop notes", June 2001. 1559 1560 [19] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource 1561 Records in DNSSEC", Work in Progress, January 2006. 1562 1563 [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 1564 Resource Records (RRs)", RFC 4509, May 2006. 1565 1566 1567 1568 1569 1570Kolkman & Gieben Informational [Page 28] 1571 1572RFC 4641 DNSSEC Operational Practices September 2006 1573 1574 1575 [21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1576 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 1577 4366, April 2006. 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626Kolkman & Gieben Informational [Page 29] 1627 1628RFC 4641 DNSSEC Operational Practices September 2006 1629 1630 1631Appendix A. Terminology 1632 1633 In this document, there is some jargon used that is defined in other 1634 documents. In most cases, we have not copied the text from the 1635 documents defining the terms but have given a more elaborate 1636 explanation of the meaning. Note that these explanations should not 1637 be seen as authoritative. 1638 1639 Anchored key: A DNSKEY configured in resolvers around the globe. 1640 This key is hard to update, hence the term anchored. 1641 1642 Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked 1643 "Bogus" when a signature of an RRSet does not validate against a 1644 DNSKEY. 1645 1646 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used 1647 exclusively for signing the apex key set. The fact that a key is 1648 a KSK is only relevant to the signing tool. 1649 1650 Key size: The term 'key size' can be substituted by 'modulus size' 1651 throughout the document. It is mathematically more correct to use 1652 modulus size, but as this is a document directed at operators we 1653 feel more at ease with the term key size. 1654 1655 Private and public keys: DNSSEC secures the DNS through the use of 1656 public key cryptography. Public key cryptography is based on the 1657 existence of two (mathematically related) keys, a public key and a 1658 private key. The public keys are published in the DNS by use of 1659 the DNSKEY Resource Record (DNSKEY RR). Private keys should 1660 remain private. 1661 1662 Key rollover: A key rollover (also called key supercession in some 1663 environments) is the act of replacing one key pair with another at 1664 the end of a key effectivity period. 1665 1666 Secure Entry Point (SEP) key: A KSK that has a parental DS record 1667 pointing to it or is configured as a trust anchor. Although not 1668 required by the protocol, we recommend that the SEP flag [3] is 1669 set on these keys. 1670 1671 Self-signature: This only applies to signatures over DNSKEYs; a 1672 signature made with DNSKEY x, over DNSKEY x is called a self- 1673 signature. Note: without further information, self-signatures 1674 convey no trust. They are useful to check the authenticity of the 1675 DNSKEY, i.e., they can be used as a hash. 1676 1677 1678 1679 1680 1681 1682Kolkman & Gieben Informational [Page 30] 1683 1684RFC 4641 DNSSEC Operational Practices September 2006 1685 1686 1687 Singing the zone file: The term used for the event where an 1688 administrator joyfully signs its zone file while producing melodic 1689 sound patterns. 1690 1691 Signer: The system that has access to the private key material and 1692 signs the Resource Record sets in a zone. A signer may be 1693 configured to sign only parts of the zone, e.g., only those RRSets 1694 for which existing signatures are about to expire. 1695 1696 Zone Signing Key (ZSK): A key that is used for signing all data in a 1697 zone. The fact that a key is a ZSK is only relevant to the 1698 signing tool. 1699 1700 Zone administrator: The 'role' that is responsible for signing a zone 1701 and publishing it on the primary authoritative server. 1702 1703Appendix B. Zone Signing Key Rollover How-To 1704 1705 Using the pre-published signature scheme and the most conservative 1706 method to assure oneself that data does not live in caches, here 1707 follows the "how-to". 1708 1709 Step 0: The preparation: Create two keys and publish both in your key 1710 set. Mark one of the keys "active" and the other "published". 1711 Use the "active" key for signing your zone data. Store the 1712 private part of the "published" key, preferably off-line. The 1713 protocol does not provide for attributes to mark a key as active 1714 or published. This is something you have to do on your own, 1715 through the use of a notebook or key management tool. 1716 1717 Step 1: Determine expiration: At the beginning of the rollover make a 1718 note of the highest expiration time of signatures in your zone 1719 file created with the current key marked as active. Wait until 1720 the expiration time marked in Step 1 has passed. 1721 1722 Step 2: Then start using the key that was marked "published" to sign 1723 your data (i.e., mark it "active"). Stop using the key that was 1724 marked "active"; mark it "rolled". 1725 1726 Step 3: It is safe to engage in a new rollover (Step 1) after at 1727 least one signature validity period. 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738Kolkman & Gieben Informational [Page 31] 1739 1740RFC 4641 DNSSEC Operational Practices September 2006 1741 1742 1743Appendix C. Typographic Conventions 1744 1745 The following typographic conventions are used in this document: 1746 1747 Key notation: A key is denoted by DNSKEYx, where x is a number or an 1748 identifier, x could be thought of as the key id. 1749 1750 RRSet notations: RRs are only denoted by the type. All other 1751 information -- owner, class, rdata, and TTL--is left out. Thus: 1752 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a 1753 list of RRs. A example of this would be "A1, A2", specifying the 1754 RRSet containing two "A" records. This could again be abbreviated to 1755 just "A". 1756 1757 Signature notation: Signatures are denoted as RRSIGx(RRSet), which 1758 means that RRSet is signed with DNSKEYx. 1759 1760 Zone representation: Using the above notation we have simplified the 1761 representation of a signed zone by leaving out all unnecessary 1762 details such as the names and by representing all data by "SOAx" 1763 1764 SOA representation: SOAs are represented as SOAx, where x is the 1765 serial number. 1766 1767 Using this notation the following signed zone: 1768 1769 example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 1770 2006022100 ; serial 1771 86400 ; refresh ( 24 hours) 1772 7200 ; retry ( 2 hours) 1773 3600000 ; expire (1000 hours) 1774 28800 ) ; minimum ( 8 hours) 1775 86400 RRSIG SOA 5 2 86400 20130522213204 ( 1776 20130422213204 14 example.net. 1777 cmL62SI6iAX46xGNQAdQ... ) 1778 86400 NS a.iana-servers.net. 1779 86400 NS b.iana-servers.net. 1780 86400 RRSIG NS 5 2 86400 20130507213204 ( 1781 20130407213204 14 example.net. 1782 SO5epiJei19AjXoUpFnQ ... ) 1783 86400 DNSKEY 256 3 5 ( 1784 EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 1785 86400 DNSKEY 257 3 5 ( 1786 gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 1787 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1788 20130422213204 14 example.net. 1789 J4zCe8QX4tXVGjV4e1r9... ) 1790 1791 1792 1793 1794Kolkman & Gieben Informational [Page 32] 1795 1796RFC 4641 DNSSEC Operational Practices September 2006 1797 1798 1799 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1800 20130422213204 15 example.net. 1801 keVDCOpsSeDReyV6O... ) 1802 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 1803 20130407213204 14 example.net. 1804 obj3HEp1GjnmhRjX... ) 1805 a.example.net. 86400 IN TXT "A label" 1806 86400 RRSIG TXT 5 3 86400 20130507213204 ( 1807 20130407213204 14 example.net. 1808 IkDMlRdYLmXH7QJnuF3v... ) 1809 86400 NSEC b.example.com. TXT RRSIG NSEC 1810 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 1811 20130407213204 14 example.net. 1812 bZMjoZ3bHjnEz0nIsPMM... ) 1813 ... 1814 1815 is reduced to the following representation: 1816 1817 SOA2006022100 1818 RRSIG14(SOA2006022100) 1819 DNSKEY14 1820 DNSKEY15 1821 1822 RRSIG14(KEY) 1823 RRSIG15(KEY) 1824 1825 The rest of the zone data has the same signature as the SOA record, 1826 i.e., an RRSIG created with DNSKEY 14. 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850Kolkman & Gieben Informational [Page 33] 1851 1852RFC 4641 DNSSEC Operational Practices September 2006 1853 1854 1855Authors' Addresses 1856 1857 Olaf M. Kolkman 1858 NLnet Labs 1859 Kruislaan 419 1860 Amsterdam 1098 VA 1861 The Netherlands 1862 1863 EMail: olaf@nlnetlabs.nl 1864 URI: http://www.nlnetlabs.nl 1865 1866 1867 R. (Miek) Gieben 1868 1869 EMail: miek@miek.nl 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906Kolkman & Gieben Informational [Page 34] 1907 1908RFC 4641 DNSSEC Operational Practices September 2006 1909 1910 1911Full Copyright Statement 1912 1913 Copyright (C) The Internet Society (2006). 1914 1915 This document is subject to the rights, licenses and restrictions 1916 contained in BCP 78, and except as set forth therein, the authors 1917 retain all their rights. 1918 1919 This document and the information contained herein are provided on an 1920 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1921 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1922 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1923 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1924 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1925 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1926 1927Intellectual Property 1928 1929 The IETF takes no position regarding the validity or scope of any 1930 Intellectual Property Rights or other rights that might be claimed to 1931 pertain to the implementation or use of the technology described in 1932 this document or the extent to which any license under such rights 1933 might or might not be available; nor does it represent that it has 1934 made any independent effort to identify any such rights. Information 1935 on the procedures with respect to rights in RFC documents can be 1936 found in BCP 78 and BCP 79. 1937 1938 Copies of IPR disclosures made to the IETF Secretariat and any 1939 assurances of licenses to be made available, or the result of an 1940 attempt made to obtain a general license or permission for the use of 1941 such proprietary rights by implementers or users of this 1942 specification can be obtained from the IETF on-line IPR repository at 1943 http://www.ietf.org/ipr. 1944 1945 The IETF invites any interested party to bring to its attention any 1946 copyrights, patents or patent applications, or other proprietary 1947 rights that may cover technology that may be required to implement 1948 this standard. Please address the information to the IETF at 1949 ietf-ipr@ietf.org. 1950 1951Acknowledgement 1952 1953 Funding for the RFC Editor function is provided by the IETF 1954 Administrative Support Activity (IASA). 1955 1956 1957 1958 1959 1960 1961 1962Kolkman & Gieben Informational [Page 35] 1963 1964