draft-ietf-dnsext-axfr-clarify-12.txt   draft-ietf-dnsext-axfr-clarify-13.txt 
DNS Extensions Working Group Edward Lewis DNS Extensions Working Group Edward Lewis
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Updates: 1034, 1035 (if approved) A. Hoenes Updates: 1034, 1035 (if approved) A. Hoenes, Ed.
Intended status: Standards Track TR-Sys Intended status: Standards Track TR-Sys
Expires: June 6, 2010 December 6, 2009 Expires: July 18, 2010 January 18, 2010
DNS Zone Transfer Protocol (AXFR) DNS Zone Transfer Protocol (AXFR)
draft-ietf-dnsext-axfr-clarify-12 draft-ietf-dnsext-axfr-clarify-13
Abstract Abstract
The Domain Name System standard mechanisms for maintaining coherent The Domain Name System standard mechanisms for maintaining coherent
servers for a zone consist of three elements. One mechanism is the servers for a zone consist of three elements. One mechanism is the
Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035. Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
The definition of AXFR has proven insufficient in detail, thereby The definition of AXFR has proven insufficient in detail, thereby
forcing implementations intended to be compliant to make assumptions, forcing implementations intended to be compliant to make assumptions,
impeding interoperability. Yet today we have a satisfactory set of impeding interoperability. Yet today we have a satisfactory set of
implementations that do interoperate. This document is a new implementations that do interoperate. This document is a new
definition of AXFR -- new in the sense that is it recording an definition of AXFR -- new in the sense that it records an accurate
accurate definition of an interoperable AXFR mechanism. definition of an interoperable AXFR mechanism.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to Process, except to format it for publication as an RFC or to
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 6, 2010. This Internet-Draft will expire on July 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Coverage and Relationship to Original AXFR Specification . 5 1.4. Coverage and Relationship to Original AXFR Specification . 5
2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7 2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9 2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9
2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10 2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10 2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10 2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10
2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10 2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10
2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11 2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. "0 Message" Response . . . . . . . . . . . . . . . . . . 11 2.2.1. Header Values . . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Header Values . . . . . . . . . . . . . . . . . . . . . 12 2.2.2. Question Section . . . . . . . . . . . . . . . . . . . . 14
2.2.3. Question Section . . . . . . . . . . . . . . . . . . . . 14 2.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 14
2.2.4. Answer Section . . . . . . . . . . . . . . . . . . . . . 14 2.2.4. Authority Section . . . . . . . . . . . . . . . . . . . 14
2.2.5. Authority Section . . . . . . . . . . . . . . . . . . . 14 2.2.5. Additional Section . . . . . . . . . . . . . . . . . . . 14
2.2.6. Additional Section . . . . . . . . . . . . . . . . . . . 14 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 15
2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 14
3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15 3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15 3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15
3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16 3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16
3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18 3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18
3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20 4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20
4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21 4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21
4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22
6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23 6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24
7.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Server . . . . . . . . . . .. . . . . . . . . . . . . . . 24
7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
10. Internationalization Considerations . . . . . . . . . . . . 25 10. Internationalization Considerations . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . .. . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 27
13. Editor's Address . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The Domain Name System standard facilities for maintaining coherent The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements. Authoritative Transfer servers for a zone consist of three elements. Authoritative Transfer
(AXFR) is defined in "Domain Names - Concepts and Facilities" (AXFR) is defined in "Domain Names - Concepts and Facilities"
[RFC1034] (referred to in this document as RFC 1034) and "Domain [RFC1034] (referred to in this document as RFC 1034) and "Domain
Names - Implementation and Specification" [RFC1035] (henceforth Names - Implementation and Specification" [RFC1035] (henceforth
RFC 1035). Incremental Zone Transfer (IXFR) is defined in RFC 1035). Incremental Zone Transfer (IXFR) is defined in
"Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt
skipping to change at page 4, line 34 skipping to change at page 4, line 34
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [BCP14]. RFCs to Indicate Requirement Levels" [BCP14].
Use of "newer"/"new" and "older"/"old" DNS refers to implementations Use of "newer"/"new" and "older"/"old" DNS refers to implementations
written after and prior to the publication of this document. written after and prior to the publication of this document.
"General purpose DNS implementation" refers to DNS software developed "General purpose DNS implementation" refers to DNS software developed
for wide-spread use. This includes resolvers and servers freely for widespread use. This includes resolvers and servers freely
accessible as libraries and standalone processes. This also includes accessible as libraries and standalone processes. This also includes
proprietary implementations used only in support of DNS service proprietary implementations used only in support of DNS service
offerings. offerings.
"Turnkey DNS implementation" refers to custom made, single use "Turnkey DNS implementation" refers to custom made, single use
implementations of DNS. Such implementations consist of software implementations of DNS. Such implementations consist of software
that employs the DNS protocol message format yet does not conform to that employs the DNS protocol message format yet does not conform to
the entire range of DNS functionality. the entire range of DNS functionality.
The terms "AXFR session", "AXFR server" and "AXFR client" will be The terms "AXFR session", "AXFR server" and "AXFR client" will be
skipping to change at page 5, line 46 skipping to change at page 5, line 46
The original "specification" of the AXFR sub-protocol is scattered The original "specification" of the AXFR sub-protocol is scattered
through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5) through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5)
depicts the scenario for which AXFR has been designed. Section 4.3.5 depicts the scenario for which AXFR has been designed. Section 4.3.5
of RFC 1034 describes the zone synchronization strategies in general of RFC 1034 describes the zone synchronization strategies in general
and rules for the invocation of a full zone transfer via AXFR; the and rules for the invocation of a full zone transfer via AXFR; the
fifth paragraph of that section contains a very short sketch of the fifth paragraph of that section contains a very short sketch of the
AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
flaw in that specification. Section 3.2.3 of RFC 1035 has assigned flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
the code point for the AXFR QTYPE (see Section 2.1.2 below for more the code point for the AXFR QTYPE (see Section 2.1.2 below for more
details). Section 4.2 of RFC 1035 discusses the transport layer use details). Section 4.2 of RFC 1035 discusses how the DNS uses the
of DNS and shortly explains why UDP transport is deemed inappropriate transport layer and briefly explains why UDP transport is deemed
for AXFR; the last paragraph of Section 4.2.2 gives details for the inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
TCP connection management with AXFR. Finally, the second paragraph details regarding TCP connection management for AXFR. Finally, the
of Section 6.3 in RFC 1035 mandates server behavior when zone data second paragraph of Section 6.3 in RFC 1035 mandates server behavior
changes occur during an ongoing zone transfer using AXFR. when zone data changes occur during an ongoing zone transfer using
AXFR.
This document will update the specification of AXFR. To this end, it This document will update the specification of AXFR. To this end, it
fully specifies the record formats and processing rules for AXFR, fully specifies the record formats and processing rules for AXFR,
largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
details the transport considerations for AXFR, thus amending Section details the transport considerations for AXFR, thus amending Section
4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility 4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility
issues and provides policy/management considerations as well as issues and provides policy/management considerations as well as
specific Security Considerations for AXFR. The goal of this document specific Security Considerations for AXFR. The goal of this document
is to define AXFR as it exists, or is supposed to exist, currently. is to define AXFR as it exists, or is supposed to exist, currently.
2. AXFR Messages 2. AXFR Messages
An AXFR session consists of an AXFR query message and the sequence of An AXFR session consists of an AXFR query message and the sequence of
AXFR response messages returned for it. In this document, the AXFR AXFR response messages returned for it. In this document, the AXFR
client is the sender of the AXFR query and the AXFR server is the client is the sender of the AXFR query and the AXFR server is the
responder. (Use of terms such as master, slave, primary, secondary responder. (Use of terms such as master, slave, primary, secondary
are not important to defining AXFR.) The use of the word "session" are not important for defining AXFR.) The use of the word "session"
without qualification refers to an AXFR session. without qualification refers to an AXFR session.
An important aspect to keep in mind is that the definition of AXFR is An important aspect to keep in mind is that the definition of AXFR is
restricted to TCP [RFC0793]. The design of the AXFR process has restricted to TCP [RFC0793] (see Section 4 for details). The design
certain inherent features that are not easily ported to UDP of the AXFR process has certain inherent features that are not easily
[RFC0768]. ported to UDP [RFC0768].
The basic format of an AXFR message is the DNS message as defined in The basic format of an AXFR message is the DNS message as defined in
Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
following documents. following documents.
o The 'Basic' DNS specification: o The 'Basic' DNS specification:
- "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)" - "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)"
[RFC1996] [RFC1996]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
skipping to change at page 9, line 43 skipping to change at page 9, line 43
Notes: Notes:
a) Set to any value that the client is not already using with the a) Set to any value that the client is not already using with the
same server. There is no specific means for selecting the value same server. There is no specific means for selecting the value
in this field. (Recall that AXFR is done only via TCP connections in this field. (Recall that AXFR is done only via TCP connections
-- see Section 4 "Transport".) -- see Section 4 "Transport".)
A server MUST reply using messages that use the same message ID to A server MUST reply using messages that use the same message ID to
allow a client to have multiple queries outstanding concurrently allow a client to have multiple queries outstanding concurrently
over the same TCP connection -- see Note a) in Section 2.2.2 for over the same TCP connection -- see Note a) in Section 2.2.1 for
more details. more details.
b) 'n/a' -- The value in this field has no meaning in the context of b) 'n/a' -- The value in this field has no meaning in the context of
AXFR query messages. For the client, it is RECOMMENDED that the AXFR query messages. For the client, it is RECOMMENDED that the
value be zero. The server MUST ignore this value. value be zero. The server MUST ignore this value.
c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
it. it.
d) The client MUST set this field to the number of resource records d) The client MUST set this field to the number of resource records
appearing in the Additional section. See Section 2.1.5 it places into the Additional section. In the absense of explicit
"Additional Section" for details. specification of new RRs to be carried in the Additional section
of AXFR queries, the value MAY be 0, 1 or 2. See Section 2.1.5
The value MAY be 0, 1 or 2. If it is 2, the Additional section "Additional Section" for details on the currently applicable RRs.
MUST contain both an EDNS0 [RFC2671] OPT resource record and a
record carrying transaction integrity and authentication data,
currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
value is 1, then the Additional section MUST contain either only
an EDNS0 OPT resource record or a record carrying transaction
integrity and authentication data. If the value is 0, the
Additional section MUST be empty.
2.1.2. Question Section 2.1.2. Question Section
The Query section of the AXFR query MUST conform to Section 4.1.2 of The Question Section of the AXFR query MUST conform to Section 4.1.2
RFC 1035, and contain a single resource record with the following of RFC 1035, and contain a single resource record with the following
values: values:
QNAME the name of the zone requested QNAME the name of the zone requested
QTYPE AXFR (= 252), the pseudo-RR type for zone transfer QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
[DNSVALS] [DNSVALS]
QCLASS the class of the zone requested [DNSVALS] QCLASS the class of the zone requested [DNSVALS]
2.1.3. Answer Section 2.1.3. Answer Section
The Answer section MUST be empty. The Answer section MUST be empty.
2.1.4. Authority Section 2.1.4. Authority Section
The Authority section MUST be empty. The Authority section MUST be empty.
2.1.5. Additional Section 2.1.5. Additional Section
The client MAY include an EDNS0 OPT [RFC2671] resource record. If Currently, two kinds of resource records are defined that can appear
in the Additional section of AXFR queries and responses: EDNS and DNS
transaction security. Future specifications defining RRs that can be
carried in the Additional section of normal DNS transactions need to
explicitly describe their use with AXFR, should that be desired.
The client MAY include one EDNS0 OPT [RFC2671] resource record. If
the server does not support EDNS0, the client MUST send this section the server does not support EDNS0, the client MUST send this section
without an EDNS0 OPT resource record if there is a retry. However, without an EDNS0 OPT resource record if there is a retry. However,
the protocol does not define an explicit indication that the server the protocol does not define an explicit indication that the server
does not support EDNS0; that needs to be inferred by the client. does not support EDNS0; that needs to be inferred by the client.
Often, the server will return a FormErr(1) which might be related to Often, the server will return a FormErr(1) which might be related to
the OPT resource record. the OPT resource record. Note that, at the time of this writing,
only the EXTENDED-RCODE field of the EDNS0 OPT RR is meaningful in
the context of AXFR; future specifications of EDNS0 flags and/or
EDNS0 options must describe their usage in the context of AXFR, if
applicable.
The client MAY include a transaction integrity and authentication The client MAY include one transaction integrity and authentication
resource record, currently a choice of TSIG [RFC2845] or SIG(0) resource record, currently a choice of TSIG [RFC2845] or SIG(0)
[RFC2931]. If the server has indicated that it does not recognize [RFC2931]. If the server has indicated that it does not recognize
the resource record, and that the error is indeed caused by the the resource record, and that the error is indeed caused by the
resource record, the client probably should not try again. Removing resource record, the client probably should not try again. Removing
the security data in the face of an obstacle ought to only be done the security data in the face of an obstacle ought to only be done
with full awareness of the implication of doing so. with full awareness of the implication of doing so.
In general, if an AXFR client is aware that an AXFR server does not In general, if an AXFR client is aware that an AXFR server does not
support a particular mechanism, the client SHOULD NOT attempt to support a particular mechanism, the client SHOULD NOT attempt to
engage the server using the mechanism (or at all). A client could engage the server using the mechanism (or at all). A client could
become aware of a server's abilities via a configuration setting or become aware of a server's abilities via a configuration setting or
skipping to change at page 11, line 17 skipping to change at page 11, line 21
In general, if an AXFR client is aware that an AXFR server does not In general, if an AXFR client is aware that an AXFR server does not
support a particular mechanism, the client SHOULD NOT attempt to support a particular mechanism, the client SHOULD NOT attempt to
engage the server using the mechanism (or at all). A client could engage the server using the mechanism (or at all). A client could
become aware of a server's abilities via a configuration setting or become aware of a server's abilities via a configuration setting or
via some other (as yet) undefined means. via some other (as yet) undefined means.
The range of permissible resource records that MAY appear in the The range of permissible resource records that MAY appear in the
Additional section might change over time. If either a change to an Additional section might change over time. If either a change to an
existing resource record (like the OPT RR for EDNS0) is made or a new existing resource record (like the OPT RR for EDNS0) is made or a new
Additional section record is created, the new definitions ought to Additional section record is created, the new definitions ought to
include a discussion on the impact upon AXFR. Future resource include a discussion on the applicability and impact upon AXFR.
records residing in the Additional section might have an effect that Future resource records residing in the Additional section might have
is orthogonal to AXFR, so can ride through the session as opaque an effect that is orthogonal to AXFR, so can ride through the session
data. In this case, a "wise" implementation ought to be able to pass as opaque data. In this case, a "wise" implementation ought to be
these records through without disruption. able to pass these records through without disruption.
2.2. AXFR Response 2.2. AXFR Response
The AXFR response will consist of 0 or more messages. A "0 message" The AXFR response will consist of one or more messages. The special
response is covered in Section 2.2.1. case of a server closing the TCP connection without sending an AXFR
response is covered in section 2.3.
An AXFR response that is transferring the zone's contents will An AXFR response that is transferring the zone's contents will
consist of a series (which could be a series of length 1) of DNS consist of a series (which could be a series of length 1) of DNS
messages. In such a series, the first message MUST begin with the messages. In such a series, the first message MUST begin with the
SOA resource record of the zone, the last message MUST conclude with SOA resource record of the zone, the last message MUST conclude with
the same SOA resource record. Intermediate messages MUST NOT contain the same SOA resource record. Intermediate messages MUST NOT contain
the SOA resource record. The AXFR server MUST copy the Question the SOA resource record. The AXFR server MUST copy the Question
section from the corresponding AXFR query message in to the first section from the corresponding AXFR query message into the first
response message's Question section. Subsequent messages MAY do the response message's Question section. For subsequent messages, it MAY
same or contain an empty Question section. do the same or leave the Question section empty.
An AXFR response indicates an error via a single DNS message with the
return code set to the appropriate value for the condition
encountered, sent once the error condition is detected. Such a
message terminates the AXFR session; it MUST copy the Query Section
from the AXFR query into its Query Section, but the inclusion of the
terminating SOA resource record is not necessary.
An AXFR server may send a number of AXFR response messages free of an The AXFR protocol treats the zone contents as an unordered collection
error condition before it sends the message indicating an error. (or to use the mathematical term, a "set") of RRs. Except for the
requirement that the transfer must begin and end with the SOA RR,
there is no requirement to send the RRs in any particular order or
grouped into response messages in any particular way. Although
servers typically do attempt to send related RRs (such as the RRs
forming an RRset, and the RRsets of a name) as a contiguous group or,
when message space allows, in the same response message, they are not
required to do so, and clients MUST accept any ordering and grouping
of the non-SOA RRs. Each RR SHOULD be transmitted only once, and
AXFR clients MUST ignore any duplicate RRs received.
2.2.1. "0 Message" Response Each AXFR response message SHOULD contain a sufficient number of RRs
to reasonably amortize the per-message overhead, up to the largest
number that will fit within a DNS message (taking the required
content of the other sections into account, as described below).
Some old AXFR clients expect each response message to contain only a
single RR. To interoperate with such clients, the server MAY
restrict response messages to a single RR. As there is no standard
way to automatically detect such clients, this typically requires
manual configuration at the server.
A legitimate "0 message" response, i.e., the client sees no response To indicate an error in an AXFR response, the AXFR server sends a
whatsoever, is very exceptional and controversial. Unquestionably it single DNS message when the error condition is detected, with the
is unhealthy for there to be 0 responses in a protocol that is response code set to the appropriate value for the condition
designed around a query - response paradigm over an unreliable encountered, Such a message terminates the AXFR session; it MUST
transport. The lack of a response could be a sign of underlying contain a copy of the Question section from the AXFR query in its
network problems and cause the protocol state machine to react Question section, but the inclusion of the terminating SOA resource
accordingly. However, AXFR uses TCP and not UDP, eliminating record is not necessary.
undetectable network errors.
A "0 message response" is reserved for situations in which the server An AXFR server may send a number of AXFR response messages free of an
has a reason to suspect that the query is sent for the purpose of error condition before it sends the message indicating an error.
abuse. Due to the use of this being so controversial, a "0 message
response" is not being defined as a legitimate part of the protocol
but the use of it is being acknowledged as a warning to AXFR client
implementations. Any earnest query has the expectation of some
response but nevertheless may not get one.
2.2.2. Header Values 2.2.1. Header Values
These are the DNS message header values for AXFR responses. These are the DNS message header values for AXFR responses.
ID MUST be copied from request -- see Note a) ID MUST be copied from request -- see Note a)
QR MUST be 1 (Response) QR MUST be 1 (Response)
OPCODE MUST be 0 (Standard Query) OPCODE MUST be 0 (Standard Query)
Flags: Flags:
AA normally 1 -- see Note b) AA normally 1 -- see Note b)
TC MUST be 0 (Not truncated) TC MUST be 0 (Not truncated)
RD RECOMMENDED: copy request's value, MAY be set to 0 RD RECOMMENDED: copy request's value, MAY be set to 0
RA SHOULD be 0 -- see Note c) RA SHOULD be 0 -- see Note c)
Z 'mbz' -- see Note d) Z 'mbz' -- see Note d)
AD covered by DNSSEC rules -- see Note e) AD 'mbz' -- see Note d)
CD covered by DNSSEC rules -- see Note e) CD 'mbz' -- see Note d)
RCODE See Note f) RCODE See Note e)
QDCOUNT MUST be 1 in the first message; QDCOUNT MUST be 1 in the first message;
MUST be 0 or 1 in all following messages; MUST be 0 or 1 in all following messages;
MUST be 1 if RCODE indicates an error MUST be 1 if RCODE indicates an error
ANCOUNT See Note g) ANCOUNT See Note f)
NSCOUNT MUST be 0 NSCOUNT MUST be 0
ARCOUNT See Note g)
ARCOUNT See Note h)
Notes: Notes:
a) Because some old implementations behave differently than is now a) Because some old implementations behave differently than is now
desired, the requirement on this field is stated in detail. New desired, the requirement on this field is stated in detail. New
DNS servers MUST set this field to the value of the AXFR query ID DNS servers MUST set this field to the value of the AXFR query ID
in each AXFR response message for the session. AXFR clients MUST in each AXFR response message for the session. AXFR clients MUST
be able to manage sessions resulting from the issuance of multiple be able to manage sessions resulting from the issuance of multiple
outstanding queries, whether AXFR queries or other DNS queries. outstanding queries, whether AXFR queries or other DNS queries.
A client SHOULD discard responses that do not correspond (via the A client SHOULD discard responses that do not correspond (via the
skipping to change at page 13, line 42 skipping to change at page 13, line 43
regarding recursive service, but doing so might confuse the regarding recursive service, but doing so might confuse the
interpretation of the response as AXFR can not be retrieved interpretation of the response as AXFR can not be retrieved
recursively. A client MAY note the server's policy regarding recursively. A client MAY note the server's policy regarding
recursive service from this value, but SHOULD NOT conclude that recursive service from this value, but SHOULD NOT conclude that
the AXFR response was obtained recursively even if the RD bit was the AXFR response was obtained recursively even if the RD bit was
1 in the query. 1 in the query.
d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
it. it.
e) If the implementation supports the DNS Security Extensions (DNSSEC e) In the absence of an error, the server MUST set the value of this
-- see Section 2), then this value MUST be set according to the
rules in RFC 4035, Section 3.1.6, "The AD and CD Bits in an
Authoritative Response". If the implementation does not support
the DNS Security Extensions, then this value MUST be set to 0 and
MUST be ignored upon receipt.
f) In the absence of an error, the server MUST set the value of this
field to NoError(0). If a server is not authoritative for the field to NoError(0). If a server is not authoritative for the
queried zone, the server SHOULD set the value to NotAuth(9). queried zone, the server SHOULD set the value to NotAuth(9).
(Reminder, consult the appropriate IANA registry [DNSVALS].) If a (Reminder, consult the appropriate IANA registry [DNSVALS].) If a
client receives any other value in response, it MUST act according client receives any other value in response, it MUST act according
to the error. For example, a malformed AXFR query or the presence to the error. For example, a malformed AXFR query or the presence
of an EDNS0 OPT resource record sent to an old server will garner of an EDNS0 OPT resource record sent to an old server will result
a FormErr(1) value. This value is not set as part of the AXFR- in a FormErr(1) value. This value is not set as part of the AXFR-
specific response processing. The same is true for other values specific response processing. The same is true for other values
indicating an error. indicating an error.
g) The count of answer records MUST equal the number of resource f) The count of answer records MUST equal the number of resource
records in the AXFR Answer Section. When a server is aware that a records in the AXFR Answer Section. When a server is aware that a
client will only accept one resource record per response message, client will only accept response messages with a single resource
then the value MUST be 1. A server MAY be made aware of a record, then the value MUST be 1. A server MAY be made aware of a
client's limitations via configuration data. client's limitations via configuration data.
h) The client MUST set this field to the number of resource records g) The server MUST set this field to the number of resource records
appearing in the Additional section. The considerations of Note it places into the Additional section. In the absense of explicit
d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional specification of new RRs to be carried in the Additional section
Section" below for more details. of AXFR response messages, the value MAY be 0, 1 or 2. See
Section 2.1.5 above for details on the currently applicable RRs
and Section 2.2.5 for additional considerations specific to AXFR
servers.
2.2.3. Question Section 2.2.2. Question Section
In the first response message, this section MUST be copied from the In the first response message, this section MUST be copied from the
query. In subsequent messages, this section MAY be copied from the query. In subsequent messages, this section MAY be copied from the
query or it MAY be empty. However, in an error response message (see query or it MAY be empty. However, in an error response message (see
Section 2.2), this section MUST be copied as well. The content of Section 2.2), this section MUST be copied as well. The content of
this section MAY be used to determine the context of the message, this section MAY be used to determine the context of the message,
that is, the name of the zone being transferred. that is, the name of the zone being transferred.
2.2.4. Answer Section 2.2.3. Answer Section
MUST be populated with the zone contents. See Section 3 below on The Answer section MUST be populated with the zone contents. See
encoding zone contents. Section 3 below on encoding zone contents.
2.2.5. Authority Section 2.2.4. Authority Section
The Authority section MUST be empty. The Authority section MUST be empty.
2.2.6. Additional Section 2.2.5. Additional Section
The contents of this section MUST follow the guidelines for EDNS0 and The contents of this section MUST follow the guidelines for EDNS0 and
TSIG, SIG(0), or whatever other future record is possible here. The TSIG, SIG(0), or whatever other future record is possible here. The
contents of Section 2.1.5 apply analogously as well. contents of Section 2.1.5 apply analogously as well.
The following considerations specifically apply to AXFR responses:
If the client has supplied an EDNS0 OPT RR in the AXFR query and if
the server supports ENDS0 as well, it SHOULD include one EDNS0 OPT RR
in the first response message and MAY do so in subsequent response
messages (see Section 2.2); the specifications of EDNS0 options to be
carried in the OPT RR may impose stronger requirements.
If the client has supplied a transaction security resource record
(currently a choice of TSIG and SIG(0)) and the server supports the
method chosen by the client, it MUST place the corresponding resource
record into the AXFR response message(s), according to the rules
specified for that method.
2.3. TCP Connection Aborts 2.3. TCP Connection Aborts
If an AXFR client sends a query on a TCP connection and the If an AXFR client sends a query on a TCP connection and the
connection is closed at any point, the AXFR client MUST consider the connection is closed at any point, the AXFR client MUST consider the
AXFR session terminated. The message ID MAY be used again on a new AXFR session terminated. The message ID MAY be used again on a new
connection, even if the question and AXFR server are the same. connection, even if the question and AXFR server are the same.
Facing a dropped connection, a client SHOULD try to make some Facing a dropped connection, a client SHOULD try to make some
determination whether the connection closure was the result of determination as to whether the connection closure was the result of
network activity or a decision by the AXFR server. This network activity or due to a decision by the AXFR server. This
determination is not an exact science. It is up to the AXFR client determination is not an exact science. It is up to the AXFR client
implementor to react, but the reaction SHOULD NOT be an endless cycle to react, but the implemented reaction SHOULD NOT be either an
of retries nor an increasing (in frequency) retry rate. endless cycle of retries or an increasing (in frequency) retry rate.
An AXFR server implementor SHOULD take into consideration the dilemma An AXFR server implementor should take into consideration the dilemma
described above when a connection is closed with an outstanding query described above when a connection is closed with an outstanding query
in the pipeline. For this reason, a server ought to reserve this in the pipeline. For this reason, a server ought to reserve this
course of action for situations in which it believes beyond a doubt course of action for situations in which it believes beyond a doubt
that the AXFR client is attempting abusive behavior. that the AXFR client is attempting abusive behavior.
3. Zone Contents 3. Zone Contents
The objective of the AXFR session is to request and transfer the The objective of the AXFR session is to request and transfer the
contents of a zone. The objective is to permit the AXFR client to contents of a zone, in order to permit the AXFR client to faithfully
reconstruct the zone as it exists at the server for the given zone reconstruct the zone as it exists at the primary server for the given
serial number. Over time the definition of a zone has evolved from zone serial number. The word "exists" here designates the externally
denoting a static set of records to also cover a dynamically updated visible behavior, i.e., the zone content that is being served (handed
set of records, and then a potentially continually regenerated set of out to clients) -- not its persistent representation in a zone file
records (e.g., RRs synthesized "on the fly" from rule sets or or database used by the server -- and that for consistency should be
database lookup results in other forms than RR format) as well. served subsequently by the AXFR client in an identical manner.
Over time the definition of a zone has evolved from denoting a static
set of records to also cover a dynamically updated set of records,
and then a potentially continually regenerated set of records (e.g.,
RRs synthesized "on the fly" from rule sets or database lookup
results in other forms than RR format) as well.
3.1. Records to Include 3.1. Records to Include
In the Answer section of AXFR response messages the resource records In the Answer section of AXFR response messages, the resource records
within a zone for the given serial number MUST appear. The within a zone for the given serial number MUST appear. The
definition of what belongs in a zone is described in RFC 1034, definition of what belongs in a zone is described in RFC 1034,
Section 4.2, "How the database is divided into zones" (in particular Section 4.2, "How the database is divided into zones" (in particular
Section 4.2.1, "Technical considerations"), and it has been clarified Section 4.2.1, "Technical considerations"), and it has been clarified
in Section 6 of RFC 2181. in Section 6 of RFC 2181.
Unless the AXFR server knows that the AXFR client is old and expects
just one resource record per AXFR response message, an AXFR server
SHOULD populate an AXFR response message with as many complete
resource record sets as will fit within a DNS message.
Zones for which it is impractical to list the entire zone for a Zones for which it is impractical to list the entire zone for a
serial number are not suitable for AXFR retrieval. A typical (but serial number are not suitable for AXFR retrieval. A typical (but
not limiting) description of such a zone is a zone consisting of not limiting) description of such a zone is a zone consisting of
responses generated via other database lookups and/or computed based responses generated via other database lookups and/or computed based
upon ever changing data. upon ever changing data.
3.2. Delegation Records 3.2. Delegation Records
In Section 4.2.1 of RFC 1034, this text appears (keep in mind that In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
the "should" in the quotation predates [BCP14], cf. Section 1.1): the "should" in the quotation predates [BCP14], cf. Section 1.1):
skipping to change at page 16, line 26 skipping to change at page 16, line 32
The phrase "that describe cuts" is a reference to the NS set and The phrase "that describe cuts" is a reference to the NS set and
applicable glue records. It does not mean that the cut point and applicable glue records. It does not mean that the cut point and
apex resource records are identical. For example, the SOA resource apex resource records are identical. For example, the SOA resource
record is only found at the apex. The discussion here is restricted record is only found at the apex. The discussion here is restricted
to just the NS resource record set and glue as these "describe cuts". to just the NS resource record set and glue as these "describe cuts".
DNSSEC resource records have special specifications regarding their DNSSEC resource records have special specifications regarding their
occurrence at a zone cut and the apex of a zone. This was first occurrence at a zone cut and the apex of a zone. This was first
described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
specification of DNSSEC), which parts of RFC 2181 now in fact are specification of DNSSEC), which parts of RFC 2181 now in fact are
historical. The current DNSSEC core document set (see Note e) in historical. The current DNSSEC core document set (see second bullet
Section 2.2.2 above) gives the full details for DNSSEC(bis) resource in Section 2 above) gives the full details for DNSSEC(bis) resource
record placement, and Section 3.1.5 of RFC 4035 normatively specifies record placement, and Section 3.1.5 of RFC 4035 normatively specifies
their treatment during AXFR; the alternate NSEC3 resource record their treatment during AXFR; the alternate NSEC3 resource record
defined later in RFC 5155 behaves identically as the NSEC RR, for the defined later in RFC 5155 behaves identically as the NSEC RR, for the
purpose of AXFR. purpose of AXFR.
Informally: Informally:
o The DS RRSet only occurs at the parental side of a zone cut and is o The DS RRSet only occurs at the parental side of a zone cut and is
authoritative data in the parent zone, not the secure child zone. authoritative data in the parent zone, not the secure child zone.
o The DNSKEY RRSet only occurs at the APEX of a signed zone and is o The DNSKEY RRSet only occurs at the APEX of a signed zone and is
part of the authoritative data of the zone it serves. part of the authoritative data of the zone it serves.
o Independent RRSIG RRSets occur at the signed parent side of a zone o Independent RRSIG RRSets occur at the signed parent side of a zone
cut and at the apex of a signed zone; they are authoritative data cut and at the apex of a signed zone; they are authoritative data
skipping to change at page 17, line 10 skipping to change at page 17, line 15
o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
equally may occur at the parental side of a zone cut and at the equally may occur at the parental side of a zone cut and at the
apex of a zone; each such resource record belongs to exactly one apex of a zone; each such resource record belongs to exactly one
of these zones and is to be included in the AXFR of that zone. of these zones and is to be included in the AXFR of that zone.
One issue is that in operations there are times when the NS resource One issue is that in operations there are times when the NS resource
records for a zone might be different at a cut point in the parent records for a zone might be different at a cut point in the parent
and at the apex of a zone. Sometimes this is the result of an error and at the apex of a zone. Sometimes this is the result of an error
and sometimes it is part of an ongoing change in name servers. The and sometimes it is part of an ongoing change in name servers. The
DNS protocol is robust enough to overcome inconsistencies up to (but DNS protocol is robust enough to overcome inconsistencies up to (but
not including) there being no parent indicated NS resource record not including) there being no parent-indicated NS resource record
referencing a server that is able to serve the child zone. This referencing a server that is able to serve the child zone. This
robustness is one quality that has fueled the success of the DNS. robustness is one quality that has fueled the success of the DNS.
Still, the inconsistency is an error state and steps need to be taken Still, the inconsistency is an error state and steps need to be taken
to make it apparent (if it is unplanned) and to make it clear once to make it apparent (if it is unplanned) and to make it clear once
the inconsistency has been removed. the inconsistency has been removed.
Another issue is that the AXFR server could be authoritative for a Another issue is that the AXFR server could be authoritative for a
different set of zones than the AXFR client. It is possible that the different set of zones than the AXFR client. It is possible that the
AXFR server be authoritative for both halves of an inconsistent cut AXFR server be authoritative for both halves of an inconsistent cut
point and that the AXFR client is authoritative for just the parent point and that the AXFR client is authoritative for just the parent
skipping to change at page 17, line 49 skipping to change at page 18, line 4
mean a lot more needed work and even network retrieval of data. An mean a lot more needed work and even network retrieval of data. An
authoritative server ought not be required to perform any queries. authoritative server ought not be required to perform any queries.
2) By transferring the inconsistent NS resource records from a server 2) By transferring the inconsistent NS resource records from a server
that is authoritative for both the cut point and the apex to a client that is authoritative for both the cut point and the apex to a client
that is not authoritative for both, the error is exposed. For that is not authoritative for both, the error is exposed. For
example, an authorized administrator can manually request the AXFR example, an authorized administrator can manually request the AXFR
and inspect the results to see the inconsistent records. (A server and inspect the results to see the inconsistent records. (A server
authoritative for both halves would otherwise always answer from the authoritative for both halves would otherwise always answer from the
more authoritative set, concealing the error.) more authoritative set, concealing the error.)
3) The inconsistent NS resource record set might indicate a problem 3) The inconsistent NS resource record set might indicate a problem
in a registration database. in a registration database.
4) This requirement is necessary to ensure that retrieving a given 4) This requirement is necessary to ensure that retrieving a given
(zone,serial) pair by AXFR yields the exact same set of resource (zone,serial) pair by AXFR yields the exact same set of resource
records no matter which of the zone's authoritative servers is chosen records no matter which of the zone's authoritative servers is chosen
as the source of the transfer. as the source of the transfer.
If an AXFR server were allowed to respond with the authoritative NS If an AXFR server were allowed to respond with the authoritative NS
RRset of a child zone instead of a glue NS RRset in the zone being RRset of a child zone instead of a parent-side NS RRset in the zone
transferred, the set of records returned could vary depending on being transferred, the set of records returned could vary depending
whether or not the server happens to be authoritative for the child on whether or not the server happened to be authoritative for the
zone as well. child zone as well.
The property that a given (zone,serial) pair corresponds to a single, The property that a given (zone,serial) pair corresponds to a single,
well-defined set of records is necessary for the correct operation of well-defined set of records is necessary for the correct operation of
incremental transfer protocols such as IXFR [RFC1995]. For example, incremental transfer protocols such as IXFR [RFC1995]. For example,
a client may retrieve a zone by AXFR from one server, and then apply a client may retrieve a zone by AXFR from one server, and then apply
an incremental change obtained by IXFR from a different server. If an incremental change obtained by IXFR from a different server. If
the two servers have different ideas of the zone contents, the client the two servers have different ideas of the zone contents, the client
can end up attempting to incrementally add records that already exist can end up attempting to incrementally add records that already exist
or to delete records that do not exist. or to delete records that do not exist.
skipping to change at page 18, line 50 skipping to change at page 19, line 4
operational matter. operational matter.
3.4. Name Compression 3.4. Name Compression
Compression of names in DNS messages is described in RFC 1035, Compression of names in DNS messages is described in RFC 1035,
Section 4.1.4, "Message compression". The issue highlighted here Section 4.1.4, "Message compression". The issue highlighted here
relates to a comment made in RFC 1034, Section 3.1, "Name space relates to a comment made in RFC 1034, Section 3.1, "Name space
specifications and terminology" which says "When you receive a domain specifications and terminology" which says "When you receive a domain
name or label, you should preserve its case." ("Should" in the quote name or label, you should preserve its case." ("Should" in the quote
predates [BCP14].) predates [BCP14].)
Since the primary objective of AXFR is to enable the client to serve
Name compression in an AXFR message MUST preserve the case of the the same zone content as the server, unlike such normal DNS responses
original domain name. That is, although when comparing a domain that are expected to preserve the case in the query, the actual zone
name, "a" equals "A", when comparing for the purposes of message transfer needs to retain the case of the labels in the zone content.
compression, "a" is not equal to "A". Note that this is not the Hence, name compression in an AXFR message SHOULD be performed in a
usual definition of name comparison in the DNS protocol and case-preserving manner, unlike how it is done for 'normal' DNS
represents a new requirement on AXFR servers. responses. That is, although when comparing a domain name for
matching, "a" equals "A", when comparing for the purposes of message
compression for AXFR, "a" is not equal to "A". Note that this is not
the usual definition of name comparison in the DNS protocol and
represents a new understanding of the requirement on AXFR servers.
Rules governing name compression of RDATA in an AXFR message MUST Rules governing name compression of RDATA in an AXFR message MUST
abide by the specification in "Handling of Unknown DNS Resource abide by the specification in "Handling of Unknown DNS Resource
Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
Compression". Compression".
3.5. Occluded Names 3.5. Occluded Names
Dynamic Update [RFC2136] operations, and in particular its Dynamic Update [RFC2136] operations, and in particular its
interaction with DNAME [RFC2672], can have a side effect of occluding interaction with DNAME [RFC2672], can have a side effect of occluding
skipping to change at page 19, line 38 skipping to change at page 19, line 46
4. Transport 4. Transport
AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
1034 that states: "Because accuracy is essential, TCP or some other 1034 that states: "Because accuracy is essential, TCP or some other
reliable protocol must be used for AXFR requests." The restriction reliable protocol must be used for AXFR requests." The restriction
to TCP is also mentioned in Section 6.1.3.2. of "Requirements for to TCP is also mentioned in Section 6.1.3.2. of "Requirements for
Internet Hosts - Application and Support" [RFC1123]. Internet Hosts - Application and Support" [RFC1123].
The most common scenario is for an AXFR client to open a TCP The most common scenario is for an AXFR client to open a TCP
connection to the AXFR server, send an AXFR query, receive the AXFR connection to the AXFR server, send an AXFR query, receive the AXFR
response, and then close the connection. But variations of that response, and then close the connection. But variations of that most
most simple scenario are legitimate and likely, in particular sending simple scenario are legitimate and likely: in particular, sending a
a query for the zone's SOA resource record first over the same TCP query for the zone's SOA resource record first over the same TCP
connection, and reusing an existing TCP connection for other queries. connection, and reusing an existing TCP connection for other queries.
Therefore, the assumption that a TCP connection is dedicated to a Therefore, the assumption that a TCP connection is dedicated to a
single AXFR session is incorrect. This wrong assumption has led to single AXFR session is incorrect. This wrong assumption has led to
implementation choices that prevent either multiple concurrent zone implementation choices that prevent either multiple concurrent zone
transfers or the use of an open connection for other queries. transfers or the use of an open connection for other queries.
Since the early days of the DNS, operators who have sets of name Since the early days of the DNS, operators who have sets of name
servers that are authoritative for a common set of zones found it servers that are authoritative for a common set of zones found it
desirable to be able to have multiple concurrent zone transfers in desirable to be able to have multiple concurrent zone transfers in
progress; this way a name server does not have to wait for one zone progress; this way a name server does not have to wait for one zone
transfer to complete before the next could begin. RFC 1035 did not transfer to complete before the next can begin. RFC 1035 did not
exclude this possibility, but legacy implementations missed to exclude this possibility, but legacy implementations failed to
support this functionality. The remaining presence of such legacy support this functionality efficiently, over a single TCP connection.
implementations makes it necessary that new general purpose server The remaining presence of such legacy implementations makes it
implementation still provide options for gracefull fallback to the necessary that new general purpose client implementations still
old behavior in their support of concurrent DNS transactions and AXFR provide options for graceful fallback to the old behavior in their
sessions on a single TCP connection. support of concurrent DNS transactions and AXFR sessions on a single
TCP connection.
4.1. TCP 4.1. TCP
In the original definition there arguably is an implicit assumption In the original definition there arguably is an implicit assumption
(probably unintentional) that a TCP connection is used for one and (probably unintentional) that a TCP connection is used for one and
only one AXFR session. This is evidenced in the lack of an explicit only one AXFR session. This is evidenced in the lack of an explicit
requirement to copy the Query section and/or the message ID into requirement to copy the Question Section and/or the message ID into
responses, no explicit ordering information within the AXFR response responses, no explicit ordering information within the AXFR response
messages, and the lack of an explicit notice indicating that a zone messages, and the lack of an explicit notice indicating that a zone
transfer continues in the next message. transfer continues in the next message.
The guidance given below is intended to enable better performance of The guidance given below is intended to enable better performance of
the AXFR exchange as well as provide guidelines on interactions with the AXFR exchange as well as provide guidelines on interactions with
older software. Better performance includes being able to multiplex older software. Better performance includes being able to multiplex
DNS message exchanges including zone transfer sessions. Guidelines DNS message exchanges including zone transfer sessions. Guidelines
for interacting with older software are generally applicable to new for interacting with older software are generally applicable to new
AXFR clients. In the reverse situation, older AXFR client and newer AXFR clients. In the reverse situation, older AXFR client and newer
AXFR server, the server ought to operate within the specification for AXFR server, the server ought to operate within the specification for
an older server. an older server.
4.1.1. AXFR client TCP 4.1.1. AXFR client TCP
An AXFR client MAY request a connection to an AXFR server for any An AXFR client MAY request a connection to an AXFR server for any
reason. An AXFR client SHOULD close the connection when there is no reason. An AXFR client SHOULD close the connection when there is no
apparent need to use the connection for some time period. The AXFR apparent need to use the connection for some time period. The AXFR
server ought not have to maintain idle connections, the burden of server ought not have to maintain idle connections; the burden of
connection closure ought to be on the client. "Apparent need" for connection closure ought to be on the client. "Apparent need" for
the connection is a judgment for the AXFR client and the DNS client. the connection is a judgment for the AXFR client and the DNS client.
If the connection is used for multiple sessions, or if it is known If the connection is used for multiple sessions, or if it is known
sessions will be coming, or if there is other query/response traffic sessions will be coming, or if there is other query/response traffic
anticipated or currently on the open connection, then there is anticipated or currently on the open connection, then there is
"apparent need". "apparent need".
An AXFR client can cancel the delivery of a zone only by closing the An AXFR client can cancel the delivery of a zone only by closing the
connection. However, this action will also cancel all other connection. However, this action will also cancel all other
outstanding activity using the connection. There is no other outstanding activity using the connection. There is no other
mechanism by which an AXFR response can be cancelled. mechanism by which an AXFR response can be cancelled.
When a TCP connection is closed remotely (relative to the client), When a TCP connection is closed remotely (relative to the client),
whether by the AXFR server or due to a network event, the AXFR client whether by the AXFR server or due to a network event, the AXFR client
MUST cancel all outstanding sessions and non-AXFR transactions. MUST cancel all outstanding sessions and non-AXFR transactions.
Recovery from this situation is not straightforward. If the Recovery from this situation is not straightforward. If the
disruption was a spurious event, attempting to restart the connection disruption was a spurious event, attempting to restart the connection
would be proper. If the disruption was caused by a failure that would be proper. If the disruption was caused by a failure that
proved to be persistent, the AXFR client would be wise to not spend proved to be persistent, the AXFR client would be wise not to spend
too many resources trying to rebuild the connection. Finally, if the too many resources trying to rebuild the connection. Finally, if the
connection was dropped because of a policy at the AXFR server (as can connection was dropped because of a policy at the AXFR server (as can
be the case with older AXFR servers), the AXFR client would be wise be the case with older AXFR servers), the AXFR client would be wise
to not retry the connection. Unfortunately, knowing which of the not to retry the connection. Unfortunately, knowing which of the
three cases above (momentary disruption, failure, policy) applies is three cases above (momentary disruption, failure, policy) applies is
not possible with certainty, and can only be assessed by heuristics. not possible with certainty, and can only be assessed by heuristics.
This exemplifies the general complications for clients in connection-
oriented protocols not receiving meaningful error responses.
An AXFR client MAY use an already opened TCP connection to start an An AXFR client MAY use an already opened TCP connection to start an
AXFR session. Using an existing open connection is RECOMMENDED over AXFR session. Using an existing open connection is RECOMMENDED over
opening a new connection. (Non-AXFR session traffic can also use an opening a new connection. (Non-AXFR session traffic can also use an
open connection.) If in doing so the AXFR client realizes that the open connection.) If in doing so the AXFR client realizes that the
responses cannot be properly differentiated (lack of matching query responses cannot be properly differentiated (lack of matching query
IDs for example) or the connection is terminated for a remote reason, IDs for example) or the connection is terminated for a remote reason,
then the AXFR client SHOULD NOT attempt to reuse an open connection then the AXFR client SHOULD NOT attempt to reuse an open connection
with the specific AXFR server until the AXFR server is updated (which with the specific AXFR server until the AXFR server is updated (which
is, of course, not an event captured in the DNS protocol). is, of course, not an event captured in the DNS protocol).
4.1.2. AXFR server TCP 4.1.2. AXFR server TCP
An AXFR server MUST be able to handle multiple AXFR sessions on a An AXFR server MUST be able to handle multiple AXFR sessions on a
single TCP connection, as well as handle other query/response single TCP connection, as well as to handle other query/response
transactions over it. transactions over it.
If a TCP connection is closed remotely, the AXFR server MUST cancel If a TCP connection is closed remotely, the AXFR server MUST cancel
all AXFR sessions in place. No retry activity is necessary; that is all AXFR sessions in place. No retry activity is necessary; that is
initiated by the AXFR client. initiated by the AXFR client.
Local policy MAY dictate that a TCP connection is to be closed. Such Local policy MAY dictate that a TCP connection is to be closed. Such
an action SHOULD be in reaction to limits such as those placed on the an action SHOULD be in reaction to limits such as those placed on the
number of outstanding open connections. Closing a connection in number of outstanding open connections. Closing a connection in
response to a suspected security event SHOULD be done only in extreme response to a suspected security event SHOULD be done only in extreme
cases, when the server is certain the action is warranted. An cases, when the server is certain the action is warranted. An
isolated request for a zone not on the AXFR server SHOULD receive a isolated request for a zone not on the AXFR server SHOULD receive a
response with the appropriate return code and not see the connection response with the appropriate response code and not see the
broken. connection broken.
4.2. UDP 4.2. UDP
With the addition of EDNS0 and applications which require many small With the addition of EDNS0 and applications which require many small
zones such as in web hosting and some ENUM scenarios, AXFR sessions zones such as in web hosting and some ENUM scenarios, AXFR sessions
on UDP would now seem desirable. However, there are still some on UDP would now seem desirable. However, there are still some
aspects of AXFR sessions that are not easily translated to UDP. aspects of AXFR sessions that are not easily translated to UDP.
Therefore, this document does not update RFC 1035 in this respect: Therefore, this document does not update RFC 1035 in this respect:
AXFR sessions over UDP transport are not defined. AXFR sessions over UDP transport are not defined.
skipping to change at page 25, line 38 skipping to change at page 25, line 37
Gustafsson. In his latest version, this acknowledgment appeared: Gustafsson. In his latest version, this acknowledgment appeared:
"Many people have contributed input and commentary to earlier "Many people have contributed input and commentary to earlier
versions of this document, including but not limited to Bob Halley, versions of this document, including but not limited to Bob Halley,
Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert
Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
Trenholme, and Brian Wellington." Trenholme, and Brian Wellington."
Comments since the -05 version have come from these individuals: Comments since the -05 version have come from these individuals:
Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
Ian Jackson, Andreas Gustafsson, Brian Wellington, and other Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
participants of the DNSEXT working group. Bill Manning, and other participants of the DNSEXT working group.
Edward Lewis served as a patiently listening sole document editor for Edward Lewis served as a patiently listening sole document editor for
two years. two years.
12. References 12. References
All "RFC" references by can be obtained from the RFC Editor web site All "RFC" references by can be obtained from the RFC Editor web site
at the URLs: http://rfc-editor.org/rfc.html at the URLs: http://rfc-editor.org/rfc.html
or http://rfc-editor.org/rfcsearch.html ; or http://rfc-editor.org/rfcsearch.html ;
information regarding this organization can be found at the following information regarding this organization can be found at the following
skipping to change at page 28, line 14 skipping to change at page 28, line 14
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
Implementation Notes for DNSSECbis", Implementation Notes for DNSSECbis",
draft-ietf-dnsext-dnssec-bis-updates-09 (work in draft-ietf-dnsext-dnssec-bis-updates-09 (work in
progress), September 2009. progress), September 2009.
13. Editors' Addresses Authors' Addresses
Edward Lewis Edward Lewis
46000 Center Oak Plaza 46000 Center Oak Plaza
Sterling, VA, 22033, US Sterling, VA, 22033, US
Email: ed.lewis@neustar.biz Email: ed.lewis@neustar.biz
Alfred Hoenes Alfred Hoenes, Editor
TR-Sys TR-Sys
Gerlinger Str. 12 Gerlinger Str. 12
Ditzingen D-71254 Ditzingen D-71254
Germany Germany
Email: ah@TR-Sys.de Email: ah@TR-Sys.de
Editorial Note: Discussion [[ to be removed by RFC-Editor ]] Editorial Note: Discussion [[ to be removed by RFC-Editor ]]
Comments on this draft ought to be addressed to the editors and/or to Comments on this draft ought to be addressed to the editors and/or to
 End of changes. 71 change blocks. 
171 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/