idnits 2.17.1 draft-koch-dnsop-dnssec-operator-change-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 140 has weird spacing: '...perator is th...' == Line 143 has weird spacing: '...perator denot...' -- The document date (February 14, 2014) is 3718 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: 'RFC1034' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC5910' is defined on line 567, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4641 (Obsoleted by RFC 6781) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) ** Downref: Normative reference to an Informational RFC: RFC 6781 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Koch 3 Internet-Draft M. Sanz 4 Intended status: Standards Track DENIC eG 5 Expires: August 18, 2014 A.L.J. Verschuren 6 SIDN Labs 7 February 14, 2014 9 Changing DNS Operators for DNSSEC signed Zones 10 draft-koch-dnsop-dnssec-operator-change-06 12 Abstract 14 Changing the DNS delegation for a DNS zone is quite involved if done 15 by the books, but most often handled pragmatically in today's 16 operational practice at the top level with registries and registrars. 17 This document describes a delegation change procedure that maintains 18 consistency and validation under DNSSEC. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 18, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Purpose of this Document . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements and Assumptions for Seamless Operator Change . . 4 58 2.1. Requirements for Seamless Operator Change . . . . . . . . 4 59 2.2. Assumptions for Seamless Operator Change . . . . . . . . 5 60 3. Executing the Change . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Changing DNS operator only . . . . . . . . . . . . . . . 7 62 3.2. Changing DNS operator and registrar . . . . . . . . . . . 9 63 3.3. Losing operator not participating . . . . . . . . . . . . 10 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 7.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Appendix A. Document Revision History . . . . . . . . . . . . . 13 71 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 A.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 A.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 A.6. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 A.7. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 When the NS RRSet in a DNS delegation is to be changed from one to a 83 disjoint other, the most conservative approach would be to add the 84 new servers as (stealth) secondary servers, then add them to the NS 85 RRSet, change the primary master (that is, change the AXFR/IXFR 86 source for all the secondary servers), remove the old name servers' 87 names from the NS RRSet and finally cease service on those former 88 name servers. This would involve two changes to the zone file for 89 the apex NS RRSet and in turn two interactions with the parent zone 90 (the registry) for the delegation NS RRSet. Another procedure would 91 at least see the old name servers acquire the new data by transfer 92 and then publish it until the NS records' time to live (TTL) values 93 expire. 95 Operational practice deviates from this in many cases, especially 96 where there is a combined role of the registrar as registrar, DNS 97 operator and web hoster. Often the new infrastructure is set up 98 independent of and in parallel to the old one and there is only one 99 delegation change. Resolvers will access either version of the DNS 100 zone and the inconsistency in DNS data and even at the application 101 layer will be tolerated as long as the end user gets to see any 102 result at all. 104 DNSSEC [RFC4033][RFC4034][RFC4035] is less tolerant to this 105 inconsistency, and the challenge is that access to and validation of 106 DNS data will involve multiple steps. The resolver might access DNS 107 data through one (say, the old) name server infrastructure and DNS 108 key material (the apex DNSKEY RRSet) through the other. A hard 109 switch would increase the likelyhood of a validation failure, should 110 the signature over some RRSet not match any key in the DNSKEY RRSet. 112 1.1. Purpose of this Document 114 This document attempts to list requirements for a seamless change of 115 DNS operators in a registry/registrar environment. It then suggests 116 a procedure that should work in an automated environment even for 117 large numbers of DNS operator changes. It is meant as a supplement 118 or contribution to the updated version of [RFC4641], as currently 119 expressed in [RFC6781], section 4.3.5. 121 1.2. Terminology 123 The change of DNS infrastructure involves multiple parties. We are 124 using the following terms throughout the document. 126 Registrar. The entity that can change entries in a DNS registry 127 database, usually, but not restricted to, by means of a realtime 128 provisioning protocol like EPP [RFC5730]. NB: the procedure 129 described in this document does not require a strict registry- 130 registrar-registrant separation. Where the registrant can 131 directly interact with the registry they are considered filling 132 the registrar role. 134 DNS operator. The DNS operator provides the DNS infrastructure for a 135 given DNS zone (delegated domain). This party may or may not be 136 identical to the registrant or the registrar. The details of 137 provisioning the DNS data into the DNS zone are beyond the scope 138 of this document. 140 losing DNS operator is the party that controls zone content and DNS 141 infrastructure at the beginning of a DNS operator change. 143 gaining DNS operator denotes the party that will control zone 144 content and DNS infrastructure after the successful DNS operator 145 change. 147 The terms Zone Signing Key (ZSK) and Key Signing Key (KSK) are 148 defined in section 2 of [RFC4033]. 150 Domain names and IP addresses herein are for explanatory purposes 151 only and should not be expected to lead to useful information in real 152 life [RFC2606],[RFC5735]. 154 2. Requirements and Assumptions for Seamless Operator Change 156 Regardless of the the particular registry provisioning protocol 157 (e.g., EPP, [RFC5730], [RFC5731]) DNS registries usually provide for 158 a method to transfer a domain name between different registrars. 159 However, from this angle there is no separate role for the DNS 160 operator, the entity that is responsible for the DNS infrastructure 161 and/or the content of the DNS zone. This entity may be identical to 162 the registrar, the registrant, or neither. From the DNSSEC 163 perspective it is important to consider the entity controlling the 164 ZSK and KSK in any transfer that involves changing the NS RRSet to a 165 disjoint set (as opposed to simple additions to or removals from the 166 NS RRSet). 168 The change of a registrar is of limited effect from the DNSSEC 169 perspective. The discussion of the ability of the gaining registrar 170 to accept DNSSEC information within a domain object is beyond the 171 scope of this document. The focus is kept on the change of the DNS 172 operator. There are two cases: ideally, the losing operator will be 173 able to incorporate data generated by the gaining operator into their 174 version of the DNS zone. However, the proposed solution should also 175 be able to cover the case where this cooperation cannot be relied 176 upon. 178 2.1. Requirements for Seamless Operator Change 180 This is a list of requirements for the operator change: 182 no validation failures During the operator change, as in normal 183 operations, DNSSEC validation failures, resulting from unavailable 184 or outdated key or signature material, must be avoided. 186 validation failures worse than insecure Where there is the choice 187 between DNSSEC validation failures and an insecure state, the 188 latter is to be preferred, although its extent still ought to be 189 kept to a necessary minimum. 191 no private keys Private cryptographic keys will not be exchanged 192 between the losing and the gaining operator. Scenarios in which 193 this would be feasible would not pose the challenges addressed in 194 this document. 196 no use of foreign RRSIG information The process of signing a zone is 197 usually done in one of three ways: The zone is signed completely 198 as a file, then loaded into a name server, the signer is a "bump 199 in the wire" solution or the name server combines signing and 200 serving on the primary master. Adding foreign signatures into a 201 zone is not easily achieved in any of these setups, so it ought to 202 be avoided. It also helps contain the effect of changes to an 203 RRSet locally, as no signatures have to be generated remotely with 204 subsequent re-import. 206 little interaction To ease automation the number of interactions 207 between registry, registrar or registrars and operators should be 208 minimized. 210 little overhead for losing operator Whenever interaction or action 211 cannot be avoided, the losing operator should be involved as 212 little as possible to avoid overhead for the leaving customer. In 213 turn, this suggests the gaining operator should be in control of 214 the process. 216 2.2. Assumptions for Seamless Operator Change 218 This is a list of assumptions for the operator change: 220 no direct communication channel between operators We do not assume 221 the existence of a direct, confidential, authenticated 222 communication channel between the losing and the gaining operator. 223 On an abstract level, the registrant could be viewed as an 224 indirect channel, but involving the registrant is not necessarily 225 easily automated. 227 secure communication channel between operator, registrar, and registry 228 We do, though, assume the existence of a direct, confidential, 229 authenticated communication channel between an operator and their 230 registrar as well as between the registrar and the registry. 232 incorporation of foreign DNSKEY RRs To achieve a symmetric 233 validation chain along the DS/KSK/ZSK of both the losing and the 234 gaining DNS operator it is assumed that either operator can, 235 technically, incorporate DNSKEY RRs into their apex DNSKEY RRSet. 236 This includes the ability to subsequently properly sign the DNSKEY 237 RRSet. 239 ability to store and retrieve DNSKEY RRs We assume that registrars 240 are able to store in and retrieve from the registry DNSKEY RRs or 241 equivalent information. This can be achieved by the registry 242 using DNSKEY RRs as key material (as opposed to or in addition to 243 DS RRs) or by the ability to insert DNSKEY data in free text or 244 remarks fields within or associated with the domain object. 246 no algorithm rollover Current reading is that an algorithm rollover 247 requires a full validation with all algorithms involved, whereas a 248 key rollover will work whenever data can be validated using either 249 key ([RFC4035], section 2.2). Therefore, it is assumed that both 250 operators utilize the same DNSSEC key algorithm during the 251 transfer. This does neither preclude the use of different key 252 sizes nor the change of key algorithms after the DNS operator 253 change. 255 ZSK/KSK separation This document assumes a key separation between 256 Zone Signing Key (ZSK) and Key Signing Key (KSK) as per [RFC4641]. 257 Where a zone maintainer decides to use only a single key [RFC6781] 258 the process layout will remain the same, details of differences to 259 be explored in a future update of this draft. 261 no ZSK/KSK rollover in progress Since no private keys will change 262 hands, the operator change implies a key rollover from the losing 263 to the gaining operator. A progressing rollover of the ZSK or KSK 264 at the losing DNS operator would add complexity due to more 265 possible validation paths. While both a rollover and a DNS 266 operator change can be combined, we will, for the sake of 267 simplicty, assume they will not. How to implement this business 268 constraint is beyond the scope of this document. Since the DNS 269 zone at the gaining DNS operator will be set up from scratch, it 270 is assumed there is no rollover in progress, either. 272 resolver does not indefinitely prolongate retention of cached data 273 Some resolvers are known to refresh the TTL of an NS RRSet of a 274 zone upon every authoritative response they receive that carries 275 this NS RRSet in the authority section. This is partly in the 276 spirit of [RFC2181] in that this source (the authoritative child) 277 is more credible than the NS RRSet in a referral, but independent 278 of DNSSEC this behaviour leads to an undesired side effect. These 279 'sticky' resolvers will never learn of a redelegation if that 280 happens by switching between two non-overlapping sets of name 281 servers, which is current practice in many environments. 282 Therefore the process for operator change does not have to take 283 this behaviour into account but may assume benign resolver 284 operation. 286 3. Executing the Change 288 The challenge to face is that during the DNS operator change 289 resolvers may see an NS RRSet pointing to either the losing or the 290 gaining operator's name servers. They may also have cached DNS data 291 and corresponding signatures from either source and this may in 292 particular mean that the apex DNSKEY RRSet and its signature or 293 signatures have a different origin than some other to-be-validated 294 RRSet. 296 To prevent validation failures, resolvers need, through careful 297 timing, be given the chance to acquire the necessary DNSKEY data that 298 allows them to validate signed DNS data from either source. 299 Therefore the DNSKEY RRSets originating from either infrastructure or 300 a limited time window need to have a non zero intersection set that 301 will be covered by both the old an the new trust anchor (or KSK). 303 Changing the DNS operator will be a three step process involving both 304 the gaining and the losing DNS operator. For the sake of simplicity, 305 the first case will not cover a registrar change. 307 3.1. Changing DNS operator only 309 At the beginning, there is a delegation to the losing operator's name 310 servers and a DS RR pointing to a KSK controlled by that losing 311 registrar in the parent zone. As a first step, the gaining operator 312 will obtain through the DNS the ZSK(!) from the losing operator's 313 version of the zone, validate it using the publicly available DNS 314 information, add it to its apex DNSKEY RRSet and re-sign that RRSet. 315 At this point, the new infrastructure will not yet be queried, but it 316 would provide a validation path through the new KSK for signatures 317 generated with either the new or old ZSK. To achieve symmetry, the 318 new ZSK needs to be incorporated into the old apex DNSKEY RRSet. 319 Since a (trusted, validatable) path to that information is not 320 available in the DNS, yet and no direct communication path between 321 the losing and the gaining operator is assumed, the registry will act 322 as a dropbox. Again, for the sake of simplicity, we assume that the 323 registry accepts key material in the form DNSKEY rather than DS 324 resource records. 326 | | | 327 | +--------+ | +--------+ | +--------+ 328 | Secure | Add | | | Change | | | Delete | 329 | +------->| new DS |-|->| NS |-|->| old DS | 330 +----------+ | | +--------+ | +--------+ | +--------+ 331 | Keyrelay | | | | | 332 | (relay |-|->-+ | | 333 | new ZSK) | | | | 334 +----------+ | | | 335 | | | 336 (1) | (2) | (3) | (4) 338 (1): Gaining operator configures zone with old ZSK included and 339 signs 340 (2): Loosing operator recieves new ZSK, includes ZSK in zone and 341 resigns 342 (3): Wait max TTL old DNSKEY RRset after seeing new ZSK in old 343 zone and DS TTL 344 (4): Wait TTL NS RRset old zone after NS change 346 Figure: Changing DNS operator only 348 The first change to the registration data, to be initiated by the 349 gaining operator will add the new KSK to the domain object to be 350 added to the parent zone as DS. This way, the parent zone can 351 publish two (or more) DS RRs, one for either KSK. At the same time, 352 the registry can make the new ZSK available to the losing operator. 353 No change is initiated yet to the parent zone NS RRSet. 355 Upon appearance of the gaining operator's ZSK in the registry's 356 communication channel to the losing operator, he is supposed to copy 357 this ZSK into its version of the apex DNSKEY RRSet and to re-sign the 358 DNSKEY RRSet with the old KSK. 360 Once that has happened and the TTL value of the (previous, sans new 361 ZSK) DNSKEY RRSet has passed, all resolver caches will either have no 362 DNSKEY RRSet for this zone or they will have acquired one that has a 363 signature made by the old KSK over both the old and the new ZSK. The 364 second precondition for the next step is that no DS RRSets exist 365 without reference to the new KSK that was inserted in the previous, 366 first step. This will be the case after the new DS RRSet will have 367 been visible in the DNS and the TTL of the DS RRSet (actually, that 368 of the previous instance of that DS RRSet) will have expired. Both 369 expiration intervals may and likely will overlap, but may start at 370 different times and are otherwise independent. The termination of 371 the later of the two will determine the earliest point in time for 372 progress. 374 The gaining operator can now initiate the second step, changing the 375 NS RRSet in the parent to the new name server infrastructure. Note 376 that a hard delegation change rather than a multi-step phase-in is 377 part of the design to reflect today's operational practice. 379 After this second step, the parent zone will contain an NS RRSet 380 delegating to the gaining operator's name servers as well as two DS 381 records, one referring to the old KSK, the other referring to the new 382 KSK. Due to the two DS RRs, either DNSKEY RRSet can be validated. 383 Either path will provide validation for both the old and the new ZSK. 384 That enables RRSIG validation on all DNS data independent of its 385 origin at the losing or gaining operator's version of the zone. 387 The final third step can be started after all instances of DNSKEY 388 RRSets containing the old KSK have expired. This also requires that 389 no queries are directed to the name servers of the losing operator. 390 The latter can be assumed after the TTL of the (old) NS RRSet at the 391 parent has passed (no delegations to old infrastructure) and 392 subsequently the TTL of the NS RRSet at the losing operator's zone 393 has also passed (no refresh or overwrite of referral data by 394 authoritative data from the child zone). Since a DNSKEY RRSet might 395 have been sent as part of a DNS response just before this expiry, 396 this DNSKEY RRSet's (originating from the losing operator, containing 397 old KSK and new ZSK) TTL must pass, too. In total, counting from the 398 appearance of the new NS RRSet in the parent zone, the sum of the TTL 399 of the NS RRSet at the parent, the TTL of the NS RRSet at the child 400 (losing operator) and the TTL of the DNSKEY RR at the losing operator 401 determines the earliest point in time for proceeding with the next 402 step. 404 The third step will be removing the old KSK from the domain object as 405 part of the KSK rollover. The parent zone will then publish a single 406 DS RR pointing to the new KSK only. As soon as the new DS RRSet will 407 be the only one present in caches, the losing operator may cease to 408 serve the zone. The gaining operator, in turn, can remove the old 409 ZSK from its apex DNSKEY RRSet, not without re-signing this RRSet 410 afterwards. 412 3.2. Changing DNS operator and registrar 414 Should the DNS operator change involve a registrar change the 415 procedure described in the previous paragraph can be followed with 416 one minor change. The first step, adding the new KSK to be added as 417 DS in the parent zone , will be immediately preceded by a transfer 418 initiated by the gaining registrar. After the transfer step will 419 have been executed, the gaining registrar will be the sponsoring 420 entity for a domain object that continues to refer to the losing 421 operator's infrastructure and therefore probably also the losing 422 registrar's data untill the the other steps in the procedure have 423 completed. 425 | | | 426 | +--------+ | +--------+ | +--------+ 427 | Secure | Add | | | Change | | | Delete | 428 | +----->| new DS |-|->| NS |-|->| old DS | 429 +----------+ | | +--------+ | +--------+ | +--------+ 430 | Keyrelay | | +----------+ | | 431 | (relay |-|->| Transfer | | | 432 | new ZSK) | | +----------+ | | 433 +----------+ | | | 434 | | | 435 (1) | (2) | (3) | (4) 437 (1): Gaining operator configures zone with old ZSK included and 438 signs 439 (2): Loosing operator recieves new ZSK, includes ZSK in zone and 440 resigns 441 (3): Wait max TTL old DNSKEY RRset after seeing new ZSK in old 442 zone and DS TTL 443 (4): Wait TTL NS RRset old zone after NS change 445 Figure: Changing DNS operator and registrar 447 3.3. Losing operator not participating 449 The procedure described in the previous sections depends upon the 450 losing DNS operator's participation to incorporate the new ZSK into 451 their DNSKEY RRSet. Should the losing operator not participate, 452 reasons for this being beyond the scope of this document, the gaining 453 operator can notice this after waiting a reasonable amount of time 454 after executing the first step. 456 The only known working way to avoid validation failures in this case 457 is to declare the zone insecure by removing the DS RR from the parent 458 zone. Some timing considerations are still due. After the parent 459 has stopped publishing the DS RRSet, and at least one DS TTL has 460 passed, the registered NS RRSet can be changed from the losing 461 operator's to the gaining operator's infrastructure. The gaining 462 operator's key material can be registered in a second step only after 463 the maximum of the TTL values of the parent's and the (losing 464 operator's) child's NS RRSet has passed, again counting from the 465 appearance of the NS RRSet in the parent zone. At this point, the 466 zone's security status is back to "secure". When an attempt has been 467 made to have the losing operator cooperate by including the old ZSK 468 in the new zone's DNSKEY RRset, this ZSK can be removed from the zone 469 one DS TTL after the old DS has been removed from the parent zone. 471 | | | 472 +----------+ | | | 473 | Keyrelay | | +----------+ | | 474 | (relay |-|->| Transfer | | | 475 | new ZSK) | | +----------+ | | 476 +----------+ | | +--------+ | +--------+ | +--------+ 477 | +------>| Delete |-|->| Change |-|->| Add | 478 | Insecure | old DS | | | NS | | | new DS | 479 | +--------+ | +--------+ | +--------+ 480 | | | 481 (1) | (2) | (3) | (4) 483 (1): Gaining operator configures zone with old ZSK included and 484 signs 485 (2): Loosing operator is uncooperative 486 (3): Wait TTL DS RRset parent zone 487 (4): Wait TTL NS RRset old zone after NS change 489 Figure: Loosing operator uncooperative, going insecure 491 4. Security Considerations 493 Since the procedure described in this document is incompatible with a 494 DNSKEY algorithm rollover during the operator change, it may 495 encourage the use of the same algorithm across all operators 496 involved. This could essentially limit the algorithm agility from an 497 operational perspective. Concerted action might be advised should 498 that preferred algorithm no longer be appropriate. 500 Preferring insecure state over validation failure is a judgement that 501 should be revisited, especially in the light of emerging application 502 protocols that will ignore unsigned or unvalidated DNS data. 504 As with a regular ZSK key rollover there is an odd chance that RRSets 505 with larger TTL values than the DNSKEY and NS RRSets, which dominate 506 the timing considerations, stay in a validator's cache. Any attempt 507 to revalidate these would lead to validation failures due to the 508 unavailability of the old ZSK. 510 5. IANA Considerations 512 This document does not request any IANA action. 514 6. Acknowledgements 516 The review, comments, and contributions by James Galvin and Paul 517 Wouters are much appreciated. Special thanks go to the authors and 518 contributors of [RFC4641] and [RFC6781] for detailed work on key 519 rollovers. 521 7. References 523 7.1. Normative References 525 [RFC2606] Eastlake, D.E. and A. Panitz, "Reserved Top Level DNS 526 Names", BCP 32, RFC 2606, June 1999. 528 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 529 Rose, "DNS Security Introduction and Requirements", RFC 530 4033, March 2005. 532 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 533 RFC 4641, September 2006. 535 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 536 RFC 5735, January 2010. 538 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 539 Operational Practices, Version 2", RFC 6781, December 540 2012. 542 7.2. Informative References 544 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 545 STD 13, RFC 1034, November 1987. 547 [RFC1035] Mockapetris, P., "Domain names - implementation and 548 specification", STD 13, RFC 1035, November 1987. 550 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 551 Specification", RFC 2181, July 1997. 553 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 554 Rose, "Resource Records for the DNS Security Extensions", 555 RFC 4034, March 2005. 557 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 558 Rose, "Protocol Modifications for the DNS Security 559 Extensions", RFC 4035, March 2005. 561 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 562 STD 69, RFC 5730, August 2009. 564 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 565 Domain Name Mapping", STD 69, RFC 5731, August 2009. 567 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 568 Security Extensions Mapping for the Extensible 569 Provisioning Protocol (EPP)", RFC 5910, May 2010. 571 Appendix A. Document Revision History 573 [This section should be removed by the RFC editor before publishing] 575 A.1. -00 577 1. Initial document. 579 A.2. -01 581 Expanded on the assumptions and requirements. 583 Added initial version of the process description. 585 A.3. -02 587 Split requirements and assumptions. 589 Declared sticky resolvers a non-issue. 591 Increased level of detail of discussion of TTL expiration between 592 updates. 594 Added early security considerations. 596 A.4. -03 598 Removed redundant requirement. 600 Reclassified 'sticky' resolver issue to assumption. 602 Explictly assume secure path between registrar and registry. 604 Clarified rollover in progress. 606 A.5. -04 608 Clarified operational practice in the introduction. 610 Added timing considerations for going through insecure. 612 Elaborated on combined transfer and operator change. 614 Expanded security considerations section. 616 Elevated 4033, 4641, and 4641bis to normative references; relaxed 617 1034, 1035, and 2181 to informative. 619 A.6. -05 621 Added 6781 as normative reference 623 Updated authors 625 A.7. -06 627 Change reference in text from 4146bis to 6781 629 Added ascii art 631 Replaced communication of ZSK from entry in registration DB to 632 generic communication channel 634 Added text to 3.3 to remove old ZSK from new zone 636 Authors' Addresses 637 Peter Koch 638 DENIC eG 639 Kaiserstrasse 75-77 640 Frankfurt 60329 641 DE 643 Phone: +49 69 27235 0 644 Email: pk@DENIC.DE 646 Marcos Sanz 647 DENIC eG 648 Kaiserstrasse 75-77 649 Frankfurt 60329 650 DE 652 Phone: +49 69 27235 0 653 Email: sanz@DENIC.DE 655 Antoin Verschuren 656 SIDN Labs 657 Meander 501 658 Arnhem 6825 MD 659 NL 661 Email: antoin.verschuren@sidn.nl 662 URI: https://www.sidn.nl/