idnits 2.17.1 draft-koch-dnsop-dnssec-operator-change-02.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 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 124 has weird spacing: '...perator provi...' == Line 129 has weird spacing: '...perator is th...' == Line 132 has weird spacing: '...perator denot...' -- The document date (May 3, 2011) is 4741 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC5910' is defined on line 461, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-13) exists of draft-ietf-dnsop-rfc4641bis-05 -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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: Informational DENIC eG 5 Expires: November 4, 2011 May 3, 2011 7 Changing DNS Operators for DNSSEC signed Zones 8 draft-koch-dnsop-dnssec-operator-change-02 10 Abstract 12 Changing the DNS delegation for a DNS zone is quite involved if done 13 by the books, but most often handled pragmatically in today's 14 operational practice at the top level with registries and registrars. 15 This document describes a proposal for a delegation change procedure 16 that will maintain consistency and validation under DNSSEC. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 4, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Purpose of this Document . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements and Assumptions for Seamless Operator 56 Change . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Requirements for Seamless Operator Change . . . . . . 4 58 2.2. Assumptions for Seamless Operator Change . . . . . . . 6 59 3. Executing the Change . . . . . . . . . . . . . . . . . 7 60 3.1. Changing DNS operator only . . . . . . . . . . . . . . 7 61 3.2. Changing DNS operator and registrar . . . . . . . . . 9 62 3.3. Losing operator not participating . . . . . . . . . . 9 63 4. Security Considerations . . . . . . . . . . . . . . . 9 64 5. IANA Considerations . . . . . . . . . . . . . . . . . 10 65 6. References . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. Normative References . . . . . . . . . . . . . . . . . 10 67 6.2. Informative References . . . . . . . . . . . . . . . . 10 68 Appendix A. Document Revision History . . . . . . . . . . . . . . 11 69 A.1. Changes between -01 and -02 . . . . . . . . . . . . . 11 70 A.2. Changes between -00 and -01 . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 When the NS RRSet in a DNS delegation is to be changed from one to a 76 disjoint other, the conservative approach has been to add the new 77 servers as (stealth) secondary servers, then add them to the NS 78 RRSet, change the primary master (that is, change the AXFR/IXFR 79 source for all the secondary servers), remove the old name servers' 80 names from the NS RRSet and finally cease service on those former 81 name servers. This would involve two changes to the zone file for 82 the apex NS RRSet and in turn two interactions with the parent zone 83 (the registry) for the delegation NS RRSet. 85 Operational practice deviates from this in many cases, especially 86 where there is a combined role of the registrar as registrar, DNS 87 operator and web hoster. Often the new infrastructure is set up 88 independent of and in parallel to the old one and there is only one 89 delegation change. Resolvers will access either version of the DNS 90 zone and the inconsistency in DNS data and even at the application 91 layer will be tolerated as long as the end user gets to see any 92 result at all. 94 DNSSEC is less tolerant to this inconsistency, and the challenge is 95 that access to and validation of DNS data will involve multiple 96 steps. The resolver might access DNS data through one (say, the old) 97 name server infrastructure and DNS key material (the apex DNSKEY 98 RRSet) through the other. A hard switch would increase the 99 likelyhood of a validation failure, should the signature over some 100 RRSet not match any key in the DNSKEY RRSet. 102 1.1. Purpose of this Document 104 This document attempts to list requirements for a seamless change of 105 DNS operators in a registry/registrar environment. It then suggests 106 a procedure that should work in an automated environment even for 107 large numbers of DNS operator changes. It is meant as a supplement 108 or contribution to the updated version of [RFC4641], as currently 109 expressed in [I-D.ietf-dnsop-rfc4641bis], section 4.3.5. 111 1.2. Terminology 113 The change of DNS infrastructure involves multiple parties. We are 114 using the following terms throughout the document. 116 registrar The entity that can change entries in a DNS registry 117 database, usually, but not restricted to, by means of a realtime 118 provisioning protocol like EPP [RFC5730]. NB: the procedure 119 described in this document does not require a strict registry- 120 registrar-registrant separation. Where the registrant can 121 directly interact with the registry they are considered filling 122 the registrar role. 124 DNS operator provides the DNS infrastructure for a given DNS zone 125 (delegated domain). This party may or may not be identical to the 126 registrant or the registrar. The details of provisioning the DNS 127 data into the DNS zone are beyond the scope of this document. 129 losing DNS operator is the party that controls zone content and DNS 130 infrastructure at the beginning of a DNS operator change. 132 gaining DNS operator denotes the party that will control zone 133 content and DNS infrastructure after the successful DNS operator 134 change. 136 Domain names and IP addresses herein are for explanatory purposes 137 only and should not be expected to lead to useful information in real 138 life [RFC2606],[RFC5735]). 140 2. Requirements and Assumptions for Seamless Operator Change 142 Regardless of the the particular registry provisioning protocol 143 (e.g., EPP, [RFC5730], [RFC5731]) DNS registries usually provide for 144 a method to transfer a domain name between different registrars. 145 However, from this angle there is no separate role for the DNS 146 operator, the entity that is responsible for the DNS infrastructure 147 and/or the content of the DNS zone. This entity may be identical to 148 the registrar, the registrant, or neither. From the DNSSEC 149 perspective it is important to consider the entity controlling the 150 ZSK and KSK in any transfer that involves changing the NS RRSet to a 151 disjoint set (as opposed to simple additions to or removals from the 152 NS RRSet). 154 The change of a registrar is of limited effect from the DNSSEC 155 perspective. The discussion of the ability of the gaining registrar 156 to accept DNSSEC information within a domain object is beyond the 157 scope of this document. The focus is kept on the change of the DNS 158 operator. There are two cases: ideally, the losing operator will be 159 able to incorporate data generated by the gaining operator into their 160 version of the DNS zone. However, the proposed solution should also 161 be able to cover the case where this cooperation cannot be relied 162 upon. 164 2.1. Requirements for Seamless Operator Change 166 This is a preliminary list of requirements for the operator change: 168 no validation failures During the operator change, as in normal 169 operations, DNSSEC validation failures, resulting from unavailable 170 or outdated key or signature material, must be avoided. 172 validation failures worse than insecure Where there is the choice 173 between DNSSEC validation failures and an insecure state, the 174 latter is to be preferred, although its extent still ought to be 175 kept to a necessary minimum. 177 no private keys Private cryptographic keys will not be exchanged 178 between the losing and the gaining operator. Scenarios in which 179 this would be feasible would not pose the challenges addressed in 180 this document. 182 no use of foreign RRSIG information The process of signing a zone is 183 usually done in one of three ways: The zone is signed completely 184 as a file, then loaded into a name server, the signer is a "bump 185 in the wire" solution or the name server combines signing and 186 serving on the primary master. Adding foreign signatures into a 187 zone is not easily achieved in any of these setups, so it ought to 188 be avoided. It also helps contain the effect of changes to an 189 RRSet locally, as no signatures have to be generated remotely with 190 subsequent re-import. 192 little interaction To ease automation the number of interactions 193 between registry, registrar or registrars and operators should be 194 minimized. 196 little overhead for losing operator Whenever interaction or action 197 cannot be avoided, the losing operator should be involved as 198 little as possible to avoid overhead for the leaving customer. In 199 turn, this suggests the gaining operator should be in control of 200 the process. 202 no added non-DNSSEC complexity The process of operator change, 203 ignoring the DNSSEC components, should not be more involved or 204 more complex than today's operational practice for operator 205 changes. 207 no workarounds for problematic resolver behaviour Some resolvers are 208 known to refresh the TTL of an NS RRSet of a zone upon every 209 authoritative response they receive that carries the NS RRSet in 210 the authority section. This is partly in the spirit of [RFC2181] 211 in that this source (the authoritative child) is more credible 212 than the NS RRSet in a referral, but independent of DNSSEC this 213 behaviour leads to an undesired side effect. These 'sticky' 214 resolvers will never learn of a redelegation if that happens by 215 switching between two non-overlapping sets of name servers, which 216 is current practice in many environments. Therefore the process 217 for operator change does not have to take this behaviour into 218 account but may assume benign resolver operation. 220 2.2. Assumptions for Seamless Operator Change 222 This is a preliminary list of assumptions for the operator change: 224 no direct communication channel We do not assume the existence of a 225 direct, confidential, authenticated communication channel between 226 the losing and the gaining operator. On an abstract level, the 227 registrant could be viewed as an indirect channel, but involving 228 the registrant is not necessarily easily automated. 230 incorporation of foreign DNSKEY RRs To achieve a symmetric 231 validation chain along the DS/KSK/ZSK of both the losing and the 232 gaining DNS operator it is assumed that either operator can, 233 technically, incorporate DNSKEY RRs into their apex DNSKEY RRSet. 234 This includes the ability to subsequently properly sign the DNSKEY 235 RRSet. 237 ability to store and retrieve DNSKEY RRs We assume that registrars 238 are able to store in and retrieve from the registry DNSKEY RRs or 239 equivalent information. This can be achieved by the registry 240 using DNSKEY RRs as key material (as opposed to or in addition to 241 DS RRs) or by the ability to insert DNSKEY data in free text or 242 remarks fields within or associated with the domain object. 244 no algorithm rollover Current reading is that an algorithm rollover 245 requires a full validation with all algorithms involved, whereas a 246 key rollover will work whenever data can be validated using either 247 key ([RFC4035], section 2.2). Therefore, it is assumed that both 248 operators utilize the same DNSSEC key algorithm during the 249 transfer. This does neither preclude the use of different key 250 sizes nor the change of key algorithms after the DNS operator 251 change. 253 ZSK/KSK separation This document assumes a key separation between 254 Zone Signing Key (ZSK) and Key Signing Key (KSK) as per [RFC4641]. 255 Where a zone maintainer decides to use only a single key 256 [I-D.ietf-dnsop-rfc4641bis] the process layout will remain the 257 same, details of differences to be explored in a future update of 258 this draft. 260 no ZSK/KSK rollover in progress An active rollover of the ZSK or KSK 261 at the losing DNS operator would add complexity due to more 262 possible validation paths. While both a rollover and a DNS 263 operator change can be combined, we will, for the sake of 264 simplicty, assume they will not. How to implement this business 265 constraint is beyond the scope of this document. Since the DNS 266 zone at the gaining DNS operator will be set up from scratch, it 267 is assumed there is no rollover in progress, either. 269 3. Executing the Change 271 The challenge to face is that during the DNS operator change 272 resolvers may see an NS RRSet pointing to either the losing or the 273 gaining operator's name servers. They may also have cached DNS data 274 and corresponding signatures from either source and this may in 275 particular mean that the apex DNSKEY RRSet and its signature or 276 signatures have a different origin than some other to-be-validated 277 RRSet. 279 To prevent validation failures, resolvers need, through careful 280 timing, be given the chance to acquire the necessary DNSKEY data that 281 allows them to validate signed DNS data from either source. 282 Therefore the DNSKEY RRSets originating from either infrastructure or 283 a limited time window need to have a non zero intersection set that 284 will be covered by both the old an the new trust anchor (or KSK). 286 Changing the DNS operator will be a three step process involving both 287 the gaining and the losing DNS operator. For the sake of simplicity, 288 the first case will not cover a registrar change. 290 3.1. Changing DNS operator only 292 At the beginning, there is a delegation to the losing operator's name 293 servers and a DS RR pointing to a KSK controlled by that losing 294 registrar in the parent zone. As a first step, the gaining operator 295 will obtain through the DNS the ZSK(!) from the losing operator's 296 version of the zone, validate it using the publicly available DNS 297 information, add it to its apex DNSKEY RRSet and re-sign that RRSet. 298 At this point, the new infrastructure will not yet be queried, but it 299 would provide a validation path through the new KSK for signatures 300 generated with the old ZSK. To achieve symmetry, the new ZSK needs 301 to be incorporated into the old apex DNSKEY RRSet. Since a (trusted, 302 validatable) path to that information is not available in the DNS, 303 yet and no direct communication path between the losing and the 304 gaining operator is assumed, the registry will act as a dropbox. 305 Again, for the sake of simplicity, we assume that the registry 306 accepts key material in the form DNSKEY rather than DS resource 307 records. 309 The first change to the registration data, to be initiated by the 310 gaining operator will add the new KSK and the new ZSK to the domain 311 object. This way, the parent zone can publish two (or three, taking 312 into account the ZSK) DS RRs, one for either KSK. At the same time, 313 the registry can make available the new ZSK to the losing operator. 314 No change is initiated yet to the parent zone NS RRSet. 316 Upon appearance of the gaining operator's ZSK in the registry 317 database the losing operator is supposed to copy this ZSK into its 318 version of the apex DNSKEY RRSet and to re-sign the DNSKEY RRSet with 319 the old KSK. 321 Once that has happened and the TTL value of the (previous, sans new 322 ZSK) DNSKEY RRSet has passed, all resolver caches will either have no 323 DNSKEY RRSet for this zone or they will have acquired one that has a 324 signature made by the old KSK over both the old and the new ZSK. The 325 second precondition for the next step is that no DS RRSets exist 326 without reference to the new KSK that was inserted in the previous, 327 first step. This will be the case after the new DS RRSet will have 328 been visible in the DNS and the TTL of the DS RRSet (actually, that 329 of the previous instance of that DS RRSet) will have expired. Both 330 expiration intervals may and likely will overlap, but may start at 331 different times and are otherwise independent. The termination of 332 the later of the two will determine the earliest point in time for 333 progress. 335 The gaining operator can now initiate the second step, changing the 336 NS RRSet in the parent to the new name server infrastructure. At the 337 same time, the ZSK can be removed from the domain object since the 338 registry has fulfilled its role as a ZSK dropbox. Note that a hard 339 delegation change rather than a multi-step phase-in is part of the 340 design to reflect today's operational practice. 342 After this second step, the parent zone will contain an NS RRSet 343 delegating to the gaining operator's name servers as well as two DS 344 records, one referring to the old KSK, the other referring to the new 345 KSK. Due to the two DS RRs, either DNSKEY RRSet can be validated. 346 Either path will provide validation for both the old and the new ZSK. 347 That enables RRSIG validation on all DNS data independent of its 348 origin at the losing or gaining operator's version of the zone. 350 The final third step can be started after all instances of DNSKEY 351 RRSets containing the old KSK have expired. This also requires that 352 no queries are directed to the name servers of the losing operator. 353 The latter can be assumed after the TTL of the (old) NS RRSet at the 354 parent has passed (no delegations to old infrastructure) and 355 subsequently the TTL of the NS RRSet at the losing operator's zone 356 has also passed (no refresh or overwrite of referral data by 357 authoritative data from the child zone). Since a DNSKEY RRSet might 358 have been sent as part of a DNS response just before this expiry, 359 this DNSKEY RRSet's (originating from the losing operator, containing 360 old KSK and new ZSK) TTL must pass, too. In total, counting from the 361 appearance of the new NS RRSet in the parent zone, the sum of the TTL 362 of the NS RRSet at the parent, the TTL of the NS RRSet at the child 363 (losing operator) and the TTL of the DNSKEY RR at the losing operator 364 determines the earliest point in time for proceeding with the next 365 step. 367 The third step will be removing the old KSK from the domain object as 368 part of the KSK rollover. The parent zone will then publish a single 369 DS RR pointing to the new KSK only. As soon as the new DS RRSet will 370 be the only one present in caches, the losing operator may cease to 371 serve the zone. The gaining operator, in turn, can remove the old 372 ZSK from its apex DNSKEY RRSet, not without re-signing this RRSet 373 afterwards. 375 3.2. Changing DNS operator and registrar 377 Should the DNS operator change involve a registrar change the 378 procedure described in the previous paragraph can be followed with 379 one minor change. The first step, adding the new KSK and the new 380 ZSK, will be combined with a transfer initiated by the gaining 381 registrar. 383 3.3. Losing operator not participating 385 The procedure described in the previous sections depends upon the 386 losing DNS operator's participation to incorporate the new ZSK into 387 their DNSKEY RRSet. Should the losing operator not participate, 388 reasons for this being beyond the scope of this document, the gaining 389 operator can notice this after waiting a reasonable amount of time 390 after executing the first step. 392 The only known working way to avoid validation failures in this case 393 is to declare the zone insecure by removing the DS RR from the parent 394 zone. [details TBD] 396 4. Security Considerations 398 Since the procedure described in this document is incompatible with a 399 DNSKEY algorithm rollover during the operator change, it may 400 encourage the use of the same algorithm across all operators 401 involved. This could essentially limit the algorithm agility from an 402 operational perspective. Concerted action might be advised should 403 that preferred algorithm no longer be appropriate. 405 Preferring insecure state over validation failure is a judgement that 406 should be revisited. 408 [This section needs more work] 410 5. IANA Considerations 412 This document does not request any IANA action. 414 6. References 416 6.1. Normative References 418 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 419 STD 13, RFC 1034, November 1987. 421 [RFC1035] Mockapetris, P., "Domain names - implementation and 422 specification", STD 13, RFC 1035, November 1987. 424 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 425 Specification", RFC 2181, July 1997. 427 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 428 Names", BCP 32, RFC 2606, June 1999. 430 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 431 BCP 153, RFC 5735, January 2010. 433 6.2. Informative References 435 [I-D.ietf-dnsop-rfc4641bis] 436 Kolkman, O., "DNSSEC Operational Practices, Version 2", 437 draft-ietf-dnsop-rfc4641bis-05 (work in progress), 438 October 2010. 440 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 441 Rose, "DNS Security Introduction and Requirements", 442 RFC 4033, March 2005. 444 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 445 Rose, "Resource Records for the DNS Security Extensions", 446 RFC 4034, March 2005. 448 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 449 Rose, "Protocol Modifications for the DNS Security 450 Extensions", RFC 4035, March 2005. 452 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 453 RFC 4641, September 2006. 455 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 456 STD 69, RFC 5730, August 2009. 458 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 459 Domain Name Mapping", STD 69, RFC 5731, August 2009. 461 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 462 Security Extensions Mapping for the Extensible 463 Provisioning Protocol (EPP)", RFC 5910, May 2010. 465 Appendix A. Document Revision History 467 This section is to be removed should the draft be published. 468 $Id: draft-koch-dnsop-dnssec-operator-change.xml,v 1.5 2011/05/03 16:01:09 pk Exp $ 470 A.1. Changes between -01 and -02 472 Split requirements and assumptions. 474 Declared sticky resolvers a non-issue. 476 Increased level of detail of doscussion of TTL expiration between 477 updates. 479 Added early security considerations. 481 A.2. Changes between -00 and -01 483 Expanded on the assumptions and requirements. 485 Added initial version of the process description. 487 Authors' Addresses 489 Peter Koch 490 DENIC eG 491 Kaiserstrasse 75-77 492 Frankfurt 60329 493 DE 495 Phone: +49 69 27235 0 496 Email: pk@DENIC.DE 497 Marcos Sanz 498 DENIC eG 499 Kaiserstrasse 75-77 500 Frankfurt 60329 501 DE 503 Phone: +49 69 27235 0 504 Email: sanz@DENIC.DE