idnits 2.17.1 draft-daley-servezones-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 (August 13, 2013) is 3906 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, Ed. 3 Internet-Draft .nz Registry Services 4 Intended status: Standards Track August 13, 2013 5 Expires: February 14, 2014 7 DNS SERVEZONES message 8 draft-daley-servezones-00 10 Abstract 12 This memo describes an addition 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 February 14, 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. The SERVEZONES message . . . . . . . . . . . . . . . . . . . 3 55 3.1. SERVEZONES request . . . . . . . . . . . . . . . . . . . 3 56 3.1.1. Specifying master servers . . . . . . . . . . . . . . 4 57 3.1.2. Specifying initial zone data . . . . . . . . . . . . 4 58 3.2. SERVEZONES response . . . . . . . . . . . . . . . . . . . 4 59 4. Processing the SERVEZONES messages . . . . . . . . . . . . . 5 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 8.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Definitions 70 This memo uses the following DNS server roles in a manner consistent 71 with RFC 2136 [RFC2136]: 73 Slave An authoritative server that uses AXFR or IXFR to retrieve 74 the zone and is named in the zone's NS RRset. 76 Master An authoritative server configured to be the source of AXFR 77 or IXFR data for one or more slave servers. 79 2. Introduction 81 It is common practice for Internet service providers and domain name 82 registrars to operate DNS servers that are simultaneously 83 authoritative for many zones. In some case a single DNS server may 84 be authoritative for hundreds of thousands of zones. Despite the 85 large number of zones served, the server is unlikely to also be 86 authoritative for a common parent of these zones and so must operate 87 each zone independently. 89 The DNS protocol supports the provisioning of resource records in 90 zones already being served by an authoritative DNS server using the 91 DNS UPDATE message described in RFC 2136 [RFC2136]. However no 92 similar operation exists to update the list of zones that a server 93 serves. 95 This memo describes the SERVEZONES message that instructs an 96 authoritative DNS server to start serving or stop serving zones. 98 This message supports the remote provisioning of zones in the same 99 manner that DNS UPDATE supports the remote provisioning of Resource 100 Records. 102 2.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 3. The SERVEZONES message 110 When a DNS server or provisioning system chooses to instruct an 111 authoritative DNS server to start serving or stop serving one or more 112 zones then it does so by sending a SERVEZONES message. SERVEZONES 113 uses the DNS message format, although it uses only a subset of the 114 available fields. 116 SERVEZONES is similar to NOTIFY in that it has a request message with 117 the header QR=0 and a response message with QR=1. The response 118 message contains no useful information, but its reception is an 119 indication that the server has received the SERVEZONES message. 121 SERVEZONES is similar to UPDATE in that the contents of the QTYPE 122 field are used to differentiate between a request to start serving a 123 specified zone or to stop serving a specified zone. 125 The SERVEZONES message is signalled by Opcode=6. 127 Except where specified, all DNS header fields are set as for a normal 128 DNS query or response. 130 3.1. SERVEZONES request 132 A SERVEZONES request contains one or more zones included as a QNAME 133 in the QUERY section of the SERVEZONES message. 135 A single SERVEZONES request can instruct the receiving server to both 136 start serving one or more zones and to stop serving one or more 137 zones. 139 Each zone for which serving is to start is included as a QNAME in the 140 QUERY section with the QTYPE set to SOA. 142 Each zone for which serving is to stop is included as a QNAME in the 143 QUERY section with the QTYPE set to ANY. 145 For all SERVEZONES requests: 147 o The QCLASS for each entry in the QUERY section is set as required 149 o QDCOUNT is set to the number of zones in the QUERY section. 151 o ANCOUNT is set to zero (0). 153 3.1.1. Specifying master servers 155 If the server receiving the message is intended to act as a slave 156 server then the AUTHORITY section MAY include a list of master 157 servers. NSCOUNT is set to the number of master servers listed in 158 the AUTHORITY section. 160 If a list of master servers is provided then it applies to all the 161 zones listed in the SERVEZONES message for whom serving is to start 162 (QTYPE is set to SOA). 164 The receiving server MUST fetch the zone data from one of the listed 165 master servers before serving the zone. 167 3.1.2. Specifying initial zone data 169 If the server receiving the message is intended to act as a master 170 then the ADDITIONAL section MUST include the initial zone data. 171 ARCOUNT is set to the number of entries in the ADDITIONAL section. 173 If initial zone data is included in the ADDITIONAL section then it 174 applies to all the zones listed in the SERVEZONES message for whom 175 serving is to start (QTYPE is set to SOA). If multiple zones are 176 listed then the initial zone data MUST NOT contain any fully 177 qualified domain names (FQDNs). 179 The receiving server MUST add the initial zone data before serving 180 the zone. 182 3.2. SERVEZONES response 184 A SERVEZONES response is sent to acknowledge receipt of the 185 SERVEZONES request to the same source that sent the original request. 187 QDCOUNT, ANCOUNT, NSCOUNT and ARCOUNT are all set to zero (0). 189 If the SERVEZONES request is processed correctly then the receiving 190 server SHOULD respond with a SERVEZONES response with RCode=NOERROR. 192 The following specific error conditions apply: 194 1. If any of the zones listed in the request to start serving are 195 already being served by the receiving server then it MUST ignore 196 the entire request and return an error response with 197 RCode=YXDOMAIN. 199 2. If any zones are listed in the request to start serving and 200 neither the AUTHORITY or ADDITIONAL sections appear in the 201 request then the receiving server MUST ignore the entire request 202 and return an error response with RCode=FORMERROR. 204 3. If any zones are listed in the request to start serving and both 205 the AUTHORITY and ADDITIONAL sections contain data then the 206 receiving server MUST ignore the entire request and return an 207 error response with RCode=FORMERROR. 209 4. If FQDNs are included in the initial zone data and the SERVEZONES 210 message lists multiple zones to start serving then the receiving 211 server SHOULD return an error response with RCode=FORMERROR. 213 5. If any of the zones listed in the request to stop serving are not 214 being served by the receiving server then it MUST ignore the 215 entire request and return an error response with RCode=NXDOMAIN. 217 4. Processing the SERVEZONES messages 219 It is recognised that not all authoritative nameservers are capable 220 of dynamically loading new zones to serve or dynamically ceasing to 221 serve zones. It is left to the implementor to decide whether to load 222 /unload the zones dynamically; wait for a server restart or to 223 initiate a restart itself. 225 5. Acknowledgements 227 The author thanks Sebastian Castro for his input and review. 229 6. IANA Considerations 231 This memo requests that IANA assigns the following values in the DNS 232 Opcode registry: 234 +--------+------------+ 235 | Opcode | Mnemonic | 236 +--------+------------+ 237 | 6 | SERVEZONES | 238 +--------+------------+ 240 7. Security Considerations 242 Clearly the SERVEZONES message has the potential to be misused and 243 such misuse would be likely to cause considerable issues. It is 244 therefore RECOMMENDED that: 246 o SERVEZONES messages are always protected by TSIG and implementors 247 allow adminstrators to require this protection. 249 o Implementors do not enable processing of SERVEZONES messages by 250 default. 252 8. References 254 8.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 8.2. Informative References 261 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 262 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 263 RFC 2136, April 1997. 265 Author's Address 267 Jay Daley (editor) 268 .nz Registry Services 269 PO Box 24361, Manners Street 270 Wellington 6142 271 New Zealand 273 Phone: +64 4 931 6970 274 Email: jay@nzrs.net.nz