idnits 2.17.1 draft-ietf-dnsop-dnssec-operational-practices-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1121. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1111. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2004) is 7130 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 865, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 871, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 882, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 894, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2541 (ref. '2') (Obsoleted by RFC 4641) ** Obsolete normative reference: RFC 3090 (ref. '3') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-12) exists of draft-ietf-dnsext-keyrr-key-signing-flag-06 == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dnssec-intro-11 == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-07 -- Obsolete informational reference (is this intentional?): RFC 3658 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-key-rollover-requirements-01 Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSOP O. Kolkman 2 Internet-Draft RIPE NCC 3 Expires: April 11, 2005 R. Gieben 4 NLnet Labs 5 October 11, 2004 7 DNSSEC Operational Practices 8 draft-ietf-dnsop-dnssec-operational-practices-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 11, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This document describes a set of practices for operating a DNSSEC 44 aware environment. The target audience is zone administrators 45 deploying DNSSEC that need a guide to help them chose appropriate 46 values for DNSSEC parameters. It also discusses operational matters 47 such as key rollovers, KSK and ZSK considerations and related 48 matters. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3 54 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3 55 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4 57 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5 58 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1 Motivations for the KSK and ZSK Separation . . . . . . . . 7 60 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8 61 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8 62 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8 63 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9 65 3.3.1 Difference Between ZSK and KSK Rollovers . . . . . . . 10 66 3.3.2 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10 67 3.3.3 Key-signing Key Rollovers . . . . . . . . . . . . . . 14 68 3.3.4 Automated Key Rollovers . . . . . . . . . . . . . . . 15 69 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 15 70 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16 71 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16 72 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16 73 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 17 74 5.1 Initial Key Exchanges and Parental Policies 75 Considerations . . . . . . . . . . . . . . . . . . . . . . 17 76 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 17 77 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 18 78 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 18 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 83 8.2 Informative References . . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 85 A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 21 87 C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 22 88 D. Document Details and Changes . . . . . . . . . . . . . . . . . 23 89 D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 23 90 D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 23 91 Intellectual Property and Copyright Statements . . . . . . . . 25 93 1. Introduction 95 During workshops and early operational deployment tests, operators 96 and system administrators gained experience about operating DNSSEC 97 aware DNS services. This document translates these experiences into 98 a set of practices for zone administrators. At the time of writing, 99 there exists very little experience with DNSSEC in production 100 environments, this document should therefore explicitly not be seen 101 as representing 'Best Current Practices'. 103 The procedures herein are focused on the maintenance of signed zones 104 (i.e. signing and publishing zones on authoritative servers). It is 105 intended that maintenance of zones such as resigning or key rollovers 106 be transparent to any verifying clients on the Internet. 108 The structure of this document is as follows: It begins with 109 discussing some of the considerations with respect to timing 110 parameters of DNS in relation to DNSSEC (Section 2). Aspects of key 111 management such as key rollover schemes are described in Section 3. 112 Emergency rollover considerations are addressed in Section 4. The 113 typographic conventions used in this document are explained in 114 Appendix C. 116 Since this is a document with operational suggestions and there are 117 no protocol specifications, the RFC2119 [7] language does not apply. 119 1.1 The Use of the Term 'key' 121 It is assumed that the reader is familiar with the concept of 122 asymmetric keys on which DNSSEC is based (Public Key Cryptography 123 [11]). Therefore, this document will use the term 'key' rather 124 loosely. Where it is written that 'a key is used to sign data' it is 125 assumed that the reader understands that it is the private part of 126 the key-pair that is used for signing. It is also assumed that the 127 reader understands that the public part of the key-pair is published 128 in the DNSKEY resource record and that it is the public part that is 129 used in key-exchanges. 131 1.2 Keeping the Chain of Trust Intact 133 Maintaining a valid chain of trust is important because broken chains 134 of trust will result in data being marked as bogus, which may cause 135 entire (sub)domains to become invisible to verifying clients. The 136 administrators of secured zones have to realize that their zone is, 137 to their clients, part of a chain of trust. 139 As mentioned in the introduction, the procedures herein are intended 140 to ensure maintenance of zones, such as resigning or key rollovers, 141 be transparent to the verifying clients on the Internet. 143 Administrators of secured zones will have to keep in mind that data 144 published on an authoritative primary server will not be immediately 145 seen by verifying clients; it may take some time for the data to be 146 transfered to other secondary authoritative nameservers, during which 147 period clients may be fetching data from caching non-authoritative 148 servers. 150 For the verifying clients it is important that data from secured 151 zones can be used to build chains of trust regardless of whether the 152 data came directly from an authoritative server, a caching nameserver 153 or some middle box. Only by carefully using the available timing 154 parameters can a zone administrator assure that the data necessary 155 for verification can be obtained. 157 The responsibility for maintaining the chain of trust is shared by 158 administrators of secured zones in the chain of trust. This is most 159 obvious in the case of a 'key compromise' when a trade off between 160 maintaining a valid chain of trust and replacing the compromised keys 161 as soon as possible, must be made. 163 The zone administrator will have to make a trade off between keeping 164 the chain of trust intact - thereby allowing for attacks with the 165 compromised key - or to deliberately break the chain of trust and 166 making secured sub domains invisible to security aware resolvers. 167 Also see Section 4. 169 2. Time in DNSSEC 171 Without DNSSEC all times in DNS are relative. The SOA's refresh, 172 retry and expiration timers are counters that are used to determine 173 the time elapsed after a slave server synchronized (or tried to 174 synchronize) with a master server. The Time to Live (TTL) value and 175 the SOA minimum TTL parameter [8] are used to determine how long a 176 forwarder should cache data after it has been fetched from an 177 authoritative server. By using a signature validity period, DNSSEC 178 introduces the notion of an absolute time in the DNS. Signatures in 179 DNSSEC have an expiration date after which the signature is marked as 180 invalid and the signed data is to be considered bogus. 182 2.1 Time Definitions 184 In this document we will be using a number of time related terms. 185 The following definitions apply: 186 o "Signature validity period" 187 The period that a signature is valid. It starts at the time 188 specified in the signature inception field of the RRSIG RR and 189 ends at the time specified in the expiration field of the RRSIG 190 RR. 191 o "Signature publication period" 192 Time after which a signature (made with a specific key) is 193 replaced with a new signature (made with the same key). This 194 replacement takes place by publishing the relevant RRSIG in the 195 master zone file. 196 If all signatures are refreshed at zone (re)signing then the 197 signature publication period is equal to the signature validity 198 period. 199 o "Maximum/Minimum Zone TTL" 200 The maximum or minimum value of the TTLs from the complete set 201 of RRs in a zone. 203 2.2 Time Considerations 205 Because of the expiration of signatures, one should consider the 206 following. 207 o We suggest the Maximum Zone TTL of your zone data to be a fraction 208 of your signature validity period. 209 If the TTL would be of similar order as the signature validity 210 period, then all RRsets fetched during the validity period 211 would be cached until the signature expiration time. Section 212 7.1 [5] suggests that "the resolver may use the time remaining 213 before expiration of the signature validity period of a signed 214 RRset as an upper bound for the TTL". As a result query load 215 on authoritative servers would peak at signature expiration 216 time, as this is also the time at which records simultaneously 217 expire from caches. 218 To avoid query load peaks we suggest the TTL on all the RRs in 219 your zone to be at least a few times smaller than your 220 signature validity period. 221 o We suggest the signature publication period to be at least one 222 maximum TTL smaller than the signature validity period. 223 Resigning a zone shortly before the end of the signature 224 validity period may cause simultaneous expiration of data from 225 caches. This in turn may lead to peaks in the load on 226 authoritative servers. 227 o We suggest the minimum zone TTL to be long enough to both fetch 228 and verify all the RRs in the authentication chain. A low TTL can 229 cause two problems: 230 1. During validation, some data may expire before the 231 validation is complete. The validator should be able to keep 232 all data, until is completed. This applies to all RRs needed 233 to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the 234 final answers i.e. the RR set that is returned for the initial 235 query. 236 2. Frequent verification causes load on recursive nameservers. 237 Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from 238 caching. The TTL on those should be relatively long. 239 o Slave servers will need to be able to fetch newly signed zones 240 well before the RRSIGs in the zone server by the slave server pass 241 their signature expiration time. 242 When a slave server is out of sync with its master and data in 243 a zone is signed by expired signatures it may be better for the 244 slave server not to give out any answer. 245 Normally a slave server that is not able to contact a master 246 server for an extended period will expire a zone. When that 247 happens the zone will not respond on queries. The time of 248 expiration is set in the SOA record and is relative to the last 249 successful refresh between the master and the slave server. 250 There exists no coupling between the signature expiration of 251 RRSIGs in the zone and the expire parameter in the SOA. 252 If the server serves a DNSSEC zone than it may well happen that 253 the signatures expire well before the SOA expiration timer 254 counts down to zero. It is not possible to completely prevent 255 this from happening by tweaking the SOA parameters. 256 However, the effects can be minimized where the SOA expiration 257 time is equal or smaller than the signature validity period. 258 The consequence of an authoritative server not being able to 259 update a zone, whilst that zone includes expired signatures, is 260 that non-secure resolvers will continue to be able to resolve 261 data served by the particular slave servers while security 262 aware resolvers will experience problems because of answers 263 being marked as bogus. 264 We suggest the SOA expiration timer being approximately one 265 third or one fourth of the signature validity period. It will 266 allow problems with transfers from the master server to be 267 noticed before the actual signature time out. 268 We also suggest that operators of nameservers with slave zones 269 develop 'watch dogs' to spot upcoming signature expirations in 270 slave zones, and take appropriate action. 271 When determining the value for the expiration parameter one has 272 to take the following into account: What are the chances that 273 all my secondary zones expire; How quickly can I reach an 274 administrator and load a valid zone? All these arguments are 275 not DNSSEC specific but may influence the choice of your 276 signature validity intervals. 278 3. Keys 280 The DNSSEC validation protocol does not distinguish between DNSKEYs. 281 All DNSKEYs can be used during the validation. In practice operators 282 use Key Singing and Zone Signing Keys and use the so called SEP flag 283 to distinguish between them during operations. The dynamics and 284 considerations are discussed below. 286 To make zone re-signing and key rollovers procedures easier to 287 implement, it is possible to use one or more keys as Key Signing Keys 288 (KSK) these keys will only sign the apex DNSKEY RR set in a zone. 289 Other keys can be used to sign all the RRsets in a zone and are 290 referred to as Zone Signing Keys (ZSK). In this document we assume 291 that KSKs are the subset of keys that are used for key exchanges with 292 the parent and potentially for configuration as trusted anchors - the 293 so called Secure Entry Point keys (SEP). In this document we assume 294 a one-to-one mapping between KSK and SEP keys and we assume the SEP 295 flag [4] to be set on KSKs. 297 3.1 Motivations for the KSK and ZSK Separation 299 Differentiating between the KSK to ZSK functions has several 300 advantages: 302 o The KSK can be made stronger (i.e. using more bits in the key 303 material). This has little operational impact since it is only 304 used to sign a small fraction of the zone data. 305 o As the KSK is only used to sign a key set, which is most probably 306 updated less frequently than other data in the zone, it can be 307 stored separately from and in a safer location than the ZSK. 308 o A KSK can be used for longer periods. 309 o No parent/child interaction is required when ZSKs are updated. 311 The KSK is used less than ZSK, once a key set is signed with the KSK 312 all the keys in the key set can be used as ZSK. If a ZSK is 313 compromised, it can be simply dropped from the key set. The new key 314 set is then resigned with the KSK. 316 Given the assumption that for KSKs the SEP flag is set, the KSK can 317 be distinguished from a ZSK by examining the flag field in the DNSKEY 318 RR. If the flag field is an odd number it is a KSK if it is an even 319 number it is a ZSK. 321 The zone-signing key can be used to sign all the data in a zone on a 322 regular basis. When a zone-signing key is to be rolled, no 323 interaction with the parent is needed. This allows for "Signature 324 Validity Periods" in the order of days. 326 The key-signing key is only to be used to sign the DNSKEY RRs in a 327 zone. If a key-signing key is to be rolled over, there will be 328 interactions with parties other than the zone administrator. These 329 can include the registry of the parent zone or administrators of 330 verifying resolvers that have the particular key configured as 331 trusted entry points. Hence, the "Key Usage Time" of these keys can 332 and should be made much longer. Although, given a long enough key, 333 the "Key Usage Time" can be on the order of years we suggest to plan 334 for a "Key Usage Time" of the order of a few months so that a key 335 rollover remains an operational routine. 337 3.2 Key Security Considerations 339 Keys in DNSSEC have a number of parameters which should all be chosen 340 with care, the most important once are: size, algorithm and the key 341 validity period (its lifetime). 343 3.2.1 Key Validity Period 345 RFC2541 [2] describes a number of considerations with respect to the 346 security of keys. The document deals with the generation, lifetime, 347 size and storage of private keys. 349 In Section 3 of RFC2541 [2] there are some suggestions for a key 350 validity period: 13 months for long-lived keys and 36 days for 351 transaction keys but suggestions for key sizes are not made. 353 If we say long-lived keys are key-signing keys and transactions keys 354 are zone-signing keys, these recommendations will lead to rollovers 355 occurring frequently enough to become part of 'operational habits'; 356 the procedure does not have to be reinvented every time a key is 357 replaced. 359 3.2.2 Key Algorithm 361 There are currently three different types of algorithms that can be 362 used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter 363 is fairly new and still needs to be standardized for usage in DNSSEC. 365 RSA has been developed in an open and transparent manner. As the 366 patent on RSA expired in 2000, its use is now also free. 368 DSA has been developed by NIST. The creation of signatures creation 369 is roughly the same speed as with RSA, but is 10 to 40 times as slow 370 for verification [11]. 372 We suggest the use of RSA/SHA-1 as the preferred algorithm for the 373 key. The current known attacks on RSA can be defeated by making your 374 key longer. As the MD5 hashing algorithm is showing (theoretical) 375 cracks, we recommend the usage of SHA1. 377 3.2.3 Key Sizes 379 When choosing key sizes, zone administrators will need to take into 380 account how long a key will be used and how much data will be signed 381 during the key publication period. It is hard to give precise 382 recommendations but Lenstra and Verheul [10] supplied the following 383 table with lower bound estimates for cryptographic key sizes. Their 384 recommendations are based on a set of explicitly formulated parameter 385 settings, combined with existing data points about cryptographic 386 systems. For details we refer to the original paper. 388 Year RSA Key Sizes Year RSA Key Sizes 390 2000 952 2015 1613 391 2001 990 2016 1664 392 2002 1028 2017 1717 393 2003 1068 2018 1771 394 2004 1108 2019 1825 396 2005 1149 2020 1881 397 2006 1191 2021 1937 398 2007 1235 2022 1995 399 2008 1279 2023 2054 400 2009 1323 2024 2113 402 2026 2236 2025 2174 403 2010 1369 2027 2299 404 2011 1416 2028 2362 405 2012 1464 2029 2427 406 2013 1513 407 2014 1562 409 For example, should you wish your key to last three years from 2003, 410 check the RSA key size values for 2006 in this table. In this case 411 1191. 413 3.3 Key Rollovers 415 A DNSSEC key cannot be used forever (see RFC2541 [2] and Section 416 3.2). So key rollovers are a fact of life when using DNSSEC. Zone 417 administrators who are in the process of rolling their keys have to 418 take into account that data published in previous versions of their 419 zone still lives in caches. When deploying DNSSEC, this becomes an 420 important consideration; ignoring data that may be in caches may lead 421 to loss of service for clients. 423 The most pressing example of this is when zone material signed with 424 an old key is being validated by a resolver which does not have the 425 old zone key cached. If the old key is no longer present in the 426 current zone, this validation fails, marking the data bogus. 427 Alternatively, an attempt could be made to validate data which is 428 signed with a new key against an old key that lives in a local cache, 429 also resulting in data being marked bogus. 431 3.3.1 Difference Between ZSK and KSK Rollovers 433 Note that KSK rollovers and ZSK rollovers are different. A zone-key 434 rollover can be handled in two different ways: pre-publish (Section 435 Section 3.3.2.1) and double signature (Section Section 3.3.2.2). 437 As the KSK is used to validate the key set and because the KSK is not 438 changed during a ZSK rollover, a cache is able to validate the new 439 key set of the zone. The pre-publish method does not work for a KSK 440 rollover. The following example demonstrates that, here rollover the 441 KSK from DNSKEY1 to DNSKEY2 using the NONE working pre-publish 442 method. 444 normal pre-roll roll after 446 SOA0 SOA1 SOA2 SOA3 447 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 449 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY2 450 DNSKEY10 DNSKEY2 DNSKEY2 DNSKEY10 451 DNSKEY10 DNSKEY10 452 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 453 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) 455 A cache that queries the zone during the "normal" step gets back 456 DNSKEY1. The DS RR and the key set are cached. If the TTL of the DS 457 RR is large enough, the DS RR remains in the cache until the "after" 458 step. If in this case, the key set TTL expires, and the cache 459 queries for the zone again, it will get back the new key set signed 460 by DNSKEY2. It will then try to validate the key set with DNSKEY1 461 and will fail. 463 3.3.2 Zone-signing Key Rollovers 465 For zone-signing key rollovers there are two ways to make sure that 466 during the rollover data still cached can be verified with the new 467 key sets or newly generated signatures can be verified with the keys 468 still in caches. One schema uses double signatures, it is described 469 in Section 3.3.2.2, the other uses key pre-publication (Section 470 3.3.2.1). The pros, cons and recommendations are described in 471 Section 3.3.2.3. 473 3.3.2.1 Pre-publish key set Rollover 475 This section shows how to perform a ZSK rollover without the need to 476 sign all the data in a zone twice - the so called "pre-publish 477 rollover".This method has advantages in the case of a key compromise. 478 If the old key is compromised, the new key has already been 479 distributed in the DNS. The zone administrator is then able to 480 quickly switch to the new key and remove the compromised key from the 481 zone. Another major advantage is that the zone size does not double, 482 as is the case with the double signature ZSK rollover. A small 483 "HOWTO" for this kind of rollover can be found in Appendix B. 485 normal pre-roll roll after 487 SOA0 SOA1 SOA2 SOA3 488 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 490 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 491 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 492 DNSKEY11 DNSKEY11 493 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 494 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 496 normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. 497 DNSKEY 10 is used to sign all the data of the zone, the 498 zone-signing key. 499 pre-roll: DNSKEY 11 is introduced into the key set. Note that no 500 signatures are generated with this key yet, but this does not 501 secure against brute force attacks on the public key. The minimum 502 duration of this pre-roll phase is the time it takes for the data 503 to propagate to the authoritative servers plus TTL value of the 504 key set. This equates to two times the Maximum Zone TTL. 505 roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign 506 the data in the zone exclusively (i.e. all the signatures from 507 DNSKEY 10 are removed from the zone). DNSKEY 10 remains published 508 in the key set. This way data that was loaded into caches from 509 version 1 of the zone can still be verified with key sets fetched 510 from version 2 of the zone. 511 The minimum time that the key set including DNSKEY 10 is to be 512 published is the time that it takes for zone data from the 513 previous version of the zone to expire from old caches i.e. the 514 time it takes for this zone to propagate to all authoritative 515 servers plus the Maximum Zone TTL value of any of the data in the 516 previous version of the zone. 518 after: DNSKEY 10 is removed from the zone. The key set, now only 519 containing DNSKEY 11 is resigned with the DNSKEY 1. 521 The above scheme can be simplified by always publishing the "future" 522 key immediately after the rollover. The scheme would look as follows 523 (we show two rollovers); the future key is introduced in "after" as 524 DNSKEY 12 and again a newer one, numbered 13, in "2nd after": 526 normal roll after 528 SOA0 SOA2 SOA3 529 RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) 531 DNSKEY1 DNSKEY1 DNSKEY1 532 DNSKEY10 DNSKEY10 DNSKEY11 533 DNSKEY11 DNSKEY11 DNSKEY12 534 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 535 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 537 2nd roll 2nd after 539 SOA4 SOA5 540 RRSIG12(SOA4) RRSIG12(SOA5) 542 DNSKEY1 DNSKEY1 543 DNSKEY11 DNSKEY12 544 DNSKEY12 DNSKEY13 545 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 546 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 548 Note that the key introduced after the rollover is not used for 549 production yet; the private key can thus be stored in a physically 550 secure manner and does not need to be 'fetched' every time a zone 551 needs to be signed. 553 3.3.2.2 Double Signature Zone-signing Key Rollover 555 This section shows how to perform a ZSK key rollover using the double 556 zone data signature scheme, aptly named "double sig rollover". 558 During the rollover stage the new version of the zone file will need 559 to propagate to all authoritative servers and the data that exists in 560 (distant) caches will need to expire, this will take at least the 561 maximum Zone TTL . 563 normal roll after 565 SOA0 SOA1 SOA2 566 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 567 RRSIG11(SOA1) 569 DNSKEY1 DNSKEY1 DNSKEY1 570 DNSKEY10 DNSKEY10 DNSKEY11 571 DNSKEY11 572 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 573 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 574 RRSIG11(DNSKEY) 576 normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. 577 DNSKEY 10 is used to sign all the data of the zone, the 578 zone-signing key. 579 roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced 580 into the key set and all the data in the zone is signed with 581 DNSKEY 10 and DNSKEY 11. The rollover period will need to exist 582 until all data from version 0 of the zone has expired from remote 583 caches. This will take at least the maximum Zone TTL of version 0 584 of the zone. 585 after: DNSKEY 10 is removed from the zone. All the signatures from 586 DNSKEY 10 are removed from the zone. The key set, now only 587 containing DNSKEY 11, is resigned with DNSKEY 1. 589 At every instance the data from the previous version of the zone can 590 be verified with the key from the current version and the other way 591 around. The data from the current version can be verified with the 592 data from the previous version of the zone. The duration of the 593 rollover phase and the period between rollovers should be at least 594 the "Maximum Zone TTL". 596 Making sure that the rollover phase lasts until the signature 597 expiration time of the data in version 0 of the zone is recommended. 598 This way all caches are cleared of the old signatures. However, this 599 date could be considerably longer than the Maximum Zone TTL, making 600 the rollover a lengthy procedure. 602 Note that in this example we assumed that the zone was not modified 603 during the rollover. New data can be introduced in the zone as long 604 as it is signed with both keys. 606 3.3.2.3 Pros and Cons of the Schemes 607 Pre-publish-key set rollover: This rollover does not involve signing 608 the zone data twice. Instead, just before the actual rollover, 609 the new key is published in the key set and thus available for 610 cryptanalysis attacks. A small disadvantage is that this process 611 requires four steps. Also the pre-publish scheme will not work 612 for KSKs as explained in Section 3.3. 613 Double signature rollover: The drawback of this signing scheme is 614 that during the rollover the number of signatures in your zone 615 doubles, this may be prohibitive if you have very big zones. An 616 advantage is that it only requires three steps. 618 3.3.3 Key-signing Key Rollovers 620 For the rollover of a key-signing key the same considerations as for 621 the rollover of a zone-signing key apply. However we can use a 622 double signature scheme to guarantee that old data (only the apex key 623 set) in caches can be verified with a new key set and vice versa. 625 Since only the key set is signed with a KSK, zone size considerations 626 do not apply. 628 normal roll after 630 SOA0 SOA1 SOA2 631 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) 633 DNSKEY1 DNSKEY1 DNSKEY2 634 DNSKEY2 635 DNSKEY10 DNSKEY10 DNSKEY10 636 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) 637 RRSIG2 (DNSKEY) 638 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) 640 normal: Version 0 of the zone. The parental DS points to DNSKEY1. 641 Before the rollover starts the child will have to verify what the 642 TTL is of the DS RR that points to DNSKEY1 - it is needed during 643 the rollover and we refer to the value as TTL_DS. 644 roll: During the rollover phase the zone administrator generates a 645 second KSK, DNSKEY2. The key is provided to the parent and the 646 child will have to wait until a new DS RR has been generated that 647 points to DNSKEY2. After that DS RR has been published on all 648 servers authoritative for the parents zone, the zone administrator 649 has to wait at least TTL_DS to make sure that the old DS RR has 650 expired from caches. 652 after: DNSKEY1 has been removed. 654 The scenario above puts the responsibility for maintaining a valid 655 chain of trust with the child. It also is based on the premises hat 656 the parent only has one DS RR (per algorithm) per zone. An 657 alternative mechanism has been considered. Using an established 658 trust relation, the interaction can be performed in-band, and where 659 removal of the keys by the child can be signaled by the parent. In 660 this mechanism there are periods where there are two DS RRs at the 661 parent. Since at the moment of writing the protocol for this 662 interaction has not been developed further discussion is out of scope 663 for this document. 665 3.3.4 Automated Key Rollovers 667 As keys must be renewed periodically, there are some motivation to 668 automate the rollover process (also see [12]) 670 o ZSK rollovers are easy to automate as only the local zone is 671 involved. 672 o A KSK rollover needs interaction between the parent and child. 673 Data exchange is needed to provide the new keys to the parent, 674 consequently, this data must be authenticated and integrity must 675 be guaranteed in order to avoid attacks on the rollover. 676 o All time and TTL considerations presented in Section 3.3 apply to 677 an automated rollover. 679 4. Planning for Emergency Key Rollover 681 This section deals with preparation for a possible key compromise. 682 Our advice is to have a documented procedure ready for when a key 683 compromise is suspected or confirmed. 685 When the private material of one of your keys is compromised it can 686 be used for as long as a valid authentication chain exists. An 687 authentication chain remains intact for: 688 o as long as a signature over the compromised key in the 689 authentication chain is valid, 690 o as long as a parental DS RR (and signature) points to the 691 compromised key, 692 o as long as the key is anchored in a resolver and is used as a 693 starting point for validation. (This is the hardest to update.) 695 While an authentication chain to your compromised key exists, your 696 name-space is vulnerable to abuse by the malicious key holder (i.e. 697 the owner of the compromised key). Zone operators have to make a 698 trade off if the abuse of the compromised key is worse than having 699 data in caches that cannot be validated. If the zone operator 700 chooses to break the authentication chain to the compromised key, 701 data in caches signed with this key cannot be validated. However, if 702 the zone administrator chooses to take the path of a regular 703 roll-over, the malicious key holder can spoof data so that it appears 704 to be valid. Note that this kind of attack is more likely to occur 705 in a localized part of the network topology i.e. downstream from 706 where the spoof takes place. 708 4.1 KSK Compromise 710 When the KSK has been compromised the parent must be notified as soon 711 as possible using secure means. The key set of the zone should be 712 resigned as soon as possible. Care must be taken to not break the 713 authentication chain. The local zone can only be resigned with the 714 new KSK after the parent's zone has created and reloaded its zone 715 with the DS created from the new KSK. Before this update takes place 716 it would be best to drop the security status of a zone all together: 717 the parent removes the DS of the child at the next zone update. 718 After that the child can be made secure again. 720 An additional danger of a key compromise is that the compromised key 721 can be used to facilitate a legitimate DNSKEY/DS and/or nameserver 722 rollover at the parent. When that happens the domain can be in 723 dispute. An out of band and secure notify mechanism to contact a 724 parent is needed in this case. 726 4.2 ZSK Compromise 728 Primarily because there is no parental interaction required when a 729 ZSK is compromised, the situation is less severe than with with a KSK 730 compromise. The zone must still be resigned with a new ZSK as soon 731 as possible. As this is a local operation and requires no 732 communication between the parent and child this can be achieved 733 fairly quickly. However, one has to take into account that just as 734 with a normal rollover the immediate disappearance from the old 735 compromised key may lead to verification problems. The 736 pre-publication scheme as discussed above minimizes such problems. 738 4.3 Compromises of Keys Anchored in Resolvers 740 A key can also be pre-configured in resolvers. For instance, if 741 DNSSEC is successfully deployed the root key will be pre-configured 742 in most security aware resolvers. 744 If trust-anchor keys are compromised, the resolvers using these keys 745 should be notified of this fact. Zone administrators may consider 746 setting up a mailing list to communicate the fact that a SEP key is 747 about to be rolled over. This communication will of course need to 748 be authenticated e.g. by using digital signatures. 750 End-user faced with the task of updating anchored key should always 751 validate the new key. New keys should be authenticated out of the 752 DNS, for example, looking them up on an x.509 secured announcement 753 website. 755 5. Parental Policies 757 5.1 Initial Key Exchanges and Parental Policies Considerations 759 The initial key exchange is always subject to the policies set by the 760 parent (or its registry). When designing a key exchange policy one 761 should take into account that the authentication and authorization 762 mechanisms used during a key exchange should be as strong as the 763 authentication and authorization mechanisms used for the exchange of 764 delegation information between parent and child. I.e. there is no 765 implicit need in DNSSEC to make the authentication process stronger 766 than it was in DNS. 768 Using the DNS itself as the source for the actual DNSKEY material, 769 with an off-band check on the validity of the DNSKEY, has the benefit 770 that it reduces the chances of user error. A parental DNSKEY 771 download tool can make use of the SEP bit [4] to select the proper 772 key from a DNSSEC key set; thereby reducing the chance that the wrong 773 DNSKEY is sent. It can validate the self-signature over a key; 774 thereby verifying the ownership of the private key material. 775 Fetching the DNSKEY from the DNS ensures that the child will not 776 become bogus once the parent publishes the DS RR indicating the child 777 is secure. 779 Note: the off-band verification is still needed when the key-material 780 is fetched via the DNS. The parent can never be sure whether the 781 DNSKEY RRs have been spoofed or not. 783 5.2 Storing Keys So Hashes Can Be Regenerated 785 When designing a registry system one should consider if the DNSKEYs 786 and/or the corresponding DSs are stored. Storing DNSKEYs will help 787 during troubleshooting while the overhead of calculating DS records 788 from them is minimal. 790 Having an out-of-band mechanism, such as a Whois database, to find 791 out which keys are used to generate DS Resource Records for specific 792 owners and/or zones may also help with troubleshooting. 794 5.3 Security Lameness Checks 796 Security Lameness is defined as what happens when a parent has a DS 797 RR pointing to a non-existing DNSKEY RR. During key exchange a 798 parent should make sure that the child's key is actually configured 799 in the DNS before publishing a DS RR in its zone. Failure to do so 800 would render the child's zone being marked as bogus. 802 Child zones should be very careful removing DNSKEY material, 803 specifically SEP keys, for which a DS RR exists. 805 Once a zone is "security lame" a fix (e.g. by removing a DS RR) will 806 take time to propagate through the DNS. 808 5.4 DS Signature Validity Period 810 Since the DS can be replayed as long as it has a valid signature a 811 short signature validity period over the DS minimizes the time a 812 child is vulnerable in the case of a compromise of the child's 813 KSK(s). A signature validity period that is too short introduces the 814 possibility that a zone is marked bogus in case of a configuration 815 error in the signer. There may not be enough time to fix the 816 problems before signatures expire. Something as mundane as operator 817 unavailability during weekends shows the need for DS signature 818 lifetimes longer than 2 days. We recommend the minimum for a DS 819 signature validity period to be a few days. 821 The maximum signature lifetime of the DS record depends on how long 822 child zones are willing to be vulnerable after a key compromise. 823 Other considerations, such as how often the zone is (re)signed can 824 also be taken into account. 826 We consider a signature validity period of around one week to be a 827 good compromise between the operational constraints of the parent and 828 minimizing damage for the child. 830 6. Security Considerations 832 DNSSEC adds data integrity to the DNS. This document tries to assess 833 considerations to operate a stable and secure DNSSEC service. Not 834 taking into account the 'data propagation' properties in the DNS will 835 cause validation failures and may make secured zones unavailable to 836 security aware resolvers. 838 7. Acknowledgments 840 We, the folk mentioned as authors, only acted as editors. Most of 841 the ideas in this draft were the result of collective efforts during 842 workshops, discussions and try outs. 844 At the risk of forgetting individuals who where the original 845 contributors of the ideas we would like to acknowledge people who 846 where actively involved in the compilation of this document. In 847 random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson, 848 Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier 849 Courtay, Sam Weiler, Jelte Jansen. 851 Mike StJohns designed the key exchange between parent and child 852 mentioned in the last paragraph of Section 3.3.3 854 Section 3.3.4 was supplied by G. Guette and O. Courtay. 856 Emma Bretherick and Adrian Bedford corrected many of the spelling and 857 style issues. 859 Kolkman and Gieben take the blame for introducing all miscakes(SIC). 861 8. References 863 8.1 Normative References 865 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 866 2535, March 1999. 868 [2] Eastlake, D., "DNS Security Operational Considerations", RFC 869 2541, March 1999. 871 [3] Lewis, E., "DNS Security Extension Clarification on Zone 872 Status", RFC 3090, March 2001. 874 [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key 875 (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work 876 in progress), February 2003. 878 [5] Arends, R., "DNS Security Introduction and Requirements", 879 draft-ietf-dnsext-dnssec-intro-11 (work in progress), March 880 2003. 882 [6] Arends, R., "Protocol Modifications for the DNS Security 883 Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in 884 progress), March 2003. 886 8.2 Informative References 888 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 889 Levels", BCP 14, RFC 2119, March 1997. 891 [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 892 RFC 2308, March 1998. 894 [9] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", 895 RFC 3658, December 2003. 897 [10] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 898 Sizes", The Journal of Cryptology 14 (255-293), 2001. 900 [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and 901 Source Code in C", 1996. 903 [12] Guette, G., "Requirements for Automated Key Rollover in 904 DNSsec", draft-ietf-dnsop-key-rollover-requirements-01 (work in 905 progress), August 2004. 907 Authors' Addresses 909 Olaf M. Kolkman 910 RIPE NCC 911 Singel 256 912 Amsterdam 1016 AB 913 The Netherlands 915 Phone: +31 20 535 4444 916 EMail: olaf@ripe.net 917 URI: http://www.ripe.net/ 919 Miek Gieben 920 NLnet Labs 921 Kruislaan 419 922 Amsterdam 1098 VA 923 The Netherlands 925 EMail: miek@nlnetlabs.nl 926 URI: http://www.nlnetlabs.nl 928 Appendix A. Terminology 930 In this document there is some jargon used that is defined in other 931 documents. In most cases we have not copied the text from the 932 documents defining the terms but given a more elaborate explanation 933 of the meaning. Note that these explanations should not be seen as 934 authoritative. 936 Private and Public Keys: DNSSEC secures the DNS through the use of 937 public key cryptography. Public key cryptography is based on the 938 existence of two keys, a public key and a private key. The public 939 keys are published in the DNS by use of the DNSKEY Resource Record 940 (DNSKEY RR). Private keys should remain private. 941 Signer: The system that has access to the private key material and 942 signs the Resource Record sets in a zone. A signer may be 943 configured to sign only parts of the zone e.g. only those RRsets 944 for which existing signatures are about to expire. 945 KSK: A Key-Signing Key (KSK) is a key that is used exclusively for 946 signing the apex key set. The fact that a key is a KSK is only 947 relevant to the signing tool. 948 ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all 949 data in a zone. The fact that a key is a ZSK is only relevant to 950 the signing tool. 951 SEP Key: A KSK that has a parental DS record pointing to it. Note: 952 this is not enforced in the protocol. A SEP Key with no parental 953 DS is security lame. 954 Anchored Key: A DNSKEY configured in resolvers around the globe. 955 This key is hard to update, hence the term anchored. 956 Bogus: Also see Section 5 of [5]. An RRset in DNSSEC is marked 957 "Bogus" when a signature of a RRset does not validate against a 958 DNSKEY. 959 Singing the Zone File: The term used for the event where an 960 administrator joyfully signs its zone file while producing melodic 961 sound patterns. 962 Zone Administrator: The 'role' that is responsible for signing a zone 963 and publishing it on the primary authoritative server. 965 Appendix B. Zone-signing Key Rollover Howto 967 Using the pre-published signature scheme and the most conservative 968 method to assure oneself that data does not live in caches here 969 follows the "HOWTO". 970 Key notation: 971 Step 0: The preparation: Create two keys and publish both in your key 972 set. Mark one of the keys as "active" and the other as 973 "published". Use the "active" key for signing your zone data. 974 Store the private part of the "published" key, preferably 975 off-line. 976 Step 1: Determine expiration: At the beginning of the rollover make a 977 note of the highest expiration time of signatures in your zone 978 file created with the current key marked as "active". 979 Wait until the expiration time marked in Step 1 has passed 980 Step 2: Then start using the key that was marked as "published" to 981 sign your data i.e. mark it as "active". Stop using the key that 982 was marked as "active", mark it as "rolled". 984 Step 3: It is safe to engage in a new rollover (Step 1) after at 985 least one "signature validity period". 987 Appendix C. Typographic Conventions 989 The following typographic conventions are used in this document: 990 Key notation: A key is denoted by KEYx, where x is a number, x could 991 be thought of as the key id. 992 RRset notations: RRs are only denoted by the type. All other 993 information - owner, class, rdata and TTL - is left out. Thus: 994 "example.com 3600 IN A 192.168.1.1" is reduced to "A". RRsets are 995 a list of RRs. A example of this would be: "A1,A2", specifying 996 the RRset containing two "A" records. This could again be 997 abbreviated to just "A". 998 Signature notation: Signatures are denoted as RRSIGx(RRset), which 999 means that RRset is signed with DNSKEYx. 1000 Zone representation: Using the above notation we have simplified the 1001 representation of a signed zone by leaving out all unnecessary 1002 details such as the names and by representing all data by "SOAx" 1003 SOA representation: SOA's are represented as SOAx, where x is the 1004 serial number. 1005 Using this notation the following zone: 1007 example.net. 600 IN SOA ns.example.net. bert.example.net. ( 1008 10 ; serial 1009 450 ; refresh (7 minutes 30 seconds) 1010 600 ; retry (10 minutes) 1011 345600 ; expire (4 days) 1012 300 ; minimum (5 minutes) 1013 ) 1014 600 RRSIG SOA 5 2 600 20130522213204 ( 1015 20130422213204 14 example.net. 1016 cmL62SI6iAX46xGNQAdQ... ) 1017 600 NS a.iana-servers.net. 1018 600 NS b.iana-servers.net. 1019 600 RRSIG NS 5 2 600 20130507213204 ( 1020 20130407213204 14 example.net. 1021 SO5epiJei19AjXoUpFnQ ... ) 1022 3600 DNSKEY 256 3 5 ( 1023 EtRB9MP5/AvOuVO0I8XDxy0... 1024 ) ; key id = 14 1025 3600 DNSKEY 256 3 5 ( 1026 gsPW/Yy19GzYIY+Gnr8HABU... 1027 ) ; key id = 15 1028 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 1029 20130422213204 14 example.net. 1030 J4zCe8QX4tXVGjV4e1r9... ) 1032 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 1033 20130422213204 15 example.net. 1034 keVDCOpsSeDReyV6O... ) 1035 600 RRSIG NSEC 5 2 600 20130507213204 ( 1036 20130407213204 14 example.net. 1037 obj3HEp1GjnmhRjX... ) 1038 a.example.net. 600 IN TXT "A label" 1039 600 RRSIG TXT 5 3 600 20130507213204 ( 1040 20130407213204 14 example.net. 1041 IkDMlRdYLmXH7QJnuF3v... ) 1042 600 NSEC b.example.com. TXT RRSIG NSEC 1043 600 RRSIG NSEC 5 3 600 20130507213204 ( 1044 20130407213204 14 example.net. 1045 bZMjoZ3bHjnEz0nIsPMM... ) 1047 ... 1049 is reduced to the following representation: 1051 SOA10 1052 RRSIG14(SOA10) 1054 DNSKEY14 1055 DNSKEY15 1057 RRSIG14(KEY) 1058 RRSIG15(KEY) 1060 The rest of the zone data has the same signature as the SOA record, 1061 i.e a RRSIG created with DNSKEY 14. 1063 Appendix D. Document Details and Changes 1065 This section is to be removed by the RFC editor if and when the 1066 document is published. 1068 $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.29 2004/ 1069 10/11 11:27:10 dnssec Exp $ 1071 D.1 draft-ietf-dnsop-dnssec-operational-practices-00 1073 Submission as working group document. This document is a modified 1074 and updated version of draft-kolkman-dnssec-operational-practices-00. 1076 D.2 draft-ietf-dnsop-dnssec-operational-practices-01 1078 changed the definition of "Bogus" to reflect the one in the protocol 1079 draft. 1081 Bad to Bogus 1083 Style and spelling corrections 1085 KSK - SEP mapping made explicit. 1087 Updates from Sam Weiler added 1089 Intellectual Property Statement 1091 The IETF takes no position regarding the validity or scope of any 1092 Intellectual Property Rights or other rights that might be claimed to 1093 pertain to the implementation or use of the technology described in 1094 this document or the extent to which any license under such rights 1095 might or might not be available; nor does it represent that it has 1096 made any independent effort to identify any such rights. Information 1097 on the procedures with respect to rights in RFC documents can be 1098 found in BCP 78 and BCP 79. 1100 Copies of IPR disclosures made to the IETF Secretariat and any 1101 assurances of licenses to be made available, or the result of an 1102 attempt made to obtain a general license or permission for the use of 1103 such proprietary rights by implementers or users of this 1104 specification can be obtained from the IETF on-line IPR repository at 1105 http://www.ietf.org/ipr. 1107 The IETF invites any interested party to bring to its attention any 1108 copyrights, patents or patent applications, or other proprietary 1109 rights that may cover technology that may be required to implement 1110 this standard. Please address the information to the IETF at 1111 ietf-ipr@ietf.org. 1113 Disclaimer of Validity 1115 This document and the information contained herein are provided on an 1116 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1117 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1118 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1119 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1120 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1121 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1123 Copyright Statement 1125 Copyright (C) The Internet Society (2004). This document is subject 1126 to the rights, licenses and restrictions contained in BCP 78, and 1127 except as set forth therein, the authors retain all their rights. 1129 Acknowledgment 1131 Funding for the RFC Editor function is currently provided by the 1132 Internet Society.