idnits 2.17.1 draft-koch-dnsop-dnssec-operator-change-01.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 120 has weird spacing: '...perator provi...' == Line 125 has weird spacing: '...perator is th...' == Line 128 has weird spacing: '...perator denot...' -- The document date (March 14, 2011) is 4764 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC5910' is defined on line 392, 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: September 15, 2011 March 14, 2011 7 Changing DNS Operators for DNSSEC signed Zones 8 draft-koch-dnsop-dnssec-operator-change-01 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 September 15, 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 for Seamless Operator Change . . . . . . 4 56 3. Executing the Change . . . . . . . . . . . . . . . . . 6 57 3.1. Changing DNS operator only . . . . . . . . . . . . . . 7 58 3.2. Changing DNS operator and registrar . . . . . . . . . 8 59 3.3. Losing operator not participating . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . 8 62 6. References . . . . . . . . . . . . . . . . . . . . . . 9 63 6.1. Normative References . . . . . . . . . . . . . . . . . 9 64 6.2. Informative References . . . . . . . . . . . . . . . . 9 65 Appendix A. Document Revision History . . . . . . . . . . . . . . 10 66 A.1. Changes between -00 and -01 . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 When the NS RRSet in a DNS delegation is to be changed from one to a 72 disjoint other, the conservative approach has been to add the new 73 servers as (stealth) secondary servers, then add them to the NS 74 RRSet, change the primary master (that is, change the AXFR/IXFR 75 source for all the secondary servers), remove the old name servers' 76 names from the NS RRSet and finally cease service on those former 77 name servers. This would involve two changes to the zone file for 78 the apex NS RRSet and in turn two interactions with the parent zone 79 (the registry) for the delegation NS RRSet. 81 Operational practice deviates from this in many cases, especially 82 where there is a combined role of the registrar as registrar, DNS 83 operator and web hoster. Often the new infrastructure is set up 84 independent of and in parallel to the old one and there is only one 85 delegation change. Resolvers will access either version of the DNS 86 zone and the inconsistency in DNS data and even at the application 87 layer will be tolerated as long as the end user gets to see any 88 result at all. 90 DNSSEC is less tolerant to this inconsistency, and the challenge is 91 that access to and validation of DNS data will involve multiple 92 steps. The resolver might access DNS data through one (say, the old) 93 name server infrastructure and DNS key material (the apex DNSKEY 94 RRSet) through the other. A hard switch would increase the 95 likelyhood of a validation failure, should the signature over some 96 RRSet not match any key in the DNSKEY RRSet. 98 1.1. Purpose of this Document 100 This document attempts to list requirements for a seamless change of 101 DNS operators in a registry/registrar environment. It then suggests 102 a procedure that should work in an automated environment even for 103 large numbers of DNS operator changes. It is meant as a supplement 104 or contribution to the updated version of [RFC4641], as currently 105 expressed in [I-D.ietf-dnsop-rfc4641bis], section 4.3.5. 107 1.2. Terminology 109 The change of DNS infrastructure involves multiple parties. We are 110 using the following terms throughout the document. 112 registrar The entity that can change entries in a DNS registry 113 database, usually, but not restricted to, by means of a realtime 114 provisioning protocol like EPP [RFC5730]. NB: the procedure 115 described in this document does not require a strict registry- 116 registrar-registrant separation. Where the registrant can 117 directly interact with the registry they are considered filling 118 the registrar role. 120 DNS operator provides the DNS infrastructure for a given DNS zone 121 (delegated domain). This party may or may not be identical to the 122 registrant or the registrar. The details of provisioning the DNS 123 data into the DNS zone are beyond the scope of this document. 125 losing DNS operator is the party that controls zone content and DNS 126 infrastructure at the beginning of a DNS operator change. 128 gaining DNS operator denotes the party that will control zone 129 content and DNS infrastructure after the successful DNS operator 130 change. 132 Domain names and IP addresses herein are for explanatory purposes 133 only and should not be expected to lead to useful information in real 134 life [RFC2606],[RFC5735]). 136 This document assumes a key separation between Zone Signing Key (ZSK) 137 and Key Signing Key (KSK) as per [RFC4641]. Where a zone maintainer 138 decides to use only a single key [I-D.ietf-dnsop-rfc4641bis] the 139 process layout will remain the same, details of differences to be 140 explored in a future update of this draft. 142 2. Requirements for Seamless Operator Change 144 Regardless of the the particular registry provisioning protocol 145 (e.g., EPP, [RFC5730], [RFC5731]) DNS registries usually provide for 146 a method to transfer a domain name between different registrars. 147 However, from this angle there is no separate role for the DNS 148 operator, the entity that is responsible for the DNS infrastructure 149 and/or the content of the DNS zone. This entity may be identical to 150 the registrar, the registrant, or neither. From the DNSSEC 151 perspective it is important to consider the entity controlling the 152 ZSK and KSK in any transfer that involves changing the NS RRSet to a 153 disjoint set (as opposed to simple additions to or removals from the 154 NS RRSet). 156 The change of a registrar is of limited effect from the DNSSEC 157 perspective. The discussion of the ability of the gaining registrar 158 to accept DNSSEC information within a domain object is beyond the 159 scope of this document. The focus is kept on the change of the DNS 160 operator. There are two cases: ideally, the losing operator will be 161 able to incorporate data generated by the gaining operator into their 162 version of the DNS zone. However, the proposed solution should also 163 be able to cover the case where this cooperation cannot be relied 164 upon. 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 incorporation of foreign DNSKEY RRs To achieve a symmetric 183 validation chain along the DS/KSK/ZSK of both the losing and the 184 gaining DNS operator it is assumed that either operator can, 185 technically, incorporate DNSKEY RRs into their apex DNSKEY RRSet. 186 This includes the ability to subsequently properly sign the DNSKEY 187 RRSet. 189 no use of foreign RRSIG information The process of signing a zone is 190 usually done in one of three ways: The zone is signed completely 191 as a file, then loaded into a name server, the signer is a "bump 192 in the wire" solution or the name server combines signing and 193 serving on the primary master. Adding foreign signatures into a 194 zone is not easily achieved in any of these setups, so it ought to 195 be avoided. It also helps contain the effect of changes to an 196 RRSet locally, as no signatures have to be generated remotely with 197 subsequent re-import. 199 no direct communication channel We do not assume the existence of a 200 direct, confidential, authenticated communication channel between 201 the losing and the gaining operator. On an abstract level, the 202 registrant could be viewed as an indirect channel, but involving 203 the registrant is not necessarily easily automated. 205 little interaction To ease automation the number of interactions 206 between registry, registrar or registrars and operators should be 207 minimized. 209 little overhead for losing operator Whenever interaction or action 210 cannot be avoided, the losing operator should be involved as 211 little as possible to avoid overhead for the leaving customer. In 212 turn, this suggests the gaining operator should be in control of 213 the process. 215 no algorithm rollover Current reading is that an algorithm rollover 216 requires a full validation with all algorithms involved, whereas a 217 key rollover will work whenever data can be validated using either 218 key ([RFC4035], section 2.2). Therefore, it is assumed that both 219 operators utilize the same DNSSEC key algorithm during the 220 transfer. This does neither preclude the use of diffrent key 221 sizes nor the change of key algorithms after the DNS operator 222 change. 224 no ZSK/KSK rollover in progress An active rollover of the ZSK or KSK 225 at the losing DNS operator would add complexity due to more 226 possible validation paths. While both a rollover and a DNS 227 operator change can be combined, we will, for the sake of 228 simplicty, assume they will not. How to implement this business 229 constraint is beyond the scope of this document. Since the DNS 230 zone at the gaining DNS operator will be set up from scratch, it 231 is assumed there is no rollover in progress, either. 233 3. Executing the Change 235 The challenge to face is that during the DNS operator change 236 resolvers may see an NS RRSet pointing to either the losing or the 237 gaining operator's name servers. They may also have cached DNS data 238 and corresponding signatures from either source and this may in 239 particular mean that the apex DNSKEY RRSet and its signature or 240 signatures have a different origin than some other to-be-validated 241 RRSet. 243 To prevent validation failures, resolvers need, through careful 244 timing, be given the chance to acquire the necessary DNSKEY data that 245 allows them to validate signed DNS data from either source. 246 Therefore the DNSKEY RRSets originating from either infrastructure or 247 a limited time window need to have a non zero intersection set that 248 will be covered by both the old an the new trust anchor (or KSK). 250 Changing the DNS operator will be a three step process involving both 251 the gaining and the losing DNS operator. For the sake of simplicity, 252 the first case will not cover a registrar change. 254 3.1. Changing DNS operator only 256 At the beginning, there is a delegation to the losing operator's name 257 servers and a DS RR pointing to a KSK controlled by that losing 258 registrar in the parent zone. As a first step, the gaining operator 259 will obtain through the DNS the ZSK(!) from the losing operator's 260 version of the zone, validate it using the publicly available DNS 261 information, add it to its apex DNSKEY RRSet and re-sign that RRSet. 262 At this point, the new infrastructure will not yet be queried, but it 263 would provide a validation path through the new KSK for signatures 264 generated with the old ZSK. To achieve symmetry, the new ZSK needs 265 to be incorporated into the old apex DNSKEY RRSet. Since a (trusted, 266 validatable) path to that information is not available in the DNS, 267 yet and no direct communication path between the losing and the 268 gaining operator is assumed, the registry will act as a dropbox. 269 Again, for the sake of simplicity, we assume that the registry 270 accepts key material in the form DNSKEY rather than DS resource 271 records. 273 The first change to the registration data, to be initiated by the 274 gaining operator will add the new KSK and the new ZSK to the domain 275 object. This way, the parent zone can publish two (or three, taking 276 into account the ZSK) DS RRs, one for either KSK. At the same time, 277 the registry can make available the new ZSK to the losing operator. 278 No change is initiated yet to the parent zone NS RRSet. 280 Upon appearance of the gaining operator's ZSK in the registry 281 database the losing operator is supposed to copy this ZSK into its 282 version of the apex DNSKEY RRSet and to re-sign the DNSKEY RRSet with 283 the old KSK. Once that has happened and the TTL value of the DNSKEY 284 RRSet has passed, all resolver caches will either have no DNSKEY 285 RRSet for this zone or they will have acquired one that has a 286 signature made by the old KSK over both the old and the new ZSK. 288 The gaining operator can now initiate the second step, changing the 289 NS RRSet in the parent to the new name server infrastructure. At the 290 same time, the ZSK can be removed from the domain object since the 291 registry has fulfilled its role as a ZSK dropbox. Note that a hard 292 delegation change rather than a multi-step phase-in is part of the 293 design to reflect today's operational practice. 295 After this second step, the parent zone will contain an NS RRSet 296 delegating to the gaining operator's name servers as well as two DS 297 records, one referring to the old KSK, the other referring to the new 298 KSK. Due to the two DS RRs, either DNSKEY RRSet can be validated. 299 Either path will provide validation for both the old and the new ZSK. 300 That enables RRSIG validation on all DNS data independent of its 301 origin at the losing or gaining operator's version of the zone. 303 The final third step can be started after all NS RRSet instances 304 delegating to the losing operator's name servers have expired, which 305 is supposed to happen after the maximum of the parent and child NS 306 RRSets' TTL values plus the expiration of al DNSKEY RRSets obtained 307 from the losing operator's infrastructure. (We will ignore resolvers 308 with a "sticky" behaviour that do prolong a child NS RRSet's lifetime 309 indefinitely, because this is causing issues even without DNSSEC.) 311 The third step will be removing the old KSK from the domain object as 312 part of the KSK rollover. The parent zone will then publish a single 313 DS RR pointin to the new KSK only. As soon as the new DS RRSet will 314 be the only one present in caches, the losing operator may cease to 315 serve the zone. The gaining operator, in turn, can remove the old 316 ZSK from its apex DNSKEY RRSet, not without re-signing this RRSet 317 afterwards. 319 3.2. Changing DNS operator and registrar 321 Should the DNS operator change involve a registrar change the 322 procedure described in the previous paragraph can be followed with 323 one minor change. The first step, adding the new KSK and the new 324 ZSK, will be combined with a transfer initiated by the gaining 325 registrar. 327 3.3. Losing operator not participating 329 The procedure described in the previous sections depends upon the 330 losing DNS operator's participation to incorporate the new ZSK into 331 their DNSKEY RRSet. Should the losing operator not participate, 332 reasons for this being beyond the scope of this document, the gaining 333 operator can notice this after waiting a reasonable amount of time 334 after executing the first step. 336 The only known working way to avoid validation failures in this case 337 is to declare the zone insecure by removing the DS RR from the parent 338 zone. [details TBD] 340 4. Security Considerations 342 This section needs more work 344 5. IANA Considerations 346 This document does not request any IANA action. 348 6. References 350 6.1. Normative References 352 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 353 STD 13, RFC 1034, November 1987. 355 [RFC1035] Mockapetris, P., "Domain names - implementation and 356 specification", STD 13, RFC 1035, November 1987. 358 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 359 Names", BCP 32, RFC 2606, June 1999. 361 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 362 BCP 153, RFC 5735, January 2010. 364 6.2. Informative References 366 [I-D.ietf-dnsop-rfc4641bis] 367 Kolkman, O., "DNSSEC Operational Practices, Version 2", 368 draft-ietf-dnsop-rfc4641bis-05 (work in progress), 369 October 2010. 371 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 372 Rose, "DNS Security Introduction and Requirements", 373 RFC 4033, March 2005. 375 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 376 Rose, "Resource Records for the DNS Security Extensions", 377 RFC 4034, March 2005. 379 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 380 Rose, "Protocol Modifications for the DNS Security 381 Extensions", RFC 4035, March 2005. 383 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 384 RFC 4641, September 2006. 386 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 387 STD 69, RFC 5730, August 2009. 389 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 390 Domain Name Mapping", STD 69, RFC 5731, August 2009. 392 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 393 Security Extensions Mapping for the Extensible 394 Provisioning Protocol (EPP)", RFC 5910, May 2010. 396 Appendix A. Document Revision History 398 This section is to be removed should the draft be published. 399 $Id: draft-koch-dnsop-dnssec-operator-change.xml,v 1.3 2011/03/14 22:05:16 pk Exp $ 401 A.1. Changes between -00 and -01 403 Expanded on the assumptions and requirements. 405 Added initial version of the process description. 407 Authors' Addresses 409 Peter Koch 410 DENIC eG 411 Kaiserstrasse 75-77 412 Frankfurt 60329 413 DE 415 Phone: +49 69 27235 0 416 Email: pk@DENIC.DE 418 Marcos Sanz 419 DENIC eG 420 Kaiserstrasse 75-77 421 Frankfurt 60329 422 DE 424 Phone: +49 69 27235 0 425 Email: sanz@DENIC.DE