idnits 2.17.1 draft-daley-updatezones-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 : ---------------------------------------------------------------------------- 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 (November 12, 2013) is 3818 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Daley 3 Internet-Draft .nz Registry Services 4 Intended status: Standards Track November 12, 2013 5 Expires: May 16, 2014 7 Extending DNS UPDATE for 'whole of zone' operations 8 draft-daley-updatezones-00 10 Abstract 12 This memo describes an extension to the DNS protocol that support the 13 remote provisioning of zones on authoritative servers. This addition 14 is complementary to the existing mechanisms for provisioning zone 15 data using the DNS protocol. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 16, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 3. Extending the DNS UPDATE message . . . . . . . . . . . . . . 3 55 3.1. 'in zone' vs 'whole of zone' operations . . . . . . . . . 3 56 3.2. Adding zones . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2.1. Adding a master zone . . . . . . . . . . . . . . . . 4 58 3.2.2. Adding slave zones . . . . . . . . . . . . . . . . . 5 59 3.3. Removing zones . . . . . . . . . . . . . . . . . . . . . 5 60 3.4. Response . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Processing 'whole of zone' operations . . . . . . . . . . . . 6 62 4.1. Dynamic serving . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Atomicity . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. Provisioning order . . . . . . . . . . . . . . . . . . . 6 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Definitions 75 This memo uses the following DNS server roles in a manner consistent 76 with RFC 2136 [RFC2136]: 78 Slave An authoritative server that uses AXFR or IXFR to retrieve 79 the zone and is named in the zone's NS RRset. 81 Master An authoritative server configured to be the source of AXFR 82 or IXFR data for one or more slave servers. 84 This memo uses the term "catalog of zones" in the spirit of RFC 1035 85 [RFC1035] to describe the set of zones that a server is authoritative 86 for. 88 2. Introduction 90 It is common practice for Internet service providers and domain name 91 registrars to operate DNS servers that are simultaneously 92 authoritative for many zones. In some case a single DNS server may 93 be authoritative for hundreds of thousands of zones. Despite the 94 large number of zones served, the server is unlikely to also be 95 authoritative for a common parent of these zones and so must operate 96 each zone independently. 98 The DNS protocol supports the provisioning of resource records in 99 zones already being served by an authoritative DNS server using the 100 DNS UPDATE message described in RFC 2136 [RFC2136]. However no 101 similar operation exists to update the list of zones that a server 102 serves. 104 This memo describes an extension to the DNS UPDATE message that 105 allows it to be used to instruct an authoritative DNS server to start 106 serving or stop serving zones. This extension supports the remote 107 provisioning of zones in the same manner that DNS UPDATE supports the 108 remote provisioning of Resource Records. 110 2.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Extending the DNS UPDATE message 118 RFC 2136 [RFC2136] defines the DNS UPDATE message which enables the 119 remote provisioning of data within existing zones. The operations 120 enabled by RFC 2136 [RFC2136] are now referred to as 'in zone' 121 operations. 123 This memo extends the definition of the DNS UPDATE message to enable 124 the remote provisioning of zones. The operations enabled by this 125 memo are referred to as 'whole of zone' operations. 127 Two 'whole of zone' operations are defined in this memo: 129 1. Adding zones. Instructing the receiving server to add one or 130 more zones to the catalog of authoritative zones that it serves 131 and start serving these zone, either as a master or a slave. 133 2. Removing zones. Instructing the receiving server to stop serving 134 one or more authoritative zones and remove them from the catalog 135 of zones that it serves. 137 The operations described in this memo operate on the catalog of zones 138 irrespective of whether or not the server is currently responding to 139 queries for a specific zone as a server may at any point time be 140 actively serving only some of the zones in its catalog for 141 operational reasons. 143 3.1. 'in zone' vs 'whole of zone' operations 144 'in zone' operations are distinguished from 'whole of zone' 145 operations by the ZTYPE of the zones in the Zone section of the DNS 146 UPDATE message: 148 o For 'in zone' operations the ZTYPE of all of the zones in the Zone 149 section MUST be SOA. 151 o For 'whole of zone' operations the ZTYPE of all of the zones in 152 the Zone section MUST be NS. 154 It is not possible to have both 'in zone' and 'whole of zone' 155 operations in the same DNS UPDATE message and so the zones in the 156 Zone section MUST NOT have different ZTYPES. 158 'whole of zone' operations interpret the data in the Prerequisite, 159 Update and Additional sections differently from 'in zone' operations. 161 3.2. Adding zones 163 The operation to add new authoritative zones can come in one of two 164 forms: 166 1. Add a master zone. Instructing the receiving server to add a new 167 zone and serve that zone as a master. 169 2. Adding slave zones. Instructing the receiving server to add one 170 or more new zones and serve those as a slave. 172 3.2.1. Adding a master zone 174 To add a master zone the DNS UPDATE is constructed as follows: 176 One zone and only one zone MUST be listed in the Zone section. and 177 the ZTYPE of that zone MUST be set to NS. 179 The Prerequisitie section MUST be empty. 181 The Update section MUST contain the SOA record for the new zone. The 182 class of the SOA record MUST NOT be ANY. 184 The Update section MAY contain any other resource records that are to 185 be added to the zone. 187 The receiving server MUST add the SOA record and any records in the 188 Update section to the zone before serving the zone. 190 The Additional section MUST be empty. 192 3.2.2. Adding slave zones 194 To add slave zones the DNS UPDATE is constructed as follows: 196 One or more zones MUST be listed in the Zone section. and the ZTYPE 197 of those zone MUST be set to NS. 199 The Prerequisitie section MUST be empty. 201 The Update section MUST be empty. 203 The Additional section MUST contain at least one A or AAAA resource 204 record. All A and AAAA records are used by the receiving server to 205 identify the servers it should contact to pull the zones from. 207 The Additional section MAY contain a TKEY record that the receiving 208 server should use to authenticate itself when it pulls the zones. 210 The resource records in the Additional section MUST NOT be added to 211 the zones. 213 3.3. Removing zones 215 To remove zones the DNS UPDATE is constructed as follows: 217 One or more zones MUST be listed in the Zone section. and the ZTYPE 218 of those zones MUST be set to NS. 220 The Prerequisitie section MUST be empty. 222 The Update section MUST contain a SOA record for the zone to be 223 deleted and the class of the SOA record MUST be ANY. This use of a 224 class of ANY to signal the removal of a zone matches the way that a 225 resource record that is to be deleted is identified in RFC 2136 226 [RFC2136] 228 The Additional section MUST be empty. 230 3.4. Response 232 The response sent to acknowledge receipt and processing of a 'whole 233 of zone' operation is the same as specified for an 'in zone' 234 operation in RFC 2136 [RFC2136] with the addition of the following 235 specific error conditions: 237 1. When adding zones, If any of the zones listed are already in the 238 catalog of authoritative zones served by the receiving server, 239 whether or not it is currently being served, then the server MUST 240 ignore the entire request and return an error response with 241 RCode=YXDOMAIN. 243 2. When adding zones if both the Update and Additional sections are 244 empty then the receiving server MUST ignore the entire request 245 and return an error response with RCode=FORMERROR. 247 3. When adding zones if both the Update and Additional sections 248 contain data then the receiving server MUST ignore the entire 249 request and return an error response with RCode=FORMERROR. 251 4. When adding a master zone, if initial zone data is provided and 252 the domains names of those resource records are not within the 253 zone being added (i.e. they are 'out of bailiwick') then the 254 receiving server SHOULD ignore the entire operation and return an 255 error response with RCode=FORMERROR. 257 5. When removing zones, if any of the zones listed are not in the 258 catalog of zones served by the receiving server then it MUST 259 ignore the entire request and return an error response with 260 RCode=NXDOMAIN. 262 4. Processing 'whole of zone' operations 264 4.1. Dynamic serving 266 It is recognised that not all authoritative nameservers are capable 267 of dynamically loading new zones to serve or dynamically ceasing to 268 serve zones. It is left to the implementor to decide whether to load 269 /unload the zones dynamically; wait for a server restart or to 270 initiate a restart itself. 272 4.2. Atomicity 274 This memo does not change the requirements for serialisation of 275 UPDATE operations the depend on each other, as specified in section 276 3.7 of RFC 2136 [RFC2136], which apply equally to 'whole of zone' 277 operations as they do to 'in zone' operations. 279 4.3. Provisioning order 281 A server receiving a 'whole of zone' operation SHOULD NOT assume any 282 particular order to the provisioning of zones and reject the 283 operation as a result. Examples of erroneous rejections include: 285 1. When adding slave zones, rejecting the operation if the master 286 servers specified are unreachable or do not serve the required 287 zone. 289 2. When adding or removing zones, rejecting the operation if it 290 would leave an incorrect or inconsistent set of nameservers for 291 that zone specified in that zone or in the parent delegation. 293 5. Acknowledgements 295 The author thanks Mark Andrews for his input. 297 6. IANA Considerations 299 This memo includes no request to IANA. 301 7. Security Considerations 303 Clearly unrestricted access to 'whole of zone' operations is a 304 significant threat and misuse would be likely to cause considerable 305 issues. It is therefore RECOMMENDED that: 307 o DNS UPDATE messages that contain 'whole of zone' operations are 308 protected by TSIG and implementors allow adminstrators to require 309 this protection. 311 o Implementors do not enable processing of 'whole of zone' 312 operations by default. 314 The provision of a TKEY record is a significant vulnerability if the 315 DNS UPDATE message containing it is transmitted in clear over the 316 wire. It is therefore RECOMMENDED that such messages are encrypted. 318 8. References 320 8.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 326 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 327 RFC 2136, April 1997. 329 8.2. Informative References 331 [RFC1035] Mockapetris, P., "Domain names - implementation and 332 specification", STD 13, RFC 1035, November 1987. 334 Author's Address 335 Jay Daley 336 .nz Registry Services 337 PO Box 24361, Manners Street 338 Wellington 6142 339 New Zealand 341 Phone: +64 4 931 6970 342 Email: jay@nzrs.net.nz