idnits 2.17.1 draft-ietf-dnsext-axfr-clarify-14.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to directly say this. It does mention RFC1034 though, so this could be OK. -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to directly say this. It does mention RFC1035 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 26, 2010) is 5137 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 normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4635 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-20) exists of draft-ietf-dnsext-dnssec-bis-updates-10 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group Edward Lewis 3 Internet-Draft NeuStar, Inc. 4 Updates: 1034, 1035 (if approved) A. Hoenes, Ed. 5 Intended status: Standards Track TR-Sys 6 Expires: September 26, 2010 March 26, 2010 8 DNS Zone Transfer Protocol (AXFR) 9 draft-ietf-dnsext-axfr-clarify-14 11 Abstract 13 The standard means within the Domain Name System protocol for 14 maintaining coherence among a zone's authoritative name servers 15 consists of three mechanisms. Authoritative Transfer (AXFR) is one 16 of the mechanisms and is defined in RFC 1034 and RFC 1035. 18 The definition of AXFR has proven insufficient in detail, thereby 19 forcing implementations intended to be compliant to make assumptions, 20 impeding interoperability. Yet today we have a satisfactory set of 21 implementations that do interoperate. This document is a new 22 definition of AXFR -- new in the sense that it records an accurate 23 definition of an interoperable AXFR mechanism. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may contain material 29 from IETF Documents or IETF Contributions published or made publicly 30 available before November 10, 2008. The person(s) controlling the 31 copyright in some of this material may not have granted the IETF 32 Trust the right to allow modifications of such material outside the 33 IETF Standards Process. Without obtaining an adequate license from 34 the person(s) controlling the copyright in such materials, this 35 document may not be modified outside the IETF Standards Process, and 36 derivative works of it may not be created outside the IETF Standards 37 Process, except to format it for publication as an RFC or to 38 translate it into languages other than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress". 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on September 26, 2010. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 76 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 1.4. Coverage and Relationship to Original AXFR Specification . 5 79 2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7 80 2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8 81 2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9 82 2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10 83 2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10 84 2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10 85 2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10 86 2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11 87 2.2.1. Header Values . . . . . . . . . . . . . . . . . . . . . 12 88 2.2.2. Question Section . . . . . . . . . . . . . . . . . . . . 14 89 2.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 14 90 2.2.4. Authority Section . . . . . . . . . . . . . . . . . . . 14 91 2.2.5. Additional Section . . . . . . . . . . . . . . . . . . . 14 92 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 15 93 3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15 94 3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15 95 3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16 96 3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18 97 3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18 98 3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19 99 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20 102 4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21 103 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22 105 6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23 106 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24 107 7.1. Server . . . . . . . . . . .. . . . . . . . . . . . . . . 24 108 7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 111 10. Internationalization Considerations . . . . . . . . . . . . 25 112 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . 26 114 12.1. Normative References . .. . . . . . . . . . . . . . . . 26 115 12.2. Informative References . . . . . . . . . . . . . . . . . 28 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 118 1. Introduction 120 The Domain Name System standard facilities for maintaining coherent 121 servers for a zone consist of three elements. Authoritative Transfer 122 (AXFR) is defined in "Domain Names - Concepts and Facilities" 123 [RFC1034] (referred to in this document as RFC 1034) and "Domain 124 Names - Implementation and Specification" [RFC1035] (henceforth 125 RFC 1035). Incremental Zone Transfer (IXFR) is defined in 126 "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt 127 notification of zone changes (NOTIFY) is defined in "A Mechanism for 128 Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The 129 goal of these mechanisms is to enable a set of DNS name servers to 130 remain coherently authoritative for a given zone. 132 This document re-specifies the AXFR mechanism as it is deployed in 133 the Internet at large, hopefully with the precision expected from 134 modern Internet Standards, and thereby updates RFC 1034 and RFC 1035. 136 1.1. Definition of Terms 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in "Key words for use in 141 RFCs to Indicate Requirement Levels" [BCP14]. 143 Use of "newer"/"new" and "older"/"old" DNS refers to implementations 144 written after and prior to the publication of this document. 146 "General purpose DNS implementation" refers to DNS software developed 147 for widespread use. This includes resolvers and servers freely 148 accessible as libraries and standalone processes. This also includes 149 proprietary implementations used only in support of DNS service 150 offerings. 152 "Turnkey DNS implementation" refers to custom made, single use 153 implementations of DNS. Such implementations consist of software 154 that employs the DNS protocol message format yet does not conform to 155 the entire range of DNS functionality. 157 The terms "AXFR session", "AXFR server" and "AXFR client" will be 158 introduced in the first paragraph of Section 2, after some more 159 context has been established. 161 1.2. Scope 163 In general terms, authoritative name servers for a given zone can use 164 various means to achieve coherency of the zone contents they serve. 165 For example, there are DNS implementations that assemble answers from 166 data stored in relational databases (as opposed to master files), 167 relying on the database's non-DNS means to synchronize the database 168 instances. Some of these non-DNS solutions interoperate in some 169 fashion. However, AXFR, IXFR, and NOTIFY are the only protocol- 170 defined in-band mechanisms to provide coherence of a set of name 171 servers, and they are the only mechanisms specified by the IETF. 173 This document does not cover incoherent DNS situations. There are 174 applications of the DNS in which servers for a zone are designed to 175 be incoherent. For these configurations, a coherency mechanism as 176 described here would be unsuitable. 178 A DNS implementation is not required to support AXFR, IXFR, and 179 NOTIFY, but it should have some means for maintaining name server 180 coherency. A general purpose DNS implementation will likely support 181 AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS 182 implementations may exist without AXFR. 184 1.3. Context 186 Besides describing the mechanisms themselves, there is the context in 187 which they operate to consider. In the initial specifications of 188 AXFR (and IXFR and NOTIFY), little consideration was given to 189 security and privacy issues. Since the original definition of AXFR, 190 new opinions have appeared on the access to an entire zone's 191 contents. In this document, the basic mechanisms will be discussed 192 separately from the permission to use these mechanisms. 194 1.4. Coverage and Relationship to Original AXFR Specification 196 This document concentrates on just the definition of AXFR. Any 197 effort to update the specification of the IXFR or NOTIFY mechanisms 198 is left to different documents. 200 The original "specification" of the AXFR sub-protocol is scattered 201 through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5) 202 depicts the scenario for which AXFR has been designed. Section 4.3.5 203 of RFC 1034 describes the zone synchronization strategies in general 204 and rules for the invocation of a full zone transfer via AXFR; the 205 fifth paragraph of that section contains a very short sketch of the 206 AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant 207 flaw in that specification. Section 3.2.3 of RFC 1035 has assigned 208 the code point for the AXFR QTYPE (see Section 2.1.2 below for more 209 details). Section 4.2 of RFC 1035 discusses how the DNS uses the 210 transport layer and briefly explains why UDP transport is deemed 211 inappropriate for AXFR; the last paragraph of Section 4.2.2 gives 212 details regarding TCP connection management for AXFR. Finally, the 213 second paragraph of Section 6.3 in RFC 1035 mandates server behavior 214 when zone data changes occur during an ongoing zone transfer using 215 AXFR. 217 This document will update the specification of AXFR. To this end, it 218 fully specifies the record formats and processing rules for AXFR, 219 largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it 220 details the transport considerations for AXFR, thus amending Section 221 4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility 222 issues and provides policy/management considerations as well as 223 specific Security Considerations for AXFR. The goal of this document 224 is to define AXFR as it is understood by the DNS community to exist 225 today. 227 2. AXFR Messages 229 An AXFR session consists of an AXFR query message and the sequence of 230 AXFR response messages returned for it. In this document, the AXFR 231 client is the sender of the AXFR query and the AXFR server is the 232 responder. (Use of terms such as master, slave, primary, secondary 233 are not important for defining AXFR.) The use of the word "session" 234 without qualification refers to an AXFR session. 236 An important aspect to keep in mind is that the definition of AXFR is 237 restricted to TCP [RFC0793] (see Section 4 for details). The design 238 of the AXFR process has certain inherent features that are not easily 239 ported to UDP [RFC0768]. 241 The basic format of an AXFR message is the DNS message as defined in 242 Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the 243 following documents. 245 o The 'Basic' DNS specification: 247 - "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)" 248 [RFC1996] 249 - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] 250 - "Clarifications to the DNS Specification" [RFC2181] 251 - "Extension Mechanisms for DNS (EDNS0)" [RFC2671] 252 - "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] 253 - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] 254 - "Obsoleting IQUERY" [RFC3425] 255 - "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] 256 - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] 257 - "Domain Name System (DNS) IANA Considerations" [RFC5395] 259 o Further additions related to the DNS Security Extensions (DNSSEC), 260 defined in these base documents: 262 - "DNS Security Introduction and Requirements" [RFC4033] 263 - "Resource Records for the DNS Security Extensions" [RFC4034] 264 - "Protocol Modifications for the DNS Security Extensions" [RFC4035] 265 - "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509] 266 - "DNS Security Hashed Authenticated Denial of Existence" [RFC5155] 267 - "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource 268 Records for DNSSEC" [RFC5702] 269 - "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U] 271 These documents contain information about the syntax and semantics of 272 DNS messages. They do not interfere with AXFR but are also helpful 273 in understanding what will be carried via AXFR. 275 For convenience, the synopsis of the DNS message header from 276 [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is 277 reproduced here informally: 279 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 280 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 281 | ID | 282 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 283 |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | 284 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 285 | QDCOUNT/ZOCOUNT | 286 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 287 | ANCOUNT/PRCOUNT | 288 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 289 | NSCOUNT/UPCOUNT | 290 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 291 | ARCOUNT | 292 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 294 This document makes use of the field names as they appear in this 295 diagram. The names of sections in the body of DNS messages are 296 capitalized in this document for clarity, e.g., "Additional section". 298 The DNS message size limit from [RFC1035] for DNS over UDP (and its 299 extension via the EDNS0 mechanism specified in [RFC2671]) is not 300 relevant for AXFR, as explained in Section 4. The upper limit on the 301 permissible size of a DNS message over TCP is only restricted by the 302 TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a 303 two-octet message length field, understood to be unsigned, and thus 304 causing a limit of 65535 octets. This limit is not changed by EDNS0. 306 Note that the TC (truncation) bit is never set by an AXFR server nor 307 considered/read by an AXFR client. 309 2.1. AXFR query 311 An AXFR query is sent by a client whenever there is a reason to ask. 312 This might be because of scheduled or triggered zone maintenance 313 activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], 314 respectively) or as a result of a command line request, say for 315 debugging. 317 2.1.1. Header Values 319 These are the DNS message header values for an AXFR query. 321 ID Selected by client; see Note a) 323 QR MUST be 0 (Query) 325 OPCODE MUST be 0 (Standard Query) 327 Flags: 328 AA 'n/a' -- see Note b) 329 TC 'n/a' -- see Note b) 330 RD 'n/a' -- see Note b) 331 RA 'n/a' -- see Note b) 332 Z 'mbz' -- see Note c) 333 AD 'n/a' -- see Note b) 334 CD 'n/a' -- see Note b) 336 RCODE MUST be 0 (No error) 338 QDCOUNT Number of entries in Question section; MUST be 1 340 ANCOUNT Number of entries in Answer section; MUST be 0 342 NSCOUNT Number of entries in Authority section; MUST be 0 344 ARCOUNT Number of entries in Additional section -- see Note d) 346 Notes: 348 a) Set to any value that the client is not already using with the 349 same server. There is no specific means for selecting the value 350 in this field. (Recall that AXFR is done only via TCP connections 351 -- see Section 4 "Transport".) 353 A server MUST reply using messages that use the same message ID to 354 allow a client to have multiple queries outstanding concurrently 355 over the same TCP connection -- see Note a) in Section 2.2.1 for 356 more details. 358 b) 'n/a' -- The value in this field has no meaning in the context of 359 AXFR query messages. For the client, it is RECOMMENDED that the 360 value be zero. The server MUST ignore this value. 362 c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore 363 it. 365 d) The client MUST set this field to the number of resource records 366 it places into the Additional section. In the absence of explicit 367 specification of new RRs to be carried in the Additional section 368 of AXFR queries, the value MAY be 0, 1 or 2. See Section 2.1.5 369 "Additional Section" for details on the currently applicable RRs. 371 2.1.2. Question Section 373 The Question section of the AXFR query MUST conform to Section 4.1.2 374 of RFC 1035, and contain a single resource record with the following 375 values: 377 QNAME the name of the zone requested 379 QTYPE AXFR (= 252), the pseudo-RR type for zone transfer 380 [DNSVALS] 382 QCLASS the class of the zone requested [DNSVALS] 384 2.1.3. Answer Section 386 The Answer section MUST be empty. 388 2.1.4. Authority Section 390 The Authority section MUST be empty. 392 2.1.5. Additional Section 394 Currently, two kinds of resource records are defined that can appear 395 in the Additional section of AXFR queries and responses: EDNS and DNS 396 transaction security. Future specifications defining RRs that can be 397 carried in the Additional section of normal DNS transactions need to 398 explicitly describe their use with AXFR, should that be desired. 400 The client MAY include one OPT resource record [RFC2671]. If 401 the server does not support EDNS0, the client MUST send this section 402 without an OPT resource record if there is a retry. However, 403 the protocol does not define an explicit indication that the server 404 does not support EDNS0; that needs to be inferred by the client. 405 Often, the server will return a FormErr(1) which might be related to 406 the OPT resource record. Note that, at the time of this writing, 407 only the EXTENDED-RCODE field of the OPT RR is meaningful in 408 the context of AXFR; future specifications of EDNS flags and/or 409 EDNS options must describe their usage in the context of AXFR, if 410 applicable. 412 The client MAY include one transaction integrity and authentication 413 resource record, currently a choice of TSIG [RFC2845] or SIG(0) 415 [RFC2931]. If the server has indicated that it does not recognize 416 the resource record, and that the error is indeed caused by the 417 resource record, the client probably should not try again. Removing 418 the security data in the face of an obstacle ought to only be done 419 with full awareness of the implication of doing so. 421 In general, if an AXFR client is aware that an AXFR server does not 422 support a particular mechanism, the client SHOULD NOT attempt to 423 engage the server using the mechanism (or at all). A client could 424 become aware of a server's abilities via a configuration setting or 425 via some other (as yet) undefined means. 427 The range of permissible resource records that MAY appear in the 428 Additional section might change over time. If either a change to an 429 existing resource record (like the OPT RR for EDNS) is made or a new 430 Additional section record is created, the new definitions ought to 431 include a discussion on the applicability and impact upon AXFR. 432 Future resource records residing in the Additional section might have 433 an effect that is orthogonal to AXFR, so can ride through the session 434 as opaque data. In this case, a "wise" implementation ought to be 435 able to pass these records through without disruption. 437 2.2. AXFR Response 439 The AXFR response will consist of one or more messages. The special 440 case of a server closing the TCP connection without sending an AXFR 441 response is covered in section 2.3. 443 An AXFR response that is transferring the zone's contents will 444 consist of a series (which could be a series of length 1) of DNS 445 messages. In such a series, the first message MUST begin with the 446 SOA resource record of the zone, the last message MUST conclude with 447 the same SOA resource record. Intermediate messages MUST NOT contain 448 the SOA resource record. The AXFR server MUST copy the Question 449 section from the corresponding AXFR query message into the first 450 response message's Question section. For subsequent messages, it MAY 451 do the same or leave the Question section empty. 453 The AXFR protocol treats the zone contents as an unordered collection 454 (or to use the mathematical term, a "set") of RRs. Except for the 455 requirement that the transfer must begin and end with the SOA RR, 456 there is no requirement to send the RRs in any particular order or 457 grouped into response messages in any particular way. Although 458 servers typically do attempt to send related RRs (such as the RRs 459 forming an RRset, and the RRsets of a name) as a contiguous group or, 460 when message space allows, in the same response message, they are not 461 required to do so, and clients MUST accept any ordering and grouping 462 of the non-SOA RRs. Each RR SHOULD be transmitted only once, and 463 AXFR clients MUST ignore any duplicate RRs received. 465 Each AXFR response message SHOULD contain a sufficient number of RRs 466 to reasonably amortize the per-message overhead, up to the largest 467 number that will fit within a DNS message (taking the required 468 content of the other sections into account, as described below). 469 Some old AXFR clients expect each response message to contain only a 470 single RR. To interoperate with such clients, the server MAY 471 restrict response messages to a single RR. As there is no standard 472 way to automatically detect such clients, this typically requires 473 manual configuration at the server. 475 To indicate an error in an AXFR response, the AXFR server sends a 476 single DNS message when the error condition is detected, with the 477 response code set to the appropriate value for the condition 478 encountered, Such a message terminates the AXFR session; it MUST 479 contain a copy of the Question section from the AXFR query in its 480 Question section, but the inclusion of the terminating SOA resource 481 record is not necessary. 483 An AXFR server may send a number of AXFR response messages free of an 484 error condition before it sends the message indicating an error. 486 2.2.1. Header Values 488 These are the DNS message header values for AXFR responses. 490 ID MUST be copied from request -- see Note a) 492 QR MUST be 1 (Response) 494 OPCODE MUST be 0 (Standard Query) 496 Flags: 497 AA normally 1 -- see Note b) 498 TC MUST be 0 (Not truncated) 499 RD RECOMMENDED: copy request's value, MAY be set to 0 500 RA SHOULD be 0 -- see Note c) 501 Z 'mbz' -- see Note d) 502 AD 'mbz' -- see Note d) 503 CD 'mbz' -- see Note d) 505 RCODE See Note e) 507 QDCOUNT MUST be 1 in the first message; 508 MUST be 0 or 1 in all following messages; 509 MUST be 1 if RCODE indicates an error 511 ANCOUNT See Note f) 513 NSCOUNT MUST be 0 514 ARCOUNT See Note g) 516 Notes: 518 a) Because some old implementations behave differently than is now 519 desired, the requirement on this field is stated in detail. New 520 DNS servers MUST set this field to the value of the AXFR query ID 521 in each AXFR response message for the session. AXFR clients MUST 522 be able to manage sessions resulting from the issuance of multiple 523 outstanding queries, whether AXFR queries or other DNS queries. 524 A client SHOULD discard responses that do not correspond (via the 525 message ID) to any outstanding queries. 527 Unless the client is sure that the server will consistently set 528 the ID field to the query's ID, the client is NOT RECOMMENDED to 529 issue any other queries until the end of the zone transfer. 530 A client MAY become aware of a server's abilities via a 531 configuration setting. 533 b) If the RCODE is 0 (no error), then the AA bit MUST be 1. 534 For any other value of RCODE, the AA bit MUST be set according to 535 the rules for that error code. If in doubt, it is RECOMMENDED 536 that it be set to 1. It is RECOMMENDED that the value be ignored 537 by the AXFR client. 539 c) It is RECOMMENDED that the server set the value to 0, the client 540 MUST ignore this value. 542 The server MAY set this value according to the local policy 543 regarding recursive service, but doing so might confuse the 544 interpretation of the response as AXFR can not be retrieved 545 recursively. A client MAY note the server's policy regarding 546 recursive service from this value, but SHOULD NOT conclude that 547 the AXFR response was obtained recursively even if the RD bit was 548 1 in the query. 550 d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore 551 it. 553 e) In the absence of an error, the server MUST set the value of this 554 field to NoError(0). If a server is not authoritative for the 555 queried zone, the server SHOULD set the value to NotAuth(9). 556 (Reminder, consult the appropriate IANA registry [DNSVALS].) If a 557 client receives any other value in response, it MUST act according 558 to the error. For example, a malformed AXFR query or the presence 559 of an OPT resource record sent to an old server will result 560 in a FormErr(1) value. This value is not set as part of the AXFR- 561 specific response processing. The same is true for other values 562 indicating an error. 564 f) The count of answer records MUST equal the number of resource 565 records in the AXFR Answer Section. When a server is aware that a 566 client will only accept response messages with a single resource 567 record, then the value MUST be 1. A server MAY be made aware of a 568 client's limitations via configuration data. 570 g) The server MUST set this field to the number of resource records 571 it places into the Additional section. In the absence of explicit 572 specification of new RRs to be carried in the Additional section 573 of AXFR response messages, the value MAY be 0, 1 or 2. See 574 Section 2.1.5 above for details on the currently applicable RRs 575 and Section 2.2.5 for additional considerations specific to AXFR 576 servers. 578 2.2.2. Question Section 580 In the first response message, this section MUST be copied from the 581 query. In subsequent messages, this section MAY be copied from the 582 query or it MAY be empty. However, in an error response message (see 583 Section 2.2), this section MUST be copied as well. The content of 584 this section MAY be used to determine the context of the message, 585 that is, the name of the zone being transferred. 587 2.2.3. Answer Section 589 The Answer section MUST be populated with the zone contents. See 590 Section 3 below on encoding zone contents. 592 2.2.4. Authority Section 594 The Authority section MUST be empty. 596 2.2.5. Additional Section 598 The contents of this section MUST follow the guidelines for the OPT, 599 TSIG, and SIG(0) RRs, or whatever other future record is possible 600 here. The contents of Section 2.1.5 apply analogously as well. 602 The following considerations specifically apply to AXFR responses: 604 If the client has supplied an EDNS OPT RR in the AXFR query and if 605 the server supports EDNS as well, it SHOULD include one OPT RR 606 in the first response message and MAY do so in subsequent response 607 messages (see Section 2.2); the specifications of EDNS options to be 608 carried in the OPT RR may impose stronger requirements. 610 If the client has supplied a transaction security resource record 611 (currently a choice of TSIG and SIG(0)) and the server supports the 612 method chosen by the client, it MUST place the corresponding resource 613 record into the AXFR response message(s), according to the rules 614 specified for that method. 616 2.3. TCP Connection Aborts 618 If an AXFR client sends a query on a TCP connection and the 619 connection is closed at any point, the AXFR client MUST consider the 620 AXFR session terminated. The message ID MAY be used again on a new 621 connection, even if the question and AXFR server are the same. 623 Facing a dropped connection, a client SHOULD try to make some 624 determination as to whether the connection closure was the result of 625 network activity or due to a decision by the AXFR server. This 626 determination is not an exact science. It is up to the AXFR client 627 to react, but the implemented reaction SHOULD NOT be either an 628 endless cycle of retries or an increasing (in frequency) retry rate. 630 An AXFR server implementor should take into consideration the dilemma 631 described above when a connection is closed with an outstanding query 632 in the pipeline. For this reason, a server ought to reserve this 633 course of action for situations in which it believes beyond a doubt 634 that the AXFR client is attempting abusive behavior. 636 3. Zone Contents 638 The objective of the AXFR session is to request and transfer the 639 contents of a zone, in order to permit the AXFR client to faithfully 640 reconstruct the zone as it exists at the primary server for the given 641 zone serial number. The word "exists" here designates the externally 642 visible behavior, i.e., the zone content that is being served (handed 643 out to clients) -- not its persistent representation in a zone file 644 or database used by the server -- and that for consistency should be 645 served subsequently by the AXFR client in an identical manner. 647 Over time the definition of a zone has evolved from denoting a static 648 set of records to also cover a dynamically updated set of records, 649 and then a potentially continually regenerated set of records (e.g., 650 RRs synthesized "on the fly" from rule sets or database lookup 651 results in other forms than RR format) as well. 653 3.1. Records to Include 655 In the Answer section of AXFR response messages, the resource records 656 within a zone for the given serial number MUST appear. The 657 definition of what belongs in a zone is described in RFC 1034, 658 Section 4.2, "How the database is divided into zones" (in particular 659 Section 4.2.1, "Technical considerations"), and it has been clarified 660 in Section 6 of RFC 2181. 662 Zones for which it is impractical to list the entire zone for a 663 serial number are not suitable for AXFR retrieval. A typical (but 664 not limiting) description of such a zone is a zone consisting of 665 responses generated via other database lookups and/or computed based 666 upon ever changing data. 668 3.2. Delegation Records 670 In Section 4.2.1 of RFC 1034, this text appears (keep in mind that 671 the "should" in the quotation predates [BCP14], cf. Section 1.1): 673 "The RRs that describe cuts ... should be exactly the same as the 674 corresponding RRs in the top node of the subzone." 676 There has been some controversy over this statement and the impact on 677 which NS resource records are included in a zone transfer. 679 The phrase "that describe cuts" is a reference to the NS set and 680 applicable glue records. It does not mean that the cut point and 681 apex resource records are identical. For example, the SOA resource 682 record is only found at the apex. The discussion here is restricted 683 to just the NS resource record set and glue as these "describe cuts". 685 DNSSEC resource records have special specifications regarding their 686 occurrence at a zone cut and the apex of a zone. This was first 687 described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial 688 specification of DNSSEC), which parts of RFC 2181 now in fact are 689 historical. The current DNSSEC core document set (see second bullet 690 in Section 2 above) gives the full details for DNSSEC(bis) resource 691 record placement, and Section 3.1.5 of RFC 4035 normatively specifies 692 their treatment during AXFR; the alternate NSEC3 resource record 693 defined later in RFC 5155 behaves identically as the NSEC RR, for the 694 purpose of AXFR. 695 Informally: 697 o The DS RRSet only occurs at the parental side of a zone cut and is 698 authoritative data in the parent zone, not the secure child zone. 700 o The DNSKEY RRSet only occurs at the APEX of a signed zone and is 701 part of the authoritative data of the zone it serves. 703 o Independent RRSIG RRSets occur at the signed parent side of a zone 704 cut and at the apex of a signed zone; they are authoritative data 705 in the respective zone; simple queries for RRSIG resource records 706 may return both RRSets at once if the same server is authoritative 707 for the parent zone and the child zone (Section 3.1.5 of RFC 4035 708 describes how to distinguish these RRs); this seeming ambiguity 709 does not occur for AXFR, since each such RRSIG RRset belongs to a 710 single zone. 712 o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records 713 equally may occur at the parental side of a zone cut and at the 714 apex of a zone; each such resource record belongs to exactly one 715 of these zones and is to be included in the AXFR of that zone. 717 One issue is that in operations there are times when the NS resource 718 records for a zone might be different at a cut point in the parent 719 and at the apex of a zone. Sometimes this is the result of an error 720 and sometimes it is part of an ongoing change in name servers. The 721 DNS protocol is robust enough to overcome inconsistencies up to (but 722 not including) there being no parent-indicated NS resource record 723 referencing a server that is able to serve the child zone. This 724 robustness is one quality that has fueled the success of the DNS. 725 Still, the inconsistency is an error state and steps need to be taken 726 to make it apparent (if it is unplanned) and to make it clear once 727 the inconsistency has been removed. 729 Another issue is that the AXFR server could be authoritative for a 730 different set of zones than the AXFR client. It is possible that the 731 AXFR server be authoritative for both halves of an inconsistent cut 732 point and that the AXFR client is authoritative for just the parent 733 side of the cut point. 735 When facing a situation in which a cut point's NS resource records do 736 not match the authoritative set, the question arises whether an AXFR 737 server responds with the NS resource record set that is in the zone 738 being transferred or the one that is at the authoritative location. 740 The AXFR response MUST contain the cut point NS resource record set 741 registered with the zone whether it agrees with the authoritative set 742 or not. "Registered with" can be widely interpreted to include data 743 residing in the zone file of the zone for the particular serial 744 number (in zone file environments) or as any data configured to be in 745 the zone (database), statically or dynamically. 747 The reasons for this requirement are: 749 1) The AXFR server might not be able to determine that there is an 750 inconsistency given local data, hence requiring consistency would 751 mean a lot more needed work and even network retrieval of data. An 752 authoritative server ought not be required to perform any queries. 754 2) By transferring the inconsistent NS resource records from a server 755 that is authoritative for both the cut point and the apex to a client 756 that is not authoritative for both, the error is exposed. For 757 example, an authorized administrator can manually request the AXFR 758 and inspect the results to see the inconsistent records. (A server 759 authoritative for both halves would otherwise always answer from the 760 more authoritative set, concealing the error.) 761 3) The inconsistent NS resource record set might indicate a problem 762 in a registration database. 764 4) This requirement is necessary to ensure that retrieving a given 765 (zone,serial) pair by AXFR yields the exact same set of resource 766 records no matter which of the zone's authoritative servers is chosen 767 as the source of the transfer. 769 If an AXFR server were allowed to respond with the authoritative NS 770 RRset of a child zone instead of a parent-side NS RRset in the zone 771 being transferred, the set of records returned could vary depending 772 on whether or not the server happened to be authoritative for the 773 child zone as well. 775 The property that a given (zone,serial) pair corresponds to a single, 776 well-defined set of records is necessary for the correct operation of 777 incremental transfer protocols such as IXFR [RFC1995]. For example, 778 a client may retrieve a zone by AXFR from one server, and then apply 779 an incremental change obtained by IXFR from a different server. If 780 the two servers have different ideas of the zone contents, the client 781 can end up attempting to incrementally add records that already exist 782 or to delete records that do not exist. 784 3.3. Glue Records 786 As quoted in the previous section, Section 4.2.1 of RFC 1034 provides 787 guidance and rationale for the inclusion of glue records as part of 788 an AXFR transfer. And, as also argued in the previous section of 789 this document, even when there is an inconsistency between the 790 address in a glue record and the authoritative copy of the name 791 server's address, the glue resource record that is registered as part 792 of the zone for that serial number is to be included. 794 This applies to glue records for any address family [IANA-AF]. 796 The AXFR response MUST contain the appropriate glue records as 797 registered with the zone. The interpretation of "registered with" in 798 the previous section applies here. Inconsistent glue records are an 799 operational matter. 801 3.4. Name Compression 803 Compression of names in DNS messages is described in RFC 1035, 804 Section 4.1.4, "Message compression". The issue highlighted here 805 relates to a comment made in RFC 1034, Section 3.1, "Name space 806 specifications and terminology" which says "When you receive a domain 807 name or label, you should preserve its case." ("Should" in the quote 808 predates [BCP14].) 809 Since the primary objective of AXFR is to enable the client to serve 810 the same zone content as the server, unlike such normal DNS responses 811 that are expected to preserve the case in the query, the actual zone 812 transfer needs to retain the case of the labels in the zone content. 813 Hence, name compression in an AXFR message SHOULD be performed in a 814 case-preserving manner, unlike how it is done for 'normal' DNS 815 responses. That is, although when comparing a domain name for 816 matching, "a" equals "A", when comparing for the purposes of message 817 compression for AXFR, "a" is not equal to "A". Note that this is not 818 the usual definition of name comparison in the DNS protocol and 819 represents a new understanding of the requirement on AXFR servers. 821 Rules governing name compression of RDATA in an AXFR message MUST 822 abide by the specification in "Handling of Unknown DNS Resource 823 Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name 824 Compression". 826 3.5. Occluded Names 828 Dynamic Update [RFC2136] operations, and in particular its 829 interaction with DNAME [RFC2672], can have a side effect of occluding 830 names in a zone. The addition of a delegation point via dynamic 831 update will render all subordinate domain names to be in a limbo, 832 still part of the zone but not available to the lookup process. The 833 addition of a DNAME resource record has the same impact. The 834 subordinate names are said to be "occluded". 836 Occluded names MUST be included in AXFR responses. An AXFR client 837 MUST be able to identify and handle occluded names. The rationale 838 for this action is based on a speedy recovery if the dynamic update 839 operation was in error and is to be undone. 841 4. Transport 843 AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC 844 1034 that states: "Because accuracy is essential, TCP or some other 845 reliable protocol must be used for AXFR requests." The restriction 846 to TCP is also mentioned in Section 6.1.3.2. of "Requirements for 847 Internet Hosts - Application and Support" [RFC1123]. 849 The most common scenario is for an AXFR client to open a TCP 850 connection to the AXFR server, send an AXFR query, receive the AXFR 851 response, and then close the connection. But variations of that most 852 simple scenario are legitimate and likely: in particular, sending a 853 query for the zone's SOA resource record first over the same TCP 854 connection, and reusing an existing TCP connection for other queries. 856 Therefore, the assumption that a TCP connection is dedicated to a 857 single AXFR session is incorrect. This wrong assumption has led to 858 implementation choices that prevent either multiple concurrent zone 859 transfers or the use of an open connection for other queries. 861 Since the early days of the DNS, operators who have sets of name 862 servers that are authoritative for a common set of zones found it 863 desirable to be able to have multiple concurrent zone transfers in 864 progress; this way a name server does not have to wait for one zone 865 transfer to complete before the next can begin. RFC 1035 did not 866 exclude this possibility, but legacy implementations failed to 867 support this functionality efficiently, over a single TCP connection. 868 The remaining presence of such legacy implementations makes it 869 necessary that new general purpose client implementations still 870 provide options for graceful fallback to the old behavior in their 871 support of concurrent DNS transactions and AXFR sessions on a single 872 TCP connection. 874 4.1. TCP 876 In the original definition there arguably is an implicit assumption 877 (probably unintentional) that a TCP connection is used for one and 878 only one AXFR session. This is evidenced in the lack of an explicit 879 requirement to copy the Question section and/or the message ID into 880 responses, no explicit ordering information within the AXFR response 881 messages, and the lack of an explicit notice indicating that a zone 882 transfer continues in the next message. 884 The guidance given below is intended to enable better performance of 885 the AXFR exchange as well as provide guidelines on interactions with 886 older software. Better performance includes being able to multiplex 887 DNS message exchanges including zone transfer sessions. Guidelines 888 for interacting with older software are generally applicable to new 889 AXFR clients. In the reverse situation, older AXFR client and newer 890 AXFR server, the server ought to operate within the specification for 891 an older server. 893 4.1.1. AXFR client TCP 895 An AXFR client MAY request a connection to an AXFR server for any 896 reason. An AXFR client SHOULD close the connection when there is no 897 apparent need to use the connection for some time period. The AXFR 898 server ought not have to maintain idle connections; the burden of 899 connection closure ought to be on the client. "Apparent need" for 900 the connection is a judgment for the AXFR client and the DNS client. 901 If the connection is used for multiple sessions, or if it is known 902 sessions will be coming, or if there is other query/response traffic 903 anticipated or currently on the open connection, then there is 904 "apparent need". 906 An AXFR client can cancel the delivery of a zone only by closing the 907 connection. However, this action will also cancel all other 908 outstanding activity using the connection. There is no other 909 mechanism by which an AXFR response can be cancelled. 911 When a TCP connection is closed remotely (relative to the client), 912 whether by the AXFR server or due to a network event, the AXFR client 913 MUST cancel all outstanding sessions and non-AXFR transactions. 914 Recovery from this situation is not straightforward. If the 915 disruption was a spurious event, attempting to restart the connection 916 would be proper. If the disruption was caused by a failure that 917 proved to be persistent, the AXFR client would be wise not to spend 918 too many resources trying to rebuild the connection. Finally, if the 919 connection was dropped because of a policy at the AXFR server (as can 920 be the case with older AXFR servers), the AXFR client would be wise 921 not to retry the connection. Unfortunately, knowing which of the 922 three cases above (momentary disruption, failure, policy) applies is 923 not possible with certainty, and can only be assessed by heuristics. 924 This exemplifies the general complications for clients in connection- 925 oriented protocols not receiving meaningful error responses. 927 An AXFR client MAY use an already opened TCP connection to start an 928 AXFR session. Using an existing open connection is RECOMMENDED over 929 opening a new connection. (Non-AXFR session traffic can also use an 930 open connection.) If in doing so the AXFR client realizes that the 931 responses cannot be properly differentiated (lack of matching query 932 IDs for example) or the connection is terminated for a remote reason, 933 then the AXFR client SHOULD NOT attempt to reuse an open connection 934 with the specific AXFR server until the AXFR server is updated (which 935 is, of course, not an event captured in the DNS protocol). 937 4.1.2. AXFR server TCP 939 An AXFR server MUST be able to handle multiple AXFR sessions on a 940 single TCP connection, as well as to handle other query/response 941 transactions over it. 943 If a TCP connection is closed remotely, the AXFR server MUST cancel 944 all AXFR sessions in place. No retry activity is necessary; that is 945 initiated by the AXFR client. 947 Local policy MAY dictate that a TCP connection is to be closed. Such 948 an action SHOULD be in reaction to limits such as those placed on the 949 number of outstanding open connections. Closing a connection in 950 response to a suspected security event SHOULD be done only in extreme 951 cases, when the server is certain the action is warranted. An 952 isolated request for a zone not on the AXFR server SHOULD receive a 953 response with the appropriate response code and not see the 954 connection broken. 956 4.2. UDP 958 With the addition of EDNS0 and applications which require many small 959 zones such as in web hosting and some ENUM scenarios, AXFR sessions 960 on UDP would now seem desirable. However, there are still some 961 aspects of AXFR sessions that are not easily translated to UDP. 963 Therefore, this document does not update RFC 1035 in this respect: 964 AXFR sessions over UDP transport are not defined. 966 5. Authorization 968 A zone administrator has the option to restrict AXFR access to a 969 zone. This was not envisioned in the original design of the DNS but 970 has emerged as a requirement as the DNS has evolved. Restrictions on 971 AXFR could be for various reasons including a desire (or in some 972 instances, having a legal requirement) to keep the bulk version of 973 the zone concealed or to prevent the servers from handling the load 974 incurred in serving AXFR. It has been argued that these reasons are 975 questionable, but this document, driven by the desire to leverage the 976 interoperable practice that has evolved since RFC 1035, acknowledges 977 the factual requirement to provide mechanisms to restrict AXFR. 979 A DNS implementation SHOULD provide means to restrict AXFR sessions 980 to specific clients. 982 An implementation SHOULD allow access to be granted to Internet 983 Protocol addresses and ranges, regardless of whether a source address 984 could be spoofed. Combining this with techniques such as Virtual 985 Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be 986 effective. 988 A general purpose implementation is RECOMMENDED to implement access 989 controls based upon "Secret Key Transaction Authentication for DNS" 990 [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" 991 [RFC2931]. 993 A general purpose implementation SHOULD allow access to be open to 994 all AXFR requests. I.e., an operator ought to be able to allow any 995 AXFR query to be granted. 997 A general purpose implementation SHOULD NOT have a default policy for 998 AXFR requests to be "open to all". For example, a default could be 999 to restrict transfers to addresses selected by the DNS 1000 administrator(s) for zones on the server. 1002 6. Zone Integrity 1004 An AXFR client MUST ensure that only a successfully transferred copy 1005 of the zone data can be used to serve this zone. Previous 1006 description and implementation practice have introduced a two-stage 1007 model of the whole zone synchronization procedure: Upon a trigger 1008 event (e.g., polling of a SOA resource record detects change in the 1009 SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is 1010 initiated, whereby the zone data are saved in a zone file or data 1011 base (this latter step is necessary anyway to ensure proper restart 1012 of the server); upon successful completion of the AXFR operation and 1013 some sanity checks, this data set is 'loaded' and made available for 1014 serving the zone in an atomic operation, and flagged 'valid' for use 1015 during the next restart of the DNS server; if any error is detected, 1016 this data set MUST be deleted, and the AXFR client MUST continue to 1017 serve the previous version of the zone, if it did before. The 1018 externally visible behavior of an AXFR client implementation MUST be 1019 equivalent to that of this two-stage model. 1021 If an AXFR client rejects data contained in an AXFR session, it 1022 SHOULD remember the serial number and MAY attempt to retrieve the 1023 same zone version again. The reason the same retrieval could make 1024 sense is that the reason for the rejection could be rooted in an 1025 implementation detail of one AXFR server used for the zone and not 1026 present in another AXFR server used for the zone. 1028 Ensuring that an AXFR client does not accept a forged copy of a zone 1029 is important to the security of a zone. If a zone operator has the 1030 opportunity, protection can be afforded via dedicated links, physical 1031 or virtual via a VPN among the authoritative servers. But there are 1032 instances in which zone operators have no choice but to run AXFR 1033 sessions over the global public Internet. 1035 Besides best attempts at securing TCP connections, DNS 1036 implementations SHOULD provide means to make use of "Secret Key 1037 Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and 1038 Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients 1039 to verify the contents. These techniques MAY also be used for 1040 authorization. 1042 7. Backwards Compatibility 1044 Describing backwards compatibility is difficult because of the lack 1045 of specifics in the original definition. In this section some hints 1046 at building in backwards compatibility are given, mostly repeated 1047 from the relevant earlier sections. 1049 Backwards compatibility is not necessary, but the greater the extent 1050 of an implementation's compatibility the greater its 1051 interoperability. For turnkey implementations this is not usually a 1052 concern. For general purpose implementations this takes on varying 1053 levels of importance depending on the implementer's desire to 1054 maintain interoperability. 1056 It is unfortunate that a need to fall back to older behavior cannot 1057 be discovered, hence needs to be noted in a configuration file. An 1058 implementation SHOULD, in its documentation, encourage operators to 1059 periodically review AXFR clients and servers it has made notes about 1060 repeatedly, as old software gets updated from time to time. 1062 7.1. Server 1064 An AXFR server has the luxury of being able to react to an AXFR 1065 client's abilities with the exception of knowing whether the client 1066 can accept multiple resource records per AXFR response message. The 1067 knowledge that a client is so restricted cannot be discovered, hence 1068 it has to be set by configuration. 1070 An implementation of an AXFR server MAY permit configuring, on a per 1071 AXFR client basis, the necessity to revert to single resource record 1072 per message; in that case, the default SHOULD be to use multiple 1073 records per message. 1075 7.2. Client 1077 An AXFR client has the opportunity to try other features (i.e., those 1078 not defined by this document) when querying an AXFR server. 1080 Attempting to issue multiple DNS queries over a TCP transport for an 1081 AXFR session SHOULD be aborted if it interrupts the original request, 1082 and SHOULD take into consideration whether the AXFR server intends to 1083 close the connection immediately upon completion of the original 1084 (connection-causing) zone transfer. 1086 8. Security Considerations 1088 This document is a clarification of a mechanism outlined in RFCs 1034 1089 and 1035 and as such does not add any new security considerations. 1090 RFC 3833 [RFC3833] is devoted entirely to security considerations for 1091 the DNS; its Section 4.3 delineates zone transfer security aspects 1092 from the security threats addressed by DNSSEC. 1094 Concerns regarding authorization, traffic flooding, and message 1095 integrity are mentioned in "Authorization" (Section 5), "TCP" 1096 (Section 4.2) and "Zone Integrity" (Section 6). 1098 9. IANA Considerations 1100 IANA has added a reference to this RFC in the AXFR (252) row of the 1101 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System 1102 (DNS) Parameters" registry. 1104 10. Internationalization Considerations 1106 The AXFR protocol is transparent to the parts of DNS zone content 1107 that can possibly be subject to Internationalization considerations. 1108 It is assumed that for DNS labels and domain names, the issue has 1109 been solved via "Internationalizing Domain Names in Applications 1110 (IDNA)" [RFC3490] or its successor(s). 1112 11. Acknowledgments 1114 Earlier editions of this document have been edited by Andreas 1115 Gustafsson. In his latest version, this acknowledgment appeared: 1117 "Many people have contributed input and commentary to earlier 1118 versions of this document, including but not limited to Bob Halley, 1119 Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert 1120 Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam 1121 Trenholme, and Brian Wellington." 1123 Comments since the -05 version have come from these individuals: 1124 Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, 1125 Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly, 1126 Bill Manning, and other participants of the DNSEXT working group. 1128 Edward Lewis served as a patiently listening sole document editor for 1129 two years. 1131 12. References 1133 All "RFC" references by can be obtained from the RFC Editor web site 1134 at the URLs: http://rfc-editor.org/rfc.html 1135 or http://rfc-editor.org/rfcsearch.html ; 1136 information regarding this organization can be found at the following 1137 URL: http://rfc-editor.org/ 1139 12.1. Normative References 1141 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, March 1997. 1144 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1145 RFC 793, September 1981. 1147 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1148 August 1980. 1150 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1151 STD 13, RFC 1034, November 1987. 1153 [RFC1035] Mockapetris, P., "Domain names - implementation and 1154 specification", STD 13, RFC 1035, November 1987. 1156 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1157 and Support", STD 3, RFC 1123, October 1989. 1159 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1160 August 1996. 1162 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1163 Changes (DNS NOTIFY)", RFC 1996, August 1996. 1165 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1166 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1167 RFC 2136, April 1997. 1169 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1170 Specification", RFC 2181, July 1997. 1172 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1173 RFC 2671, August 1999. 1175 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 1176 RFC 2672, August 1999. 1178 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1179 Wellington, "Secret Key Transaction Authentication for DNS 1180 (TSIG)", RFC 2845, May 2000. 1182 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 1183 RR)", RFC 2930, September 2000. 1185 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1186 ( SIG(0)s )", RFC 2931, September 2000. 1188 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, 1189 November 2002. 1191 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1192 (RR) Types", RFC 3597, September 2003. 1194 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1195 Rose, "DNS Security Introduction and Requirements", 1196 RFC 4033, March 2005. 1198 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1199 Rose, "Resource Records for the DNS Security Extensions", 1200 RFC 4034, March 2005. 1202 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1203 Rose, "Protocol Modifications for the DNS Security 1204 Extensions", RFC 4035, March 2005. 1206 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 1207 (DS) Resource Records (RRs)", RFC 4509, May 2006 1209 [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication 1210 Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", 1211 RFC 4635, August 2006. 1213 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1214 Security (DNSSEC) Hashed Authenticated Denial of 1215 Existence", RFC 5155, March 2008 1217 [RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA 1218 Considerations", BCP 42, RFC 5395, November 2008. 1220 [RFC5702] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY 1221 and RRSIG Resource Records for DNSSEC", RFC 5702, 1222 October 2009. 1224 12.2. Informative References 1226 [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", 1227 http://www.iana.org/assignments/dns-parameters 1229 [IANA-AF] IANA Registry "Address Family Numbers", 1230 http://www.iana.org/assignments/Address-family-numbers/ . 1232 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 1233 Malis, "A Framework for IP Based Virtual Private 1234 Networks", RFC 2764, February 2000. 1236 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1237 "Internationalizing Domain Names in Applications (IDNA)", 1238 RFC 3490, March 2003. 1240 [RFC3833] Atkins, D., and R. Austein, "Threat Analysis of the Domain 1241 Name System (DNS)", RFC 3833, August 2004. 1243 [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and 1244 Implementation Notes for DNSSECbis", 1245 draft-ietf-dnsext-dnssec-bis-updates-10 (work in 1246 progress), March 2010. 1248 Authors' Addresses 1250 Edward Lewis 1251 46000 Center Oak Plaza 1252 Sterling, VA, 22033, US 1254 Email: ed.lewis@neustar.biz 1256 Alfred Hoenes, Editor 1257 TR-Sys 1258 Gerlinger Str. 12 1259 Ditzingen D-71254 1260 Germany 1262 Email: ah@TR-Sys.de 1264 Editorial Note: Discussion [[ to be removed by RFC-Editor ]] 1266 Comments on this draft ought to be addressed to the editors and/or to 1267 namedroppers@ops.ietf.org.