1 Internet Engineering Task Force (IETF) E. Lewis
2 Request for Comments: 5936 NeuStar, Inc.
3 Updates: 1034, 1035 A. Hoenes, Ed.
4 Category: Standards Track TR-Sys
5 ISSN: 2070-1721 June 2010
6
7
8 DNS Zone Transfer Protocol (AXFR)
9
10 Abstract
11
12 The standard means within the Domain Name System protocol for
13 maintaining coherence among a zone's authoritative name servers
14 consists of three mechanisms. Authoritative Transfer (AXFR) is one
15 of the mechanisms and is defined in RFC 1034 and RFC 1035.
16
17 The definition of AXFR has proven insufficient in detail, thereby
18 forcing implementations intended to be compliant to make assumptions,
19 impeding interoperability. Yet today we have a satisfactory set of
20 implementations that do interoperate. This document is a new
21 definition of AXFR -- new in the sense that it records an accurate
22 definition of an interoperable AXFR mechanism.
23
24 Status of This Memo
25
26 This is an Internet Standards Track document.
27
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 5741.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc5936.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Lewis & Hoenes Standards Track [Page 1]
53 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
54
55
56 Copyright Notice
57
58 Copyright (c) 2010 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Lewis & Hoenes Standards Track [Page 2]
108 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
109
110
111 Table of Contents
112
113 1. Introduction ....................................................4
114 1.1. Definition of Terms ........................................4
115 1.2. Scope ......................................................5
116 1.3. Context ....................................................5
117 1.4. Coverage and Relationship to Original AXFR Specification ...5
118 2. AXFR Messages ...................................................6
119 2.1. AXFR Query .................................................8
120 2.1.1. Header Values .......................................8
121 2.1.2. Question Section ...................................10
122 2.1.3. Answer Section .....................................10
123 2.1.4. Authority Section ..................................10
124 2.1.5. Additional Section .................................10
125 2.2. AXFR Response .............................................11
126 2.2.1. Header Values ......................................12
127 2.2.2. Question Section ...................................14
128 2.2.3. Answer Section .....................................14
129 2.2.4. Authority Section ..................................14
130 2.2.5. Additional Section .................................14
131 2.3. TCP Connection Aborts .....................................15
132 3. Zone Contents ..................................................15
133 3.1. Records to Include ........................................15
134 3.2. Delegation Records ........................................16
135 3.3. Glue Records ..............................................18
136 3.4. Name Compression ..........................................19
137 3.5. Occluded Names ............................................19
138 4. Transport ......................................................20
139 4.1. TCP .......................................................20
140 4.1.1. AXFR Client TCP ....................................21
141 4.1.2. AXFR Server TCP ....................................22
142 4.2. UDP .......................................................22
143 5. Authorization ..................................................22
144 6. Zone Integrity .................................................23
145 7. Backwards Compatibility ........................................24
146 7.1. Server ....................................................24
147 7.2. Client ....................................................25
148 8. Security Considerations ........................................25
149 9. IANA Considerations ............................................25
150 10. Internationalization Considerations ...........................25
151 11. Acknowledgments ...............................................25
152 12. References ....................................................26
153 12.1. Normative References .....................................26
154 12.2. Informative References ...................................28
155
156
157
158
159
160
161
162 Lewis & Hoenes Standards Track [Page 3]
163 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
164
165
166 1. Introduction
167
168 The Domain Name System standard facilities for maintaining coherent
169 servers for a zone consist of three elements. Authoritative Transfer
170 (AXFR) is defined in "Domain Names - Concepts and Facilities"
171 [RFC1034] (referred to in this document as RFC 1034) and "Domain
172 Names - Implementation and Specification" [RFC1035] (henceforth RFC
173 1035). Incremental Zone Transfer (IXFR) is defined in "Incremental
174 Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification
175 of zone changes (NOTIFY) is defined in "A Mechanism for Prompt
176 Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of
177 these mechanisms is to enable a set of DNS name servers to remain
178 coherently authoritative for a given zone.
179
180 This document re-specifies the AXFR mechanism as it is deployed in
181 the Internet at large, hopefully with the precision expected from
182 modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
183
184 1.1. Definition of Terms
185
186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
188 document are to be interpreted as described in "Key words for use in
189 RFCs to Indicate Requirement Levels" [BCP14].
190
191 Use of "newer"/"new" and "older"/"old" DNS refers to implementations
192 written after and prior to the publication of this document.
193
194 "General-purpose DNS implementation" refers to DNS software developed
195 for widespread use. This includes resolvers and servers freely
196 accessible as libraries and standalone processes. This also includes
197 proprietary implementations used only in support of DNS service
198 offerings.
199
200 "Turnkey DNS implementation" refers to custom-made, single-use
201 implementations of DNS. Such implementations consist of software
202 that employs the DNS protocol message format yet does not conform to
203 the entire range of DNS functionality.
204
205 The terms "AXFR session", "AXFR server", and "AXFR client" will be
206 introduced in the first paragraph of Section 2, after some more
207 context has been established.
208
209
210
211
212
213
214
215
216
217 Lewis & Hoenes Standards Track [Page 4]
218 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
219
220
221 1.2. Scope
222
223 In general terms, authoritative name servers for a given zone can use
224 various means to achieve coherency of the zone contents they serve.
225 For example, there are DNS implementations that assemble answers from
226 data stored in relational databases (as opposed to master files),
227 relying on the database's non-DNS means to synchronize the database
228 instances. Some of these non-DNS solutions interoperate in some
229 fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-
230 defined in-band mechanisms to provide coherence of a set of name
231 servers, and they are the only mechanisms specified by the IETF.
232
233 This document does not cover incoherent DNS situations. There are
234 applications of the DNS in which servers for a zone are designed to
235 be incoherent. For these configurations, a coherency mechanism as
236 described here would be unsuitable.
237
238 A DNS implementation is not required to support AXFR, IXFR, and
239 NOTIFY, but it should have some means for maintaining name server
240 coherency. A general-purpose DNS implementation will likely support
241 AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
242 implementations may exist without AXFR.
243
244 1.3. Context
245
246 Besides describing the mechanisms themselves, there is the context in
247 which they operate to consider. In the initial specifications of
248 AXFR (and IXFR and NOTIFY), little consideration was given to
249 security and privacy issues. Since the original definition of AXFR,
250 new opinions have appeared on the access to an entire zone's
251 contents. In this document, the basic mechanisms will be discussed
252 separately from the permission to use these mechanisms.
253
254 1.4. Coverage and Relationship to Original AXFR Specification
255
256 This document concentrates on just the definition of AXFR. Any
257 effort to update the specification of the IXFR or NOTIFY mechanisms
258 is left to different documents.
259
260 The original "specification" of the AXFR sub-protocol is scattered
261 through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5)
262 depicts the scenario for which AXFR has been designed. Section 4.3.5
263 of RFC 1034 describes the zone synchronization strategies in general
264 and rules for the invocation of a full zone transfer via AXFR; the
265 fifth paragraph of that section contains a very short sketch of the
266 AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
267 flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
268 the code point for the AXFR QTYPE (see Section 2.1.2 below for more
269
270
271
272 Lewis & Hoenes Standards Track [Page 5]
273 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
274
275
276 details). Section 4.2 of RFC 1035 discusses how the DNS uses the
277 transport layer and briefly explains why UDP transport is deemed
278 inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
279 details regarding TCP connection management for AXFR. Finally, the
280 second paragraph of Section 6.3 in RFC 1035 mandates server behavior
281 when zone data changes occur during an ongoing zone transfer using
282 AXFR.
283
284 This document will update the specification of AXFR. To this end, it
285 fully specifies the record formats and processing rules for AXFR,
286 largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
287 details the transport considerations for AXFR, thus amending Section
288 4.2.2 of RFC 1035. Furthermore, it discusses backward-compatibility
289 issues and provides policy/management considerations, as well as
290 specific security considerations for AXFR. The goal of this document
291 is to define AXFR as it is understood by the DNS community to exist
292 today.
293
294 2. AXFR Messages
295
296 An AXFR session consists of an AXFR query message and the sequence of
297 AXFR response messages returned for it. In this document, the AXFR
298 client is the sender of the AXFR query, and the AXFR server is the
299 responder. (Use of terms such as master, slave, primary, and
300 secondary are not important for defining AXFR.) The use of the word
301 "session" without qualification refers to an AXFR session.
302
303 An important aspect to keep in mind is that the definition of AXFR is
304 restricted to TCP [RFC0793] (see Section 4 for details). The design
305 of the AXFR process has certain inherent features that are not easily
306 ported to UDP [RFC0768].
307
308 The basic format of an AXFR message is the DNS message as defined in
309 Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
310 following documents.
311
312 o The "Basic" DNS specification:
313
314 - "A Mechanism for Prompt Notification of Zone Changes
315 (DNS NOTIFY)" [RFC1996]
316
317 - "Dynamic Updates in the Domain Name System (DNS UPDATE)"
318 [RFC2136]
319
320 - "Clarifications to the DNS Specification" [RFC2181]
321
322 - "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
323
324
325
326
327 Lewis & Hoenes Standards Track [Page 6]
328 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
329
330
331 - "Secret Key Transaction Authentication for DNS (TSIG)"
332 [RFC2845]
333
334 - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
335
336 - "Obsoleting IQUERY" [RFC3425]
337
338 - "Handling of Unknown DNS Resource Record (RR) Types"
339 [RFC3597]
340
341 - "HMAC SHA (Hashed Message Authentication Code, Secure Hash
342 Algorithm) TSIG Algorithm Identifiers" [RFC4635]
343
344 - "Domain Name System (DNS) IANA Considerations" [RFC5395]
345
346 o Further additions related to the DNS Security Extensions (DNSSEC),
347 defined in these base documents:
348
349 - "DNS Security Introduction and Requirements" [RFC4033]
350
351 - "Resource Records for the DNS Security Extensions"
352 [RFC4034]
353
354 - "Protocol Modifications for the DNS Security Extensions"
355 [RFC4035]
356
357 - "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource
358 Records (RRs)" [RFC4509]
359
360 - "DNS Security (DNSSEC) Hashed Authenticated Denial of
361 Existence" [RFC5155]
362
363 - "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG
364 Resource Records for DNSSEC" [RFC5702]
365
366 - "Clarifications and Implementation Notes for DNSSECbis"
367 [DNSSEC-U]
368
369 These documents contain information about the syntax and semantics of
370 DNS messages. They do not interfere with AXFR but are also helpful
371 in understanding what will be carried via AXFR.
372
373 For convenience, the synopsis of the DNS message header from
374 [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
375 reproduced here informally:
376
377
378
379
380
381
382 Lewis & Hoenes Standards Track [Page 7]
383 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
384
385
386 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
387 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
388 | ID |
389 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
390 |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
391 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
392 | QDCOUNT/ZOCOUNT |
393 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
394 | ANCOUNT/PRCOUNT |
395 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
396 | NSCOUNT/UPCOUNT |
397 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
398 | ARCOUNT |
399 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
400
401 This document makes use of the field names as they appear in this
402 diagram. The names of sections in the body of DNS messages are
403 capitalized in this document for clarity, e.g., "Additional section".
404
405 The DNS message size limit from [RFC1035] for DNS over UDP (and its
406 extension via the EDNS0 mechanism specified in [RFC2671]) is not
407 relevant for AXFR, as explained in Section 4. The upper limit on the
408 permissible size of a DNS message over TCP is only restricted by the
409 TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
410 two-octet message length field, understood to be unsigned, and thus
411 causing a limit of 65535 octets. This limit is not changed by EDNS0.
412
413 Note that the TC (truncation) bit is never set by an AXFR server nor
414 considered/read by an AXFR client.
415
416 2.1. AXFR Query
417
418 An AXFR query is sent by a client whenever there is a reason to ask.
419 This might be because of scheduled or triggered zone maintenance
420 activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
421 respectively) or as a result of a command line request, say for
422 debugging.
423
424 2.1.1. Header Values
425
426 These are the DNS message header values for an AXFR query.
427
428 ID Selected by client; see Note a)
429
430 QR MUST be 0 (Query)
431
432 OPCODE MUST be 0 (Standard Query)
433
434
435
436
437 Lewis & Hoenes Standards Track [Page 8]
438 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
439
440
441 Flags:
442 AA "n/a" -- see Note b)
443 TC "n/a" -- see Note b)
444 RD "n/a" -- see Note b)
445 RA "n/a" -- see Note b)
446 Z "mbz" -- see Note c)
447 AD "n/a" -- see Note b)
448 CD "n/a" -- see Note b)
449
450 RCODE MUST be 0 (No error)
451
452 QDCOUNT Number of entries in Question section; MUST be 1
453
454 ANCOUNT Number of entries in Answer section; MUST be 0
455
456 NSCOUNT Number of entries in Authority section; MUST be 0
457
458 ARCOUNT Number of entries in Additional section -- see Note d)
459
460 Notes:
461
462 a) Set to any value that the client is not already using with the
463 same server. There is no specific means for selecting the value
464 in this field. (Recall that AXFR is done only via TCP connections
465 -- see Section 4, "Transport".)
466
467 A server MUST reply using messages that use the same message ID to
468 allow a client to have multiple queries outstanding concurrently
469 over the same TCP connection -- see Note a) in Section 2.2.1 for
470 more details.
471
472 b) "n/a" -- The value in this field has no meaning in the context of
473 AXFR query messages. For the client, it is RECOMMENDED that the
474 value be zero. The server MUST ignore this value.
475
476 c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore
477 it.
478
479 d) The client MUST set this field to the number of resource records
480 it places into the Additional section. In the absence of explicit
481 specification of new RRs to be carried in the Additional section
482 of AXFR queries, the value MAY be 0, 1, or 2. See Section 2.1.5,
483 "Additional Section", for details on the currently applicable RRs.
484
485
486
487
488
489
490
491
492 Lewis & Hoenes Standards Track [Page 9]
493 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
494
495
496 2.1.2. Question Section
497
498 The Question section of the AXFR query MUST conform to Section 4.1.2
499 of RFC 1035, and contain a single resource record with the following
500 values:
501
502 QNAME the name of the zone requested
503
504 QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
505 [DNSVALS]
506
507 QCLASS the class of the zone requested [DNSVALS]
508
509 2.1.3. Answer Section
510
511 The Answer section MUST be empty.
512
513 2.1.4. Authority Section
514
515 The Authority section MUST be empty.
516
517 2.1.5. Additional Section
518
519 Currently, two kinds of resource records are defined that can appear
520 in the Additional section of AXFR queries and responses: EDNS and DNS
521 transaction security. Future specifications defining RRs that can be
522 carried in the Additional section of normal DNS transactions need to
523 explicitly describe their use with AXFR, should that be desired.
524
525 The client MAY include one OPT resource record [RFC2671]. If the
526 server does not support EDNS0, the client MUST send this section
527 without an OPT resource record if there is a retry. However, the
528 protocol does not define an explicit indication that the server does
529 not support EDNS0; that needs to be inferred by the client. Often,
530 the server will return a FormErr(1) that might be related to the OPT
531 resource record. Note that, at the time of this writing, only the
532 EXTENDED-RCODE field of the OPT RR is meaningful in the context of
533 AXFR; future specifications of EDNS flags and/or EDNS options must
534 describe their usage in the context of AXFR, if applicable.
535
536 The client MAY include one transaction integrity and authentication
537 resource record, currently a choice of TSIG [RFC2845] or SIG(0)
538 [RFC2931]. If the server has indicated that it does not recognize
539 the resource record, and that the error is indeed caused by the
540 resource record, the client probably should not try again. Removing
541 the security data in the face of an obstacle ought to only be done
542 with full awareness of the implication of doing so.
543
544
545
546
547 Lewis & Hoenes Standards Track [Page 10]
548 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
549
550
551 In general, if an AXFR client is aware that an AXFR server does not
552 support a particular mechanism, the client SHOULD NOT attempt to
553 engage the server using the mechanism (or engage the server at all).
554 A client could become aware of a server's abilities via a
555 configuration setting or via some other (as yet) undefined means.
556
557 The range of permissible resource records that MAY appear in the
558 Additional section might change over time. If either a change to an
559 existing resource record (like the OPT RR for EDNS) is made or a new
560 Additional section record is created, the new definitions ought to
561 include a discussion on the applicability and impact upon AXFR.
562 Future resource records residing in the Additional section might have
563 an effect that is orthogonal to AXFR, and so can ride through the
564 session as opaque data. In this case, a "wise" implementation ought
565 to be able to pass these records through without disruption.
566
567 2.2. AXFR Response
568
569 The AXFR response will consist of one or more messages. The special
570 case of a server closing the TCP connection without sending an AXFR
571 response is covered in Section 2.3.
572
573 An AXFR response that is transferring the zone's contents will
574 consist of a series (which could be a series of length 1) of DNS
575 messages. In such a series, the first message MUST begin with the
576 SOA resource record of the zone, and the last message MUST conclude
577 with the same SOA resource record. Intermediate messages MUST NOT
578 contain the SOA resource record. The AXFR server MUST copy the
579 Question section from the corresponding AXFR query message into the
580 first response message's Question section. For subsequent messages,
581 it MAY do the same or leave the Question section empty.
582
583 The AXFR protocol treats the zone contents as an unordered collection
584 (or to use the mathematical term, a "set") of RRs. Except for the
585 requirement that the transfer must begin and end with the SOA RR,
586 there is no requirement to send the RRs in any particular order or
587 grouped into response messages in any particular way. Although
588 servers typically do attempt to send related RRs (such as the RRs
589 forming an RRset, and the RRsets of a name) as a contiguous group or,
590 when message space allows, in the same response message, they are not
591 required to do so, and clients MUST accept any ordering and grouping
592 of the non-SOA RRs. Each RR SHOULD be transmitted only once, and
593 AXFR clients MUST ignore any duplicate RRs received.
594
595 Each AXFR response message SHOULD contain a sufficient number of RRs
596 to reasonably amortize the per-message overhead, up to the largest
597 number that will fit within a DNS message (taking the required
598 content of the other sections into account, as described below).
599
600
601
602 Lewis & Hoenes Standards Track [Page 11]
603 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
604
605
606 Some old AXFR clients expect each response message to contain only a
607 single RR. To interoperate with such clients, the server MAY
608 restrict response messages to a single RR. As there is no standard
609 way to automatically detect such clients, this typically requires
610 manual configuration at the server.
611
612 To indicate an error in an AXFR response, the AXFR server sends a
613 single DNS message when the error condition is detected, with the
614 response code set to the appropriate value for the condition
615 encountered. Such a message terminates the AXFR session; it MUST
616 contain a copy of the Question section from the AXFR query in its
617 Question section, but the inclusion of the terminating SOA resource
618 record is not necessary.
619
620 An AXFR server may send a number of AXFR response messages free of an
621 error condition before it sends the message indicating an error.
622
623 2.2.1. Header Values
624
625 These are the DNS message header values for AXFR responses.
626
627 ID MUST be copied from request -- see Note a)
628
629 QR MUST be 1 (Response)
630
631 OPCODE MUST be 0 (Standard Query)
632
633 Flags:
634 AA normally 1 -- see Note b)
635 TC MUST be 0 (Not truncated)
636 RD RECOMMENDED: copy request's value; MAY be set to 0
637 RA SHOULD be 0 -- see Note c)
638 Z "mbz" -- see Note d)
639 AD "mbz" -- see Note d)
640 CD "mbz" -- see Note d)
641
642 RCODE See Note e)
643
644 QDCOUNT MUST be 1 in the first message;
645 MUST be 0 or 1 in all following messages;
646 MUST be 1 if RCODE indicates an error
647
648 ANCOUNT See Note f)
649
650 NSCOUNT MUST be 0
651
652 ARCOUNT See Note g)
653
654
655
656
657 Lewis & Hoenes Standards Track [Page 12]
658 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
659
660
661 Notes:
662
663 a) Because some old implementations behave differently than is now
664 desired, the requirement on this field is stated in detail. New
665 DNS servers MUST set this field to the value of the AXFR query ID
666 in each AXFR response message for the session. AXFR clients MUST
667 be able to manage sessions resulting from the issuance of multiple
668 outstanding queries, whether AXFR queries or other DNS queries. A
669 client SHOULD discard responses that do not correspond (via the
670 message ID) to any outstanding queries.
671
672 Unless the client is sure that the server will consistently set
673 the ID field to the query's ID, the client is NOT RECOMMENDED to
674 issue any other queries until the end of the zone transfer. A
675 client MAY become aware of a server's abilities via a
676 configuration setting.
677
678 b) If the RCODE is 0 (no error), then the AA bit MUST be 1. For any
679 other value of RCODE, the AA bit MUST be set according to the
680 rules for that error code. If in doubt, it is RECOMMENDED that it
681 be set to 1. It is RECOMMENDED that the value be ignored by the
682 AXFR client.
683
684 c) It is RECOMMENDED that the server set the value to 0; the client
685 MUST ignore this value.
686
687 The server MAY set this value according to the local policy
688 regarding recursive service, but doing so might confuse the
689 interpretation of the response, as AXFR cannot be retrieved
690 recursively. A client MAY note the server's policy regarding
691 recursive service from this value, but SHOULD NOT conclude that
692 the AXFR response was obtained recursively, even if the RD bit was
693 1 in the query.
694
695 d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore
696 it.
697
698 e) In the absence of an error, the server MUST set the value of this
699 field to NoError(0). If a server is not authoritative for the
700 queried zone, the server SHOULD set the value to NotAuth(9).
701 (Reminder: Consult the appropriate IANA registry [DNSVALS].) If a
702 client receives any other value in response, it MUST act according
703 to the error. For example, a malformed AXFR query or the presence
704 of an OPT resource record sent to an old server will result in a
705 FormErr(1) value. This value is not set as part of the AXFR-
706 specific response processing. The same is true for other values
707 indicating an error.
708
709
710
711
712 Lewis & Hoenes Standards Track [Page 13]
713 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
714
715
716 f) The count of answer records MUST equal the number of resource
717 records in the AXFR Answer section. When a server is aware that a
718 client will only accept response messages with a single resource
719 record, then the value MUST be 1. A server MAY be made aware of a
720 client's limitations via configuration data.
721
722 g) The server MUST set this field to the number of resource records
723 it places into the Additional section. In the absence of explicit
724 specification of new RRs to be carried in the Additional section
725 of AXFR response messages, the value MAY be 0, 1, or 2. See
726 Section 2.1.5 above for details on the currently applicable RRs
727 and Section 2.2.5 for additional considerations specific to AXFR
728 servers.
729
730 2.2.2. Question Section
731
732 In the first response message, this section MUST be copied from the
733 query. In subsequent messages, this section MAY be copied from the
734 query, or it MAY be empty. However, in an error response message
735 (see Section 2.2), this section MUST be copied as well. The content
736 of this section MAY be used to determine the context of the message,
737 that is, the name of the zone being transferred.
738
739 2.2.3. Answer Section
740
741 The Answer section MUST be populated with the zone contents. See
742 Section 3 below on encoding zone contents.
743
744 2.2.4. Authority Section
745
746 The Authority section MUST be empty.
747
748 2.2.5. Additional Section
749
750 The contents of this section MUST follow the guidelines for the OPT,
751 TSIG, and SIG(0) RRs, or whatever other future record is possible
752 here. The contents of Section 2.1.5 apply analogously as well.
753
754 The following considerations specifically apply to AXFR responses:
755
756 If the client has supplied an EDNS OPT RR in the AXFR query and if
757 the server supports EDNS as well, it SHOULD include one OPT RR in the
758 first response message and MAY do so in subsequent response messages
759 (see Section 2.2); the specifications of EDNS options to be carried
760 in the OPT RR may impose stronger requirements.
761
762
763
764
765
766
767 Lewis & Hoenes Standards Track [Page 14]
768 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
769
770
771 If the client has supplied a transaction security resource record
772 (currently a choice of TSIG and SIG(0)) and the server supports the
773 method chosen by the client, it MUST place the corresponding resource
774 record into the AXFR response message(s), according to the rules
775 specified for that method.
776
777 2.3. TCP Connection Aborts
778
779 If an AXFR client sends a query on a TCP connection and the
780 connection is closed at any point, the AXFR client MUST consider the
781 AXFR session terminated. The message ID MAY be used again on a new
782 connection, even if the question and AXFR server are the same.
783
784 Facing a dropped connection, a client SHOULD try to make some
785 determination as to whether the connection closure was the result of
786 network activity or due to a decision by the AXFR server. This
787 determination is not an exact science. It is up to the AXFR client
788 to react, but the implemented reaction SHOULD NOT be either an
789 endless cycle of retries or an increasing (in frequency) retry rate.
790
791 An AXFR server implementer should take into consideration the dilemma
792 described above when a connection is closed with an outstanding query
793 in the pipeline. For this reason, a server ought to reserve this
794 course of action for situations in which it believes beyond a doubt
795 that the AXFR client is attempting abusive behavior.
796
797 3. Zone Contents
798
799 The objective of the AXFR session is to request and transfer the
800 contents of a zone, in order to permit the AXFR client to faithfully
801 reconstruct the zone as it exists at the primary server for the given
802 zone serial number. The word "exists" here designates the externally
803 visible behavior, i.e., the zone content that is being served (handed
804 out to clients) -- not its persistent representation in a zone file
805 or database used by the server -- and that for consistency should be
806 served subsequently by the AXFR client in an identical manner.
807
808 Over time the definition of a zone has evolved from denoting a static
809 set of records to also cover a dynamically updated set of records,
810 and then a potentially continually regenerated set of records (e.g.,
811 RRs synthesized "on the fly" from rule sets or database lookup
812 results in other forms than RR format) as well.
813
814 3.1. Records to Include
815
816 In the Answer section of AXFR response messages, the resource records
817 within a zone for the given serial number MUST appear. The
818 definition of what belongs in a zone is described in RFC 1034,
819
820
821
822 Lewis & Hoenes Standards Track [Page 15]
823 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
824
825
826 Section 4.2, "How the database is divided into zones" (in particular
827 Section 4.2.1, "Technical considerations"), and it has been clarified
828 in Section 6 of RFC 2181.
829
830 Zones for which it is impractical to list the entire zone for a
831 serial number are not suitable for AXFR retrieval. A typical (but
832 not limiting) description of such a zone is a zone consisting of
833 responses generated via other database lookups and/or computed based
834 upon ever-changing data.
835
836 3.2. Delegation Records
837
838 In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
839 the "should" in the quotation predates [BCP14], cf. Section 1.1):
840
841 The RRs that describe cuts ... should be exactly the same as the
842 corresponding RRs in the top node of the subzone.
843
844 There has been some controversy over this statement and the impact on
845 which NS resource records are included in a zone transfer.
846
847 The phrase "that describe cuts" is a reference to the NS set and
848 applicable glue records. It does not mean that the cut point and
849 apex resource records are identical. For example, the SOA resource
850 record is only found at the apex. The discussion here is restricted
851 to just the NS resource record set and glue, as these "describe
852 cuts".
853
854 DNSSEC resource records have special specifications regarding their
855 occurrence at a zone cut and the apex of a zone. This was first
856 described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
857 specification of DNSSEC), which parts of RFC 2181 now in fact are
858 historical. The current DNSSEC core document set (see second bullet
859 in Section 2 above) gives the full details for DNSSEC(bis) resource
860 record placement, and Section 3.1.5 of RFC 4035 normatively specifies
861 their treatment during AXFR; the alternate NSEC3 resource record
862 defined later in RFC 5155 behaves identically to the NSEC RR, for the
863 purpose of AXFR.
864
865 Informally:
866
867 o The DS RRSet only occurs at the parental side of a zone cut and is
868 authoritative data in the parent zone, not the secure child zone.
869
870 o The DNSKEY RRSet only occurs at the apex of a signed zone and is
871 part of the authoritative data of the zone it serves.
872
873
874
875
876
877 Lewis & Hoenes Standards Track [Page 16]
878 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
879
880
881 o Independent RRSIG RRSets occur at the signed parent side of a zone
882 cut and at the apex of a signed zone; they are authoritative data
883 in the respective zone; simple queries for RRSIG resource records
884 may return both RRSets at once if the same server is authoritative
885 for the parent zone and the child zone (Section 3.1.5 of RFC 4035
886 describes how to distinguish these RRs); this seeming ambiguity
887 does not occur for AXFR, since each such RRSIG RRset belongs to a
888 single zone.
889
890 o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
891 equally may occur at the parental side of a zone cut and at the
892 apex of a zone; each such resource record belongs to exactly one
893 of these zones and is to be included in the AXFR of that zone.
894
895 One issue is that in operations there are times when the NS resource
896 records for a zone might be different at a cut point in the parent
897 and at the apex of a zone. Sometimes this is the result of an error,
898 and sometimes it is part of an ongoing change in name servers. The
899 DNS protocol is robust enough to overcome inconsistencies up to (but
900 not including) there being no parent-indicated NS resource record
901 referencing a server that is able to serve the child zone. This
902 robustness is one quality that has fueled the success of the DNS.
903 Still, the inconsistency is an error state, and steps need to be
904 taken to make it apparent (if it is unplanned).
905
906 Another issue is that the AXFR server could be authoritative for a
907 different set of zones than the AXFR client. It is possible that the
908 AXFR server be authoritative for both halves of an inconsistent cut
909 point and that the AXFR client is authoritative for just the parent
910 side of the cut point.
911
912 When facing a situation in which a cut point's NS resource records do
913 not match the authoritative set, the question arises whether an AXFR
914 server responds with the NS resource record set that is in the zone
915 being transferred or the one that is at the authoritative location.
916
917 The AXFR response MUST contain the cut point NS resource record set
918 registered with the zone whether it agrees with the authoritative set
919 or not. "Registered with" can be widely interpreted to include data
920 residing in the zone file of the zone for the particular serial
921 number (in zone file environments) or as any data configured to be in
922 the zone (database), statically or dynamically.
923
924
925
926
927
928
929
930
931
932 Lewis & Hoenes Standards Track [Page 17]
933 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
934
935
936 The reasons for this requirement are:
937
938 1) The AXFR server might not be able to determine that there is an
939 inconsistency given local data; hence, requiring consistency would
940 mean a lot more needed work and even network retrieval of data.
941 An authoritative server ought not be required to perform any
942 queries.
943
944 2) By transferring the inconsistent NS resource records from a server
945 that is authoritative for both the cut point and the apex to a
946 client that is not authoritative for both, the error is exposed.
947 For example, an authorized administrator can manually request the
948 AXFR and inspect the results to see the inconsistent records. (A
949 server authoritative for both halves would otherwise always answer
950 from the more authoritative set, concealing the error.)
951
952 3) The inconsistent NS resource record set might indicate a problem
953 in a registration database.
954
955 4) This requirement is necessary to ensure that retrieving a given
956 (zone, serial) pair by AXFR yields the exact same set of resource
957 records, no matter which of the zone's authoritative servers is
958 chosen as the source of the transfer.
959
960 If an AXFR server were allowed to respond with the authoritative NS
961 RRset of a child zone instead of a parent-side NS RRset in the zone
962 being transferred, the set of records returned could vary depending
963 on whether or not the server happened to be authoritative for the
964 child zone as well.
965
966 The property that a given (zone, serial) pair corresponds to a
967 single, well-defined set of records is necessary for the correct
968 operation of incremental transfer protocols such as IXFR [RFC1995].
969 For example, a client may retrieve a zone by AXFR from one server,
970 and then apply an incremental change obtained by IXFR from a
971 different server. If the two servers have different ideas of the
972 zone contents, the client can end up attempting to incrementally add
973 records that already exist or to delete records that do not exist.
974
975 3.3. Glue Records
976
977 As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
978 guidance and rationale for the inclusion of glue records as part of
979 an AXFR response. And, as also argued in the previous section of
980 this document, even when there is an inconsistency between the
981 address in a glue record and the authoritative copy of the name
982 server's address, the glue resource record that is registered as part
983 of the zone for that serial number is to be included.
984
985
986
987 Lewis & Hoenes Standards Track [Page 18]
988 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
989
990
991 This applies to glue records for any address family [IANA-AF].
992
993 The AXFR response MUST contain the appropriate glue records as
994 registered with the zone. The interpretation of "registered with" in
995 the previous section applies here. Inconsistent glue records are an
996 operational matter.
997
998 3.4. Name Compression
999
1000 Compression of names in DNS messages is described in RFC 1035,
1001 Section 4.1.4, "Message compression". The issue highlighted here
1002 relates to a comment made in RFC 1034, Section 3.1, "Name space
1003 specifications and terminology", which says:
1004
1005 When you receive a domain name or label, you should preserve its
1006 case.
1007
1008 ("Should" in the quote predates [BCP14].)
1009
1010 Since the primary objective of AXFR is to enable the client to serve
1011 the same zone content as the server, unlike such normal DNS responses
1012 that are expected to preserve the case in the query, the actual zone
1013 transfer needs to retain the case of the labels in the zone content.
1014 Hence, name compression in an AXFR message SHOULD be performed in a
1015 case-preserving manner, unlike how it is done for "normal" DNS
1016 responses. That is, although when comparing a domain name for
1017 matching, "a" equals "A", when comparing for the purposes of message
1018 compression for AXFR, "a" is not equal to "A". Note that this is not
1019 the usual definition of name comparison in the DNS protocol and
1020 represents a new understanding of the requirement on AXFR servers.
1021
1022 Rules governing name compression of RDATA in an AXFR message MUST
1023 abide by the specification in "Handling of Unknown DNS Resource
1024 Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
1025 Compression".
1026
1027 3.5. Occluded Names
1028
1029 Dynamic Update [RFC2136] operations, and in particular their
1030 interaction with DNAME [RFC2672], can have a side effect of occluding
1031 names in a zone. The addition of a delegation point via dynamic
1032 update will render all subordinate domain names to be in a limbo,
1033 still part of the zone but not available to the lookup process. The
1034 addition of a DNAME resource record has the same impact. The
1035 subordinate names are said to be "occluded".
1036
1037
1038
1039
1040
1041
1042 Lewis & Hoenes Standards Track [Page 19]
1043 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1044
1045
1046 Occluded names MUST be included in AXFR responses. An AXFR client
1047 MUST be able to identify and handle occluded names. The rationale
1048 for this action is based on a speedy recovery if the dynamic update
1049 operation was in error and is to be undone.
1050
1051 4. Transport
1052
1053 AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
1054 1034, which states:
1055
1056 Because accuracy is essential, TCP or some other reliable protocol
1057 must be used for AXFR requests.
1058
1059 The restriction to TCP is also mentioned in Section 6.1.3.2 of
1060 "Requirements for Internet Hosts - Application and Support"
1061 [RFC1123].
1062
1063 The most common scenario is for an AXFR client to open a TCP
1064 connection to the AXFR server, send an AXFR query, receive the AXFR
1065 response, and then close the connection. But variations of that most
1066 simple scenario are legitimate and likely: in particular, sending a
1067 query for the zone's SOA resource record first over the same TCP
1068 connection, and reusing an existing TCP connection for other queries.
1069
1070 Therefore, the assumption that a TCP connection is dedicated to a
1071 single AXFR session is incorrect. This wrong assumption has led to
1072 implementation choices that prevent either multiple concurrent zone
1073 transfers or the use of an open connection for other queries.
1074
1075 Since the early days of the DNS, operators who have sets of name
1076 servers that are authoritative for a common set of zones have found
1077 it desirable to be able to have multiple concurrent zone transfers in
1078 progress; this way, a name server does not have to wait for one zone
1079 transfer to complete before the next can begin. RFC 1035 did not
1080 exclude this possibility, but legacy implementations failed to
1081 support this functionality efficiently, over a single TCP connection.
1082 The remaining presence of such legacy implementations makes it
1083 necessary that new general-purpose client implementations still
1084 provide options for graceful fallback to the old behavior in their
1085 support of concurrent DNS transactions and AXFR sessions on a single
1086 TCP connection.
1087
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
1088 4.1. TCP
1089
1090 In the original definition, there arguably is an implicit assumption
1091 (probably unintentional) that a TCP connection is used for one and
1092 only one AXFR session. This is evidenced in the lack of an explicit
1093 requirement to copy the Question section and/or the message ID into
1094
1095
1096
1097 Lewis & Hoenes Standards Track [Page 20]
1098 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1099
1100
1101 responses, no explicit ordering information within the AXFR response
1102 messages, and the lack of an explicit notice indicating that a zone
1103 transfer continues in the next message.
1104
1105 The guidance given below is intended to enable better performance of
1106 the AXFR exchange as well as provide guidelines on interactions with
1107 older software. Better performance includes being able to multiplex
1108 DNS message exchanges including zone transfer sessions. Guidelines
1109 for interacting with older software are generally applicable to new
1110 AXFR clients. In the reverse situation -- older AXFR client and
1111 newer AXFR server -- the server ought to operate within the
1112 specification for an older server.
1113
1114 4.1.1. AXFR Client TCP
1115
1116 An AXFR client MAY request a connection to an AXFR server for any
1117 reason. An AXFR client SHOULD close the connection when there is no
1118 apparent need to use the connection for some time period. The AXFR
1119 server ought not have to maintain idle connections; the burden of
1120 connection closure ought to be on the client. "Apparent need" for
1121 the connection is a judgment for the AXFR client and the DNS client.
1122 If the connection is used for multiple sessions, or if it is known
1123 that sessions will be coming, or if there is other query/response
1124 traffic anticipated or currently on the open connection, then there
1125 is "apparent need".
1126
1127 An AXFR client can cancel the delivery of a zone only by closing the
1128 connection. However, this action will also cancel all other
1129 outstanding activity using the connection. There is no other
1130 mechanism by which an AXFR response can be cancelled.
1131
1132 When a TCP connection is closed remotely (relative to the client),
1133 whether by the AXFR server or due to a network event, the AXFR client
1134 MUST cancel all outstanding sessions and non-AXFR transactions.
1135 Recovery from this situation is not straightforward. If the
1136 disruption was a spurious event, attempting to restart the connection
1137 would be proper. If the disruption was caused by a failure that
1138 proved to be persistent, the AXFR client would be wise not to spend
1139 too many resources trying to rebuild the connection. Finally, if the
1140 connection was dropped because of a policy at the AXFR server (as can
1141 be the case with older AXFR servers), the AXFR client would be wise
1142 not to retry the connection. Unfortunately, knowing which of the
1143 three cases above (momentary disruption, failure, policy) applies is
1144 not possible with certainty, and can only be assessed by heuristics.
1145 This exemplifies the general complications for clients in connection-
1146 oriented protocols not receiving meaningful error responses.
1147
1148
1149
1150
1151
1152 Lewis & Hoenes Standards Track [Page 21]
1153 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1154
1155
1156 An AXFR client MAY use an already opened TCP connection to start an
1157 AXFR session. Using an existing open connection is RECOMMENDED over
1158 opening a new connection. (Non-AXFR session traffic can also use an
1159 open connection.) If in doing so the AXFR client realizes that the
1160 responses cannot be properly differentiated (lack of matching query
1161 IDs, for example) or the connection is terminated for a remote
1162 reason, then the AXFR client SHOULD NOT attempt to reuse an open
1163 connection with the specific AXFR server until the AXFR server is
1164 updated (which is, of course, not an event captured in the DNS
1165 protocol).
1166
1167 4.1.2. AXFR Server TCP
1168
1169 An AXFR server MUST be able to handle multiple AXFR sessions on a
1170 single TCP connection, as well as to handle other query/response
1171 transactions over it.
1172
1173 If a TCP connection is closed remotely, the AXFR server MUST cancel
1174 all AXFR sessions in place. No retry activity is necessary; that is
1175 initiated by the AXFR client.
1176
1177 Local policy MAY dictate that a TCP connection is to be closed. Such
1178 an action SHOULD be in reaction to limits such as those placed on the
1179 number of outstanding open connections. Closing a connection in
1180 response to a suspected security event SHOULD be done only in extreme
1181 cases, when the server is certain the action is warranted. An
1182 isolated request for a zone not on the AXFR server SHOULD receive a
1183 response with the appropriate response code and not see the
1184 connection broken.
1185
1186 4.2. UDP
1187
1188 With the addition of EDNS0 and applications that require many small
1189 zones, such as in web hosting and some ENUM scenarios, AXFR sessions
1190 on UDP would now seem desirable. However, there are still some
1191 aspects of AXFR sessions that are not easily translated to UDP.
1192
1193 Therefore, this document does not update RFC 1035 in this respect:
1194 AXFR sessions over UDP transport are not defined.
1195
1196 5. Authorization
1197
1198 A zone administrator has the option to restrict AXFR access to a
1199 zone. This was not envisioned in the original design of the DNS but
1200 has emerged as a requirement as the DNS has evolved. Restrictions on
1201 AXFR could be for various reasons including a desire (or in some
1202 instances, having a legal requirement) to keep the bulk version of
1203 the zone concealed or to prevent the servers from handling the load
1204
1205
1206
1207 Lewis & Hoenes Standards Track [Page 22]
1208 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1209
1210
1211 incurred in serving AXFR. It has been argued that these reasons are
1212 questionable, but this document, driven by the desire to leverage the
1213 interoperable practice that has evolved since RFC 1035, acknowledges
1214 the factual requirement to provide mechanisms to restrict AXFR.
1215
1216 A DNS implementation SHOULD provide means to restrict AXFR sessions
1217 to specific clients.
1218
1219 An implementation SHOULD allow access to be granted to Internet
1220 Protocol addresses and ranges, regardless of whether a source address
1221 could be spoofed. Combining this with techniques such as Virtual
1222 Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be
1223 effective.
1224
1225 A general-purpose implementation is RECOMMENDED to implement access
1226 controls based upon "Secret Key Transaction Authentication for DNS
1227 (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures
1228 ( SIG(0)s )" [RFC2931].
1229
1230 A general-purpose implementation SHOULD allow access to be open to
1231 all AXFR requests. That is, an operator ought to be able to allow
1232 any AXFR query to be granted.
1233
1234 A general-purpose implementation SHOULD NOT have a default policy for
1235 AXFR requests to be "open to all". For example, a default could be
1236 to restrict transfers to addresses selected by the DNS
1237 administrator(s) for zones on the server.
1238
1239 6. Zone Integrity
1240
1241 An AXFR client MUST ensure that only a successfully transferred copy
1242 of the zone data can be used to serve this zone. Previous
1243 description and implementation practice has introduced a two-stage
1244 model of the whole zone synchronization procedure: Upon a trigger
1245 event (e.g., when polling of a SOA resource record detects a change
1246 in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is
1247 received), the AXFR session is initiated, whereby the zone data are
1248 saved in a zone file or database (this latter step is necessary
1249 anyway to ensure proper restart of the server); upon successful
1250 completion of the AXFR operation and some sanity checks, this data
1251 set is "loaded" and made available for serving the zone in an atomic
1252 operation, and flagged "valid" for use during the next restart of the
1253 DNS server; if any error is detected, this data set MUST be deleted,
1254 and the AXFR client MUST continue to serve the previous version of
1255 the zone, if it did before. The externally visible behavior of an
1256 AXFR client implementation MUST be equivalent to that of this two-
1257 stage model.
1258
1259
1260
1261
1262 Lewis & Hoenes Standards Track [Page 23]
1263 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1264
1265
1266 If an AXFR client rejects data obtained in an AXFR session, it SHOULD
1267 remember the serial number and MAY attempt to retrieve the same zone
1268 version again. The reason the same retrieval could make sense is
1269 that the reason for the rejection could be rooted in an
1270 implementation detail of one AXFR server used for the zone and not
1271 present in another AXFR server used for the zone.
1272
1273 Ensuring that an AXFR client does not accept a forged copy of a zone
1274 is important to the security of a zone. If a zone operator has the
1275 opportunity, protection can be afforded via dedicated links, physical
1276 or virtual via a VPN among the authoritative servers. But there are
1277 instances in which zone operators have no choice but to run AXFR
1278 sessions over the global public Internet.
1279
1280 Besides best attempts at securing TCP connections, DNS
1281 implementations SHOULD provide means to make use of "Secret Key
1282 Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS
1283 Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow
1284 AXFR clients to verify the contents. These techniques MAY also be
1285 used for authorization.
1286
1287 7. Backwards Compatibility
1288
1289 Describing backwards compatibility is difficult because of the lack
1290 of specifics in the original definition. In this section, some hints
1291 at building in backwards compatibility are given, mostly repeated
1292 from the relevant earlier sections.
1293
1294 Backwards compatibility is not necessary, but the greater the extent
1295 of an implementation's compatibility, the greater its
1296 interoperability. For turnkey implementations, this is not usually a
1297 concern. For general-purpose implementations, this takes on varying
1298 levels of importance, depending on the implementer's desire to
1299 maintain interoperability.
1300
1301 It is unfortunate that a need to fall back to older behavior cannot
1302 be discovered, and thus has to be noted in a configuration file. An
1303 implementation SHOULD, in its documentation, encourage operators to
1304 periodically review AXFR clients and servers it has made notes about
1305 repeatedly, as old software gets updated from time to time.
1306
1307 7.1. Server
1308
1309 An AXFR server has the luxury of being able to react to an AXFR
1310 client's abilities, with the exception of knowing whether the client
1311 can accept multiple resource records per AXFR response message. The
1312 knowledge that a client is so restricted cannot be discovered; hence,
1313 it has to be set by configuration.
1314
1315
1316
1317 Lewis & Hoenes Standards Track [Page 24]
1318 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1319
1320
1321 An implementation of an AXFR server MAY permit configuring, on a per
1322 AXFR client basis, the necessity to revert to a single resource
1323 record per message; in that case, the default SHOULD be to use
1324 multiple records per message.
1325
1326 7.2. Client
1327
1328 An AXFR client has the opportunity to try other features (i.e., those
1329 not defined by this document) when querying an AXFR server.
1330
1331 Attempting to issue multiple DNS queries over a TCP transport for an
1332 AXFR session SHOULD be aborted if it interrupts the original request,
1333 and SHOULD take into consideration whether the AXFR server intends to
1334 close the connection immediately upon completion of the original
1335 (connection-causing) zone transfer.
1336
1337 8. Security Considerations
1338
1339 This document is a clarification of a mechanism outlined in RFCs 1034
1340 and 1035 and as such does not add any new security considerations.
1341 RFC 3833 [RFC3833] is devoted entirely to security considerations for
1342 the DNS; its Section 4.3 delineates zone transfer security aspects
1343 from the security threats addressed by DNSSEC.
1344
1345 Concerns regarding authorization, traffic flooding, and message
1346 integrity are mentioned in "Authorization" (Section 5), "TCP"
1347 (Section 4.1), and "Zone Integrity" (Section 6).
1348
1349 9. IANA Considerations
1350
1351 IANA has added a reference to this RFC in the AXFR (252) row of the
1352 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
1353 (DNS) Parameters" registry.
1354
1355 10. Internationalization Considerations
1356
1357 The AXFR protocol is transparent to the parts of DNS zone content
1358 that can possibly be subject to Internationalization considerations.
1359 It is assumed that for DNS labels and domain names, the issue has
1360 been solved via "Internationalizing Domain Names in Applications
1361 (IDNA)" [RFC3490] or its successor(s).
1362
1363 11. Acknowledgments
1364
1365 Earlier draft versions of this document have been edited by Andreas
1366 Gustafsson. In his latest draft version, this acknowledgment
1367 appeared:
1368
1369
1370
1371
1372 Lewis & Hoenes Standards Track [Page 25]
1373 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1374
1375
1376 Many people have contributed input and commentary to earlier
1377 versions of this document, including but not limited to Bob
1378 Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin
1379 Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton,
1380 Peter Koch, Sam Trenholme, and Brian Wellington.
1381
1382 Comments on later draft versions have come from these individuals:
1383 Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
1384 Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
1385 Bill Manning, and other participants of the DNSEXT working group.
1386 Significant comments from the IETF at large have been received from
1387 Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani.
1388
1389 Edward Lewis served as a patiently listening sole document editor for
1390 two years.
1391
1392 12. References
1393
1394 All "RFC" references below -- like all RFCs -- and information about
1395 the RFC series can be obtained from the RFC Editor web site at
1396 http://www.rfc-editor.org.
1397
1398 12.1. Normative References
1399
1400 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
1401 Requirement Levels", BCP 14, RFC 2119, March 1997.
1402
1403 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
1404 793, September 1981.
1405
1406 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
1407 August 1980.
1408
1409 [RFC1034] Mockapetris, P., "Domain names - concepts and
1410 facilities", STD 13, RFC 1034, November 1987.
1411
1412 [RFC1035] Mockapetris, P., "Domain names - implementation and
1413 specification", STD 13, RFC 1035, November 1987.
1414
1415 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
1416 Application and Support", STD 3, RFC 1123, October 1989.
1417
1418 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1419 August 1996.
1420
1421 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
1422 Changes (DNS NOTIFY)", RFC 1996, August 1996.
1423
1424
1425
1426
1427 Lewis & Hoenes Standards Track [Page 26]
1428 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1429
1430
1431 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
1432 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1433 RFC 2136, April 1997.
1434
1435 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1436 Specification", RFC 2181, July 1997.
1437
1438 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
1439 2671, August 1999.
1440
1441 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
1442 2672, August 1999.
1443
1444 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
1445 Wellington, "Secret Key Transaction Authentication for
1446 DNS (TSIG)", RFC 2845, May 2000.
1447
1448 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
1449 RR)", RFC 2930, September 2000.
1450
1451 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
1452 ( SIG(0)s )", RFC 2931, September 2000.
1453
1454 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
1455 2002.
1456
1457 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
1458 (RR) Types", RFC 3597, September 2003.
1459
1460 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1461 Rose, "DNS Security Introduction and Requirements", RFC
1462 4033, March 2005.
1463
1464 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1465 Rose, "Resource Records for the DNS Security Extensions",
1466 RFC 4034, March 2005.
1467
1468 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1469 Rose, "Protocol Modifications for the DNS Security
1470 Extensions", RFC 4035, March 2005.
1471
1472 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
1473 (DS) Resource Records (RRs)", RFC 4509, May 2006.
1474
1475 [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message
1476 Authentication Code, Secure Hash Algorithm) TSIG
1477 Algorithm Identifiers", RFC 4635, August 2006.
1478
1479
1480
1481
1482 Lewis & Hoenes Standards Track [Page 27]
1483 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1484
1485
1486 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
1487 Security (DNSSEC) Hashed Authenticated Denial of
1488 Existence", RFC 5155, March 2008.
1489
1490 [RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA
1491 Considerations", BCP 42, RFC 5395, November 2008.
1492
1493 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
1494 and RRSIG Resource Records for DNSSEC", RFC 5702, October
1495 2009.
1496
1497 12.2. Informative References
1498
1499 [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters",
1500 http://www.iana.org/.
1501
1502 [IANA-AF] IANA Registry "Address Family Numbers",
1503 http://www.iana.org/.
1504
1505 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
1506 Malis, "A Framework for IP Based Virtual Private
1507 Networks", RFC 2764, February 2000.
1508
1509 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
1510 "Internationalizing Domain Names in Applications (IDNA)",
1511 RFC 3490, March 2003.
1512
1513 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
1514 Name System (DNS)", RFC 3833, August 2004.
1515
1516 [DNSSEC-U] Weiler, S. and D. Blacka, "Clarifications and
1517 Implementation Notes for DNSSECbis", Work in Progress,
1518 March 2010.
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537 Lewis & Hoenes Standards Track [Page 28]
1538 RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
1539
1540
1541 Authors' Addresses
1542
1543 Edward Lewis
1544 46000 Center Oak Plaza
1545 Sterling, VA 20166
1546 US
1547
1548 EMail: ed.lewis@neustar.biz
1549
1550
1551 Alfred Hoenes, Editor
1552 TR-Sys
1553 Gerlinger Str. 12
1554 Ditzingen D-71254
1555 Germany
1556
1557 EMail: ah@TR-Sys.de
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592 Lewis & Hoenes Standards Track [Page 29]
1593
Many parts of RFC9103, particularly Section 6, update the requirements here for efficient use of TCP.