idnits 2.17.1 draft-mekking-dnsop-auto-cpsync-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2010) is 4874 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) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations W. Mekking 3 Internet-Draft NLnet Labs 4 Intended status: Standards Track December 21, 2010 5 Expires: June 24, 2011 7 Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE 8 draft-mekking-dnsop-auto-cpsync-01 10 Abstract 12 This document proposes a way to synchronise existing trust anchors 13 automatically between a child zone and its parent. The protocol can 14 be used for other Resource Records that are required to delegate from 15 a parent to a child such as NS and glue records. The synchronization 16 allows for a third party to be involved, thus the protocol is 17 suitable for both cases, whether you have to communicate to the 18 registry or to the registrar. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 24, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Introduction 60 This memo defines a way to synchronise existing trust anchors 61 automatically between a child zone and its parent. The protocol can 62 be used for other Resource Records that are required to delegate from 63 a parent to a child such as NS and glue records. The synchronization 64 allows for a third party to be involved, thus the protocol is 65 suitable for both cases, whether you have to communicate to the 66 registry or to the registrar. 68 To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones 69 must submit their DNSKEYs, or hashes of their DNSKEYs, to their 70 parent zone. The parent zone publishes the hashes of the DNSKEYs in 71 the form of a DS record. The DNSKEY RRset at the child may change 72 over time. In order to keep the chain of trust intact, the DS 73 records at the parent zone also needs to be updated. The rolling of 74 the keys with the SEP bit on is one of the few tasks in DNSSEC that 75 yet has to be fully automated. 77 The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone 78 changes to the parent. 80 To bootstrap the communication channel, information must be exchanged 81 in order to detect service location and granting update privileges. 82 A new or existing child zone is in need of a communication channel 83 with the parent. This can be a direct channel or a channel through a 84 third party: 86 If the parent allows for direct communication channel with child 87 zones, the parent can share the required data to set up the 88 channel to the child zone. Once the child has the required 89 credentials, it can use the direct communication channel with the 90 parent to request zone changes related to its delegation. 92 If a third party is involved, the third party acts on behalf of 93 the parent. In this case, the third party will give out the 94 required credentials to set up the communication channel. 96 Allowing for a third party in the communication channel ensures 97 flexibility of the service location. 99 Please note that the document only describes the front end of the 100 synchronization service. The first reason for that is that it is not 101 necessary to write down how the DNS UPDATE is processed after it is 102 accepted. It is merely a goal to provide a way for the child zone to 103 automatically update the records at the zone cut. The second reason 104 is that flexibility is needed in order to fit the protocol into the 105 multifarious policies that exist among the great number of 106 registrars. 108 Thus, it is not required that the DNS UPDATE immediately updates the 109 name server. Thus, it would still be possible to monitor the 110 incoming updates with the tools of your choice. It is not a 111 replacement of your RR provisioning system. The records in the DNS 112 UPDATE can be converted into any kind of format. 114 2. Service Discovery 116 The service location is handed out during bootstrap. If this 117 information is missing or incorrect, the normal guidelines for 118 sending DNS UPDATE messages SHOULD be followed. 120 3. Access and Update Control 122 The DNS UPDATE normally is used for granting update permissions to a 123 machine that is within the boundary of the same organization. This 124 document proposes to grant child zones the same permissions. 125 However, it MUST NOT be possible that a child zone updates 126 information in the parent zone that falls outside the administrative 127 domain of the corresponding delegation. For example, it MUST NOT be 128 possible for a child zone to update the data that the parent is 129 authoritative for, or update a delegation that is pointed to a 130 different child zone. It MUST only be able to update records that 131 match one of the following: 133 Or: The owner name is equal the child zone name and RRtype is 134 delegation specific. Currently those are records with RRtype NS 135 or DS. 137 Or: The owner name exists in the right side of the NS RRset 138 belonging to the child zone and RRtype is is glue specific. 139 Currently those are records with RRtype A or AAAA. 141 We can make a distinction here between narrow and wide glue records. 142 Narrow glue records are said to be glue specific records with an 143 owner name that is a subdomain of the child zone. Wide glue records 144 are glue specific records with an owner name that is outside of the 145 delegated child domain. 147 These updates MAY be refused if it conflicts with the local policy. 148 This list may be expanded, if there is need for more delegation 149 related zone content. 151 In case of adding or deleting delegation specific records, the DNSSEC 152 related RRs in the parent zone might need to be updated. 154 4. Update Mechanism 156 4.1. Update Request 158 Updating the NS RRset or corresponding glue at the parent, an update 159 can be sent at any time. Updating the DS RRset is part of key 160 rollover, as described in RFC 4641 [RFC4641]. When performing a key 161 rollover that involves updating the RRset at the parent, the child 162 introduces a new DNSKEY in its zone that represents the security 163 entry point for determining the chain of trust. After a while, it 164 will revoke and/or remove the previous security entry point. The 165 timings when to update the DS RRset at the parent are described in 166 draft-dnsop-morris-dnssec-key-timing [keytiming]. When updating the 167 DS RRset at the parent automatically, these timing specifications 168 SHOULD be followed. To determine the propagation delays described in 169 this document, the child should poll the parent zone for a short 170 time, until the DS is visible at all parent name servers. 172 [Author's note] To discuss: A child zone might be unable to reach all 173 parent name servers. 175 The child notifies the parent of the requested changes by sending a 176 DNS UPDATE message. If it receives a NOERROR reply in return, the 177 update is acknowledged by the parent zone. Otherwise, the child MAY 178 retry transmitting the update. In order to prevent duplicate 179 updates, it SHOULD follow the guidelines described in RFC 2136 180 [RFC2136]. 182 4.2. Processing the Update 184 An incoming DNS UPDATE message is processed as follows: 186 Step 1: Check the TSIG/SIG0 credentials. In case of TSIG, the 187 parent should follow the TSIG processing described in section 3.2 188 of RFC 2845. In case of SIG0, the parent should follow the SIG0 189 processing described in section 3.2 of RFC 2931. 191 Step 2: Verify that the updates matches the update policy for child 192 zones. 194 Step 3: If verified, send back DNS UPDATE OK. Otherwise, send back 195 DNS UPDATE REFUSED. 197 Step 4: If verified, apply changes. How that is done is a matter of 198 policy. 200 5. Examples 202 5.1. Example BIND9 Configuration 204 This is how a parent zone can configure a policy to enable a child 205 zone synchronize delegation specific records. The first rule of the 206 update policy grants children to update their DS and NS records in 207 the parent zone, in this case example.com. The second rule of the 208 update policy grants children to update the corresponding glue 209 records. 211 key cs.example.com. { 212 algorithm HMAC-MD5; 213 secret "secretforcs"; 214 } 216 key math.example.com. { 217 algorithm HMAC-MD5; 218 secret "secretformath"; 219 } 221 ... 223 zone "example.com" { 224 type master; 225 file "example.com"; 226 update-policy { grant *.example.com. self *.example.com. DS NS; }; 227 update-policy { grant *.example.com. selfsub *.example.com. A AAAA; 228 }; 229 }; 231 6. Security Considerations 233 Automating the synchronization of (DNSSEC) records between the parent 234 and child creates a new communication channel. It is up to the 235 policy of the parent, or the third party acting on behalf of the 236 parent, who is allowed such privileges. A policy would usually 237 include a form of access control. It is recommended that it involves 238 transaction authentication, for example TSIG [RFC2845] or SIG0 240 [RFC2931]. 242 In the jungle of the DNS, many stakeholders exist. The registrant of 243 a zone might not be the one that maintains the zone. That can 244 possibly mean that many stakeholders need to possess the security 245 credentials in order to use this synchronization channel. However, 246 this problem exist with any kind of transaction authentication. 248 The disadvantage of adding a new communication channel is that you 249 create a new attack window onto your DNS and DNSSEC records. When 250 using this synchronization method for your DNSSEC records, a 251 cryptographically equally strong, or stronger private key SHOULD be 252 used, compared to the strength of your DNSSEC keys. 254 The advantage is that if somehow your DNSSEC keys are compromised, 255 you can still use this channel to perform an emergency key rollover. 257 7. IANA Considerations 259 None. 261 8. Acknowledgments 263 Mark Andrews, Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards. 265 9. Changelog 267 01: 269 - Make it clear that the solution is flexible and it can fit into 270 many and diverse environments of registrars. 272 - Short section about service discovery. 274 - Add text about narrow glue records. 276 - Add text about transaction authentication concerns with respect 277 to many stakeholders involved. 279 00: 281 - Initial document 283 10. References 284 10.1. Informative References 286 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 287 "Dynamic Updates in the Domain Name System (DNS 288 UPDATE)", RFC 2136, April 1997. 290 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational 291 Practices", RFC 4641, September 2006. 293 [keytiming] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key 294 Timing Considerations", March 2010. 296 10.2. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 302 Wellington, "Secret Key Transaction Authentication for 303 DNS (TSIG)", RFC 2845, May 2000. 305 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 306 SIG(0)s)", RFC 2931, September 2000. 308 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 309 Rose, "Protocol Modifications for the DNS Security 310 Extensions", RFC 4035, March 2005. 312 Author's Address 314 Matthijs Mekking 315 NLnet Labs 316 Science Park 140 317 Amsterdam 1098 XG 318 The Netherlands 320 EMail: matthijs@nlnetlabs.nl