idnits 2.17.1 draft-koch-dnsop-dnssec-operator-change-00.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 -- The document date (March 7, 2011) is 4798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 161, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 164, but no explicit reference was found in the text == Unused Reference: 'RFC2606' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'RFC5735' is defined on line 170, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 180, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 184, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 188, 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 (~~), 9 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 8, 2011 March 7, 2011 7 Changing DNS Operators under DNSSEC 8 draft-koch-dnsop-dnssec-operator-change-00 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 8, 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 2. Requirements for Seamless Operator Change . . . . . . . 3 55 3. Security Considerations . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . 4 57 5. References . . . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Normative References . . . . . . . . . . . . . . . . . 5 59 5.2. Informative References . . . . . . . . . . . . . . . . 5 60 Appendix A. Document Revision History . . . . . . . . . . . . . . . 6 61 A.1. Initial document . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 When the NS RRSet in a DNS delegation is to be changed from one to a 67 disjoint other, the conservative approach has been to add the new 68 servers as (stealth) secondary servers, then add them to the NS 69 RRSet, change the primary master (that is, change the AXFR/IXFR 70 source for all the secondary servers), remove the old name servers' 71 names from the NS RRSet and finally cease service on those former 72 name servers. This would involve two changes to the zone file for 73 the apex NS RRSet and in turn two interactions with the parent zone 74 (the registry) for the delegation NS RRSet. 76 Operational practice deviates from this in many cases, especially 77 where there is a combined role of the registrar as registrar, DNS 78 operator and web hoster. Often the new infrastructure is set up 79 independent of and in parallel to the old one and there is only one 80 delegation change. Resolvers will access either version of the DNS 81 zone and the inconsistency in DNS data and even at the application 82 layer will be tolerated as long as the end user gets to see any 83 result at all. 85 DNSSEC is less tolerant to this inconsistency, and the challenge is 86 that access to and validation of DNS data will involvce multiple 87 steps. The resolver might access DNS data through one (say, the old) 88 name server infrastructure and DNS key material (the apex DNSKEY 89 RRSet) through the other. A hard switch would increase the 90 likelyhood of a validation failure, should the signature over some 91 RRSet not match any key in the DNSKEY RRset. 93 1.1. Purpose of this Document 95 This document attempts to list requirements for a seamless change of 96 DNS operators in a registry/registrar environment. It then suggests 97 a procedure that should work in an automated environment even for 98 large numbers of DNS operator changes. It is meant as a supplement 99 or contribution to the updated version of [RFC4641], as currently 100 expressed in [I-D.ietf-dnsop-rfc4641bis], section 4.3.5. 102 2. Requirements for Seamless Operator Change 104 Regardless of the the particular registry provisioning protocol 105 (e.g., EPP, [RFC5930], [RFC5931]) DNS registries usually provide for 106 a method to transfer a domain name between different registrars. 107 However, from this angle there is no separate role for the DNS 108 operator, the entity that is responsible for the DNS infrastructure 109 and/or the content of the DNS zone. This entity may be identical to 110 the registrar, the registrant, or neither. From the DNSSEC 111 perspective it is important to consider the entity controlling the 112 ZSK and KSK in any transfer that involves changing the NS RRSet to a 113 disjoint set (as opposed to simple additions to or removals from the 114 NS RRSet). 116 The change of a registrar is of limited effect from the DNSSEC 117 perspective. The discussion of the ability of the gaining registrar 118 to accept DNSSEC information within a domain object is beyond the 119 scope of this document. The focus is kept on the change of the DNS 120 operator. There are two cases: ideally, the losing operator will be 121 able to incorporate data generated by the gaining operator into their 122 version of the DNS zone. However, the proposed solution should also 123 be able to cover the case where this cooperation cannot be relied 124 upon. 126 This is a preliminary list of requirements for the operator change: 128 no private keys Private cryptographic keys will not be exchanged 129 between the losing and the gaining operator. Scenarios in which 130 this would be feasible would not pose the challenges addressed in 131 this document. 133 little interaction To ease automation the number of interactions 134 between registry, registrar or registrars and operators should be 135 minimized. 137 no direct channel We do not assume the existence of a direct, 138 confidential, authenticated communication channel between the 139 losing and the gaining operator. On an abstract level, the 140 registrant could be viewed as an indirect channel, but involving 141 the registrant is not necessarily easily automated. 143 little overhead for losing operator Whenever interaction or action 144 cannot be avoided, the losing operator should be involved as 145 little as possible to avoid overhead for the leaving customer. In 146 turn, this suggests the gaining operator should be in control of 147 the process. 149 3. Security Considerations 151 This section needs more work 153 4. IANA Considerations 155 This document does not request any IANA action. 157 5. References 159 5.1. Normative References 161 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 162 STD 13, RFC 1034, November 1987. 164 [RFC1035] Mockapetris, P., "Domain names - implementation and 165 specification", STD 13, RFC 1035, November 1987. 167 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 168 Names", BCP 32, RFC 2606, June 1999. 170 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 171 BCP 153, RFC 5735, January 2010. 173 5.2. Informative References 175 [I-D.ietf-dnsop-rfc4641bis] 176 Kolkman, O., "DNSSEC Operational Practices, Version 2", 177 draft-ietf-dnsop-rfc4641bis-05 (work in progress), 178 October 2010. 180 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 181 Rose, "DNS Security Introduction and Requirements", 182 RFC 4033, March 2005. 184 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 185 Rose, "Resource Records for the DNS Security Extensions", 186 RFC 4034, March 2005. 188 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 189 Rose, "Protocol Modifications for the DNS Security 190 Extensions", RFC 4035, March 2005. 192 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 193 RFC 4641, September 2006. 195 [RFC5930] Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced 196 Encryption Standard Counter Mode (AES-CTR) with the 197 Internet Key Exchange version 02 (IKEv2) Protocol", 198 RFC 5930, July 2010. 200 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 201 Protocol (EAP) Authentication Using Only a Password", 202 RFC 5931, August 2010. 204 Appendix A. Document Revision History 206 This section is to be removed should the draft be published. 207 $Id: draft-koch-dnsop-dnssec-operator-change.xml,v 1.1 2011/03/07 21:52:05 pk Exp $ 209 A.1. Initial document 211 ... 213 Authors' Addresses 215 Peter Koch 216 DENIC eG 217 Kaiserstrasse 75-77 218 Frankfurt 60329 219 DE 221 Phone: +49 69 27235 0 222 Email: pk@DENIC.DE 224 Marcos Sanz 225 DENIC eG 226 Kaiserstrasse 75-77 227 Frankfurt 60329 228 DE 230 Phone: +49 69 27235 0 231 Email: sanz@DENIC.DE