idnits 2.17.1 draft-ietf-dnsext-newzone-notify-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 32 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended status: Standard Track Feng HAN', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2010) is 5162 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) -- Looks like a reference, but probably isn't: '1' on line 112 == Missing Reference: 'RFC 1034' is mentioned on line 161, but not defined == Unused Reference: 'RFC1034' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC2845' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'PDNS' is defined on line 320, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Extensions Working Group Cindy WANG 2 Internet Draft Jian JIN 3 Intended status: Standard Track Feng HAN 4 Xiaodong LEE 5 CNNIC 6 Expires: August 7, 2010 February 8, 2010 8 A mechanism for synchronization across name servers on zone creation 9 draft-ietf-dnsext-newzone-notify-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 7, 2010. 34 Copyright Notice 36 Copyright (c) 2010 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 BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Abstract 63 This memo describes the NEWZONE_NOTIFY opcode for DNS, by which a 64 primary master server advises a set of slave servers that there is a 65 zone has been created and that a query should be initiated to 66 discover the new zone data. 68 This draft also specifies a mechanism for the slave servers to 69 achieve authenticated synchronization of zone data as well as zone 70 synchronization information with the primary when a zone is created 71 on the primary. 73 Table of Contents 75 1. Introduction................................................4 76 2. Conventions used in this document...........................5 77 3. Definitions and Invariants..................................5 78 4. NEWZONE_NOTIFY message......................................6 79 5. Automating the synchronization on zone creation across multiple 80 name servers...................................................7 81 6. Security Considerations.....................................9 82 7. References..................................................9 84 1. Introduction 86 For large and busy domain name registrars, the zone creation 87 operations resulted from frequent domain name registrations are 88 almost daily routines. However, for these operations there are no 89 technical specifications for automatic zone synchronization across 90 multiple name servers. Moreover, the manual operations turn into 91 heavy burden for administrators when there is large number of name 92 servers authoritative for the zones. 94 The major obstacle to the synchronization in the above situation is 95 that, specified by the original design of DNS, when authority zones 96 are created, they must be declared to have one or more authoritative 97 name servers, usually consisting of one primary name server and 98 several secondary name servers. The configuration of the 99 synchronization relationships among the name servers depends upon out 100 of band information and manual processes, which are normally 101 specified with the zone creation. 103 This draft specifies a mechanism for the slave servers to achieve 104 authenticated synchronization of both zone data and dependency 105 configuration with the master servers when a zone is created. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in RFC-2119 [1]. 113 3. Definitions and Invariants 115 The following definitions are used in this document, and intended to 116 be consistent with [RFC1996] and [RFC2136]: 118 o Slave: an authoritative server which uses zone transfer to 119 retrieve the zone. All slave servers are named in the NS RRs 120 for the zone. 122 o Master: an authoritative server configured to be the source of 123 zone transfer for one or more slave servers. 125 o Primary Master: the master server at the root of the zone 126 replication dependency graph. The primary master is named in 127 the zone's SOA MNAME field and optionally by an NS RR. There is 128 by definition only one primary master server per zone and the 129 source of zone creation for one or more slave servers. 131 o Notify Set: set of servers to be notified of changes to some 132 new zone. Default is all servers named in the NS RRset of the 133 zone, except for any server also named in the SOA MNAME. Some 134 implementations will permit the name server administrator to 135 override this set or add elements to it (such as, for example, 136 the "also-notify" implemented in BIND [DNS_BIND]). 137 o Trusted-Master Set: set of servers whose notification could be 138 trusted by the slave and the set is specified out-of-bind. 140 o Dependency graph: organization of the zone's name servers, such 141 that there is a primary master, and all other servers must 142 request zone replication either from the primary master or from 143 some slave which is also a master. NO loops are permitted in 144 the dependency graph. The dependency graph is created with the 145 zone by the administrator on the primary master. For example, 146 the set of servers for a zone is {p, s1, s2, s3, s4, s5, s6, 147 s7}, where p is the address of the primary and {s1... s7} 148 addresses of the slaves. The dependency graph could be defined 149 as {{p->s1}, {p->s2}, {p->s3}, {s1->s2}, {s2->s3}, {s2->s4}, 150 {s2->s5}, {s3->s6}, {s3->s7}}, where "->" denotes "is the 151 master of". An example of the "master of" relationship would 152 look like, {1.2.3.4->5.6.7.8}. 154 4. NEWZONE_NOTIFY message 156 4.1. When a primary master has a new zone, the master may send the 157 created zone's name, class, type, and the name of the master from 158 which the slave to request the zone data, to each known slave 159 server using a protocol based on the NEWZONE_NOTIFY opcode. 161 4.2. NEWZONE_NOTIFY employs the DNS Message Format [RFC 1034], 162 although it uses only a subset of the available fields. Fields 163 not otherwise described herein are to be filled with binary zero 164 (0). 166 4.3. NEWZONE_NOTIFY is similar to QUERY in that it has a request 167 message with the header QR flag "clear" and a response message 168 with QR "set". The response message contains no useful 169 information, but its reception by the master is an indication that 170 the slave has received the NEWZONE_NOTIFY and that the master can 171 remove the slave from any retry queue for this NEWZONE_NOTIFY 172 event. 174 4.4. TSIG MUST be enabled between parties exchanging the 175 NEWZONE_NOTIFY messages. 177 4.5. The NEWZONE_NOTIFY request has the following characteristics: 178 Header: 180 query ID: (new) 181 opcode: NEWZONE_NOTIFY (5) 182 resp: NOERROR 183 flags: AA 184 qdcount: 1 185 ancount: 1 186 Question Section: 187 qname: (zone name) 188 qclass: (zone class) 189 qtype: * (matches all RR types) 190 Answer Section: 191 Name of one of the masters m which satisfies m->s, where s is 192 the notified slave. 194 The defined NEWZONE_NOTIFY event in this situation is that a zone has 195 been created (QTYPE=*) on the primary master server. 197 5. Automating the synchronization on zone creation across multiple 198 name servers 200 5.1. Zone created on the primary master server 202 1. The primary master should send a NEWZONE_NOTIFY request to all 203 the servers in the dependency graph except for itself. 205 2. The notifying order should be decided by the distances (number 206 of other masters in between) of the slaves to the primary 207 master. A slave CANNOT be notified until at least one of its 208 masters responds back to the primary master with success. 210 3. For slaves with more than one master, the primary master MUST 211 send multiple notification messages, one for each master. 213 5.2. Slave Receives a NEWZONE_NOTIFY Request from the Primary Master 214 When a slave server receives a NEWZONE_NOTIFY request enclosing the 215 given QNAME, with QTYPE=* and QR=0, first of all, it MUST check the 216 authentication of the message by examining, 218 1. The notifying IP must be present in the slave's 'Trusted-Master 219 Set'; (protecting the slave from being flooded by malicious 220 messages.) 222 2. By requesting the SOA and NS record sets for the created zone 223 from the notifying master, 225 3. The notifying master MUST carry a SOA record for the notified 226 zone; 228 4. The notifying master MUST either appear in the MNAME of the SOA 229 record or goes with one name in the NS record-set for the 230 created zone; 232 5. The set of NS records for the created zone, as retrieved by the 233 slave from the notifying master, MUST include the name that 234 goes with the IP address of the notified master. 236 If the notification is justified by all the above conditions, the 237 slave should behave as though the zone given in the QNAME had been 238 created on the primary master. It should respond to the 239 NEWZONE_NOTIFY message with the following actions, 240 1. Firstly, it requests the SOA record of the named zone locally 241 to determine whether the zone exists or not. 243 2. If the zone exists, then the synchronization has been done from 244 other master of the slave; otherwise, it is a zone creation 245 notification and a zone transfer (AXFR) [AXFR_clarify] should 246 be initiated to the master specified in the answer section of 247 the NEWZONE_NOTIFY message from the primary master. 249 3. In both cases, the master appearing in the answer section is 250 configured locally to be one of the masters of the slave. 252 4. Finally, the updates are loaded into memory and the master 253 specified in the answer section of the NEWZONE_NOTIFY message 254 is added to the master list of the slave. 256 5. Whether the AXFR succeeds or not, the slave will also send a 257 NEWZONE_NOTIFY response back to the NEWZONE_NOTIFY request's 258 source, with the following characteristics: 260 Header: 261 query ID: (same) 262 opcode: NEWZONE_NOTIFY (5) 263 RCODE: NOERROR (AXFR succeeds) or Server failure (AXFR 264 fails) 265 flags: OR AA 266 qdcount: 1 267 Question Section: 268 qname: (zone name) 269 qclass: (zone class) 270 qtype: * (matches all RR types) 271 Answer Section: 272 MUST be EMPTY 274 5.3. Primary Master Receives a NEWZONE_NOTIFY Response from Slave 276 1. If a NEWZONE_NOTIFY response from a slave with RCODE= Server 277 failure arrives, the primary master keeps the NEWZONE_NOTIFY 278 query in the retry queue. 280 2. Otherwise, if the primary master server receives a 281 NEWZONE_NOTIFY response from a slave with RCODE= NOERROR, it 282 initiates the notification process to all the slaves of that 283 slave. Next it deletes the successful query from the retry 284 queue, thus completing the notification process of the zone 285 creation change to the notifying slave. 287 6. Security Considerations 289 This document is believed to introduce no additional security 290 problems to the current DNS protocol. 292 7. References 294 7.1. Normative References 296 [RFC1034] Mockapetris, P., "Domain names - concepts and 297 facilities", STD 13, RFC 1034, November 1987. 299 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 300 Specifications", STD 13, RFC 1035, November 1987. 302 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 303 Changes (DNS NOTIFY)", RFC 1996, August 1996. 305 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 306 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 307 RFC 2136, April 1997. 309 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and Wellington, 310 B., "Secret Key Transaction Authentication for DNS (TSIG) 311 ", RFC 2845, May 2000. 313 7.2. Informative References 315 [AXFR_clarify] DNS Zone Transfer Protocol (AXFR). draft-ietf- 316 dnsext-axfr-clarify-12. 318 [DNS_BIND] DNS and BIND, 5th Edition. 320 [PDNS] PowerDNS manual. Chapter 13. Master/Slave operation & 321 replication. 323 Authors' Addresses 324 Cindy WANG 325 CNNIC 326 4, South 4th Street, Zhongguancun 327 Beijing 100190 328 P.R. China 329 Email: wangxin@cnnic.cn 331 Jian Jin 332 CNNIC 333 4, South 4th Street, Zhongguancun 334 Beijing 100190 335 P.R. China 336 Email: jinjian@cnnic.cn 338 Feng Han 339 CNNIC 340 4, South 4th Street, Zhongguancun 341 Beijing 100190 342 P.R. China 343 Email: hanfeng@cnnic.cn 345 Xiaodong LEE 346 CNNIC 347 4, South 4th Street, Zhongguancun 348 Beijing 100190 349 P.R. China 350 Email: lee@cnnic.cn