draft-ietf-dnsext-axfr-clarify-14.txt   rfc5936.txt 
DNS Extensions Working Group Edward Lewis Internet Engineering Task Force (IETF) E. Lewis
Internet-Draft NeuStar, Inc. Request for Comments: 5936 NeuStar, Inc.
Updates: 1034, 1035 (if approved) A. Hoenes, Ed. Updates: 1034, 1035 A. Hoenes, Ed.
Intended status: Standards Track TR-Sys Category: Standards Track TR-Sys
Expires: September 26, 2010 March 26, 2010 ISSN: 2070-1721 June 2010
DNS Zone Transfer Protocol (AXFR) DNS Zone Transfer Protocol (AXFR)
draft-ietf-dnsext-axfr-clarify-14
Abstract Abstract
The standard means within the Domain Name System protocol for The standard means within the Domain Name System protocol for
maintaining coherence among a zone's authoritative name servers maintaining coherence among a zone's authoritative name servers
consists of three mechanisms. Authoritative Transfer (AXFR) is one consists of three mechanisms. Authoritative Transfer (AXFR) is one
of the mechanisms and is defined in RFC 1034 and RFC 1035. of the mechanisms and is 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 it records an accurate definition of AXFR -- new in the sense that it records an 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 in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (IETF). It represents the consensus of the IETF community. It has
The list of Internet-Draft Shadow Directories can be accessed at received public review and has been approved for publication by the
http://www.ietf.org/shadow.html Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 26, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5936.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 ......................................................5
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 ...................................................6
2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. AXFR Query .................................................8
2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9 2.1.1. Header Values .......................................8
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. Header Values . . . . . . . . . . . . . . . . . . . . . 12 2.2.1. Header Values ......................................12
2.2.2. Question Section . . . . . . . . . . . . . . . . . . . . 14 2.2.2. Question Section ...................................14
2.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 14 2.2.3. Answer Section .....................................14
2.2.4. Authority Section . . . . . . . . . . . . . . . . . . . 14 2.2.4. Authority Section ..................................14
2.2.5. Additional Section . . . . . . . . . . . . . . . . . . . 14 2.2.5. Additional Section .................................14
2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 15 2.3. TCP Connection Aborts .....................................15
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 ..........................................19
3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Occluded Names ............................................19
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Transport ......................................................20
4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. TCP .......................................................20
4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20 4.1.1. AXFR Client TCP ....................................21
4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21 4.1.2. AXFR Server TCP ....................................22
4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 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 ....................................................25
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 . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References ....................................................26
12.1. Normative References . .. . . . . . . . . . . . . . . . 26 12.1. Normative References .....................................26
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References ...................................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
RFC 1035). Incremental Zone Transfer (IXFR) is defined in 1035). Incremental Zone Transfer (IXFR) is defined in "Incremental
"Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification
notification of zone changes (NOTIFY) is defined in "A Mechanism for of zone changes (NOTIFY) is defined in "A Mechanism for Prompt
Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of
goal of these mechanisms is to enable a set of DNS name servers to these mechanisms is to enable a set of DNS name servers to remain
remain coherently authoritative for a given zone. coherently authoritative for a given zone.
This document re-specifies the AXFR mechanism as it is deployed in This document re-specifies the AXFR mechanism as it is deployed in
the Internet at large, hopefully with the precision expected from the Internet at large, hopefully with the precision expected from
modern Internet Standards, and thereby updates RFC 1034 and RFC 1035. modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
1.1. Definition of Terms 1.1. Definition of Terms
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 widespread 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
introduced in the first paragraph of Section 2, after some more introduced in the first paragraph of Section 2, after some more
context has been established. context has been established.
1.2. Scope 1.2. Scope
In general terms, authoritative name servers for a given zone can use In general terms, authoritative name servers for a given zone can use
various means to achieve coherency of the zone contents they serve. various means to achieve coherency of the zone contents they serve.
For example, there are DNS implementations that assemble answers from For example, there are DNS implementations that assemble answers from
data stored in relational databases (as opposed to master files), data stored in relational databases (as opposed to master files),
relying on the database's non-DNS means to synchronize the database relying on the database's non-DNS means to synchronize the database
skipping to change at page 5, line 17 skipping to change at page 5, line 24
defined in-band mechanisms to provide coherence of a set of name defined in-band mechanisms to provide coherence of a set of name
servers, and they are the only mechanisms specified by the IETF. servers, and they are the only mechanisms specified by the IETF.
This document does not cover incoherent DNS situations. There are This document does not cover incoherent DNS situations. There are
applications of the DNS in which servers for a zone are designed to applications of the DNS in which servers for a zone are designed to
be incoherent. For these configurations, a coherency mechanism as be incoherent. For these configurations, a coherency mechanism as
described here would be unsuitable. described here would be unsuitable.
A DNS implementation is not required to support AXFR, IXFR, and A DNS implementation is not required to support AXFR, IXFR, and
NOTIFY, but it should have some means for maintaining name server NOTIFY, but it should have some means for maintaining name server
coherency. A general purpose DNS implementation will likely support coherency. A general-purpose DNS implementation will likely support
AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
implementations may exist without AXFR. implementations may exist without AXFR.
1.3. Context 1.3. Context
Besides describing the mechanisms themselves, there is the context in Besides describing the mechanisms themselves, there is the context in
which they operate to consider. In the initial specifications of which they operate to consider. In the initial specifications of
AXFR (and IXFR and NOTIFY), little consideration was given to AXFR (and IXFR and NOTIFY), little consideration was given to
security and privacy issues. Since the original definition of AXFR, security and privacy issues. Since the original definition of AXFR,
new opinions have appeared on the access to an entire zone's new opinions have appeared on the access to an entire zone's
skipping to change at page 6, line 9 skipping to change at page 6, line 16
inappropriate for AXFR; the last paragraph of Section 4.2.2 gives inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
details regarding TCP connection management for AXFR. Finally, the details regarding TCP connection management for AXFR. Finally, the
second paragraph of Section 6.3 in RFC 1035 mandates server behavior second paragraph of Section 6.3 in RFC 1035 mandates server behavior
when zone data changes occur during an ongoing zone transfer using when zone data changes occur during an ongoing zone transfer using
AXFR. 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 is understood by the DNS community to exist is to define AXFR as it is understood by the DNS community to exist
today. today.
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, and
are not important for defining AXFR.) The use of the word "session" secondary are not important for defining AXFR.) The use of the word
without qualification refers to an AXFR session. "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] (see Section 4 for details). The design restricted to TCP [RFC0793] (see Section 4 for details). The design
of the AXFR process has certain inherent features that are not easily of the AXFR process has certain inherent features that are not easily
ported to UDP [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
[RFC1996] (DNS NOTIFY)" [RFC1996]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- "Clarifications to the DNS Specification" [RFC2181] - "Dynamic Updates in the Domain Name System (DNS UPDATE)"
- "Extension Mechanisms for DNS (EDNS0)" [RFC2671] [RFC2136]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] - "Clarifications to the DNS Specification" [RFC2181]
- "Obsoleting IQUERY" [RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] - "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] - "Secret Key Transaction Authentication for DNS (TSIG)"
- "Domain Name System (DNS) IANA Considerations" [RFC5395] [RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types"
[RFC3597]
- "HMAC SHA (Hashed Message Authentication Code, Secure Hash
Algorithm) TSIG Algorithm Identifiers" [RFC4635]
- "Domain Name System (DNS) IANA Considerations" [RFC5395]
o Further additions related to the DNS Security Extensions (DNSSEC), o Further additions related to the DNS Security Extensions (DNSSEC),
defined in these base documents: defined in these base documents:
- "DNS Security Introduction and Requirements" [RFC4033] - "DNS Security Introduction and Requirements" [RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035] - "Resource Records for the DNS Security Extensions"
- "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509] [RFC4034]
- "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - "Protocol Modifications for the DNS Security Extensions"
Records for DNSSEC" [RFC5702] [RFC4035]
- "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
- "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource
Records (RRs)" [RFC4509]
- "DNS Security (DNSSEC) Hashed Authenticated Denial of
Existence" [RFC5155]
- "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG
Resource Records for DNSSEC" [RFC5702]
- "Clarifications and Implementation Notes for DNSSECbis"
[DNSSEC-U]
These documents contain information about the syntax and semantics of These documents contain information about the syntax and semantics of
DNS messages. They do not interfere with AXFR but are also helpful DNS messages. They do not interfere with AXFR but are also helpful
in understanding what will be carried via AXFR. in understanding what will be carried via AXFR.
For convenience, the synopsis of the DNS message header from For convenience, the synopsis of the DNS message header from
[RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
reproduced here informally: reproduced here informally:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT | | QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT | | ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT | | NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
This document makes use of the field names as they appear in this This document makes use of the field names as they appear in this
diagram. The names of sections in the body of DNS messages are diagram. The names of sections in the body of DNS messages are
capitalized in this document for clarity, e.g., "Additional section". capitalized in this document for clarity, e.g., "Additional section".
The DNS message size limit from [RFC1035] for DNS over UDP (and its The DNS message size limit from [RFC1035] for DNS over UDP (and its
extension via the EDNS0 mechanism specified in [RFC2671]) is not extension via the EDNS0 mechanism specified in [RFC2671]) is not
relevant for AXFR, as explained in Section 4. The upper limit on the relevant for AXFR, as explained in Section 4. The upper limit on the
permissible size of a DNS message over TCP is only restricted by the permissible size of a DNS message over TCP is only restricted by the
TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
two-octet message length field, understood to be unsigned, and thus two-octet message length field, understood to be unsigned, and thus
causing a limit of 65535 octets. This limit is not changed by EDNS0. causing a limit of 65535 octets. This limit is not changed by EDNS0.
Note that the TC (truncation) bit is never set by an AXFR server nor Note that the TC (truncation) bit is never set by an AXFR server nor
considered/read by an AXFR client. considered/read by an AXFR client.
2.1. AXFR query 2.1. AXFR Query
An AXFR query is sent by a client whenever there is a reason to ask. An AXFR query is sent by a client whenever there is a reason to ask.
This might be because of scheduled or triggered zone maintenance This might be because of scheduled or triggered zone maintenance
activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
respectively) or as a result of a command line request, say for respectively) or as a result of a command line request, say for
debugging. debugging.
2.1.1. Header Values 2.1.1. Header Values
These are the DNS message header values for an AXFR query. These are the DNS message header values for an AXFR query.
skipping to change at page 9, line 14 skipping to change at page 9, line 4
2.1.1. Header Values 2.1.1. Header Values
These are the DNS message header values for an AXFR query. These are the DNS message header values for an AXFR query.
ID Selected by client; see Note a) ID Selected by client; see Note a)
QR MUST be 0 (Query) QR MUST be 0 (Query)
OPCODE MUST be 0 (Standard Query) OPCODE MUST be 0 (Standard Query)
Flags: Flags:
AA 'n/a' -- see Note b) AA "n/a" -- see Note b)
TC 'n/a' -- see Note b) TC "n/a" -- see Note b)
RD 'n/a' -- see Note b) RD "n/a" -- see Note b)
RA 'n/a' -- see Note b) RA "n/a" -- see Note b)
Z 'mbz' -- see Note c) Z "mbz" -- see Note c)
AD 'n/a' -- see Note b) AD "n/a" -- see Note b)
CD 'n/a' -- see Note b) CD "n/a" -- see Note b)
RCODE MUST be 0 (No error) RCODE MUST be 0 (No error)
QDCOUNT Number of entries in Question section; MUST be 1 QDCOUNT Number of entries in Question section; MUST be 1
ANCOUNT Number of entries in Answer section; MUST be 0 ANCOUNT Number of entries in Answer section; MUST be 0
NSCOUNT Number of entries in Authority section; MUST be 0 NSCOUNT Number of entries in Authority section; MUST be 0
ARCOUNT Number of entries in Additional section -- see Note d) ARCOUNT Number of entries in Additional section -- see Note d)
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.1 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
it places into the Additional section. In the absence of explicit it places into the Additional section. In the absence of explicit
specification of new RRs to be carried in the Additional section 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 of AXFR queries, the value MAY be 0, 1, or 2. See Section 2.1.5,
"Additional Section" for details on the currently applicable RRs. "Additional Section", for details on the currently applicable RRs.
2.1.2. Question Section 2.1.2. Question Section
The Question section of the AXFR query MUST conform to Section 4.1.2 The Question section of the AXFR query MUST conform to Section 4.1.2
of 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
skipping to change at page 10, line 40 skipping to change at page 10, line 34
The Authority section MUST be empty. The Authority section MUST be empty.
2.1.5. Additional Section 2.1.5. Additional Section
Currently, two kinds of resource records are defined that can appear Currently, two kinds of resource records are defined that can appear
in the Additional section of AXFR queries and responses: EDNS and DNS in the Additional section of AXFR queries and responses: EDNS and DNS
transaction security. Future specifications defining RRs that can be transaction security. Future specifications defining RRs that can be
carried in the Additional section of normal DNS transactions need to carried in the Additional section of normal DNS transactions need to
explicitly describe their use with AXFR, should that be desired. explicitly describe their use with AXFR, should that be desired.
The client MAY include one OPT resource record [RFC2671]. If The client MAY include one OPT resource record [RFC2671]. If the
the server does not support EDNS0, the client MUST send this section server does not support EDNS0, the client MUST send this section
without an OPT resource record if there is a retry. However, without an OPT resource record if there is a retry. However, the
the protocol does not define an explicit indication that the server protocol does not define an explicit indication that the server does
does not support EDNS0; that needs to be inferred by the client. not support EDNS0; that needs to be inferred by the client. Often,
Often, the server will return a FormErr(1) which might be related to the server will return a FormErr(1) that might be related to the OPT
the OPT resource record. Note that, at the time of this writing, resource record. Note that, at the time of this writing, only the
only the EXTENDED-RCODE field of the OPT RR is meaningful in EXTENDED-RCODE field of the OPT RR is meaningful in the context of
the context of AXFR; future specifications of EDNS flags and/or AXFR; future specifications of EDNS flags and/or EDNS options must
EDNS options must describe their usage in the context of AXFR, if describe their usage in the context of AXFR, if applicable.
applicable.
The client MAY include one 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 engage the server at all).
become aware of a server's abilities via a configuration setting or A client could become aware of a server's abilities via a
via some other (as yet) undefined means. configuration setting or 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 EDNS) is made or a new existing resource record (like the OPT RR for EDNS) 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 applicability and impact upon AXFR. include a discussion on the applicability and impact upon AXFR.
Future resource records residing in the Additional section might have Future resource records residing in the Additional section might have
an effect that is orthogonal to AXFR, so can ride through the session an effect that is orthogonal to AXFR, and so can ride through the
as opaque data. In this case, a "wise" implementation ought to be session as opaque data. In this case, a "wise" implementation ought
able to pass these records through without disruption. to be able to pass these records through without disruption.
2.2. AXFR Response 2.2. AXFR Response
The AXFR response will consist of one or more messages. The special The AXFR response will consist of one or more messages. The special
case of a server closing the TCP connection without sending an AXFR case of a server closing the TCP connection without sending an AXFR
response is covered in section 2.3. 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, and the last message MUST conclude
the same SOA resource record. Intermediate messages MUST NOT contain with the same SOA resource record. Intermediate messages MUST NOT
the SOA resource record. The AXFR server MUST copy the Question contain the SOA resource record. The AXFR server MUST copy the
section from the corresponding AXFR query message into the first Question section from the corresponding AXFR query message into the
response message's Question section. For subsequent messages, it MAY first response message's Question section. For subsequent messages,
do the same or leave the Question section empty. it MAY do the same or leave the Question section empty.
The AXFR protocol treats the zone contents as an unordered collection The AXFR protocol treats the zone contents as an unordered collection
(or to use the mathematical term, a "set") of RRs. Except for the (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, 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 there is no requirement to send the RRs in any particular order or
grouped into response messages in any particular way. Although grouped into response messages in any particular way. Although
servers typically do attempt to send related RRs (such as the RRs 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, 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 when message space allows, in the same response message, they are not
required to do so, and clients MUST accept any ordering and grouping required to do so, and clients MUST accept any ordering and grouping
skipping to change at page 12, line 9 skipping to change at page 12, line 4
forming an RRset, and the RRsets of a name) as a contiguous group or, 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 when message space allows, in the same response message, they are not
required to do so, and clients MUST accept any ordering and grouping 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 of the non-SOA RRs. Each RR SHOULD be transmitted only once, and
AXFR clients MUST ignore any duplicate RRs received. AXFR clients MUST ignore any duplicate RRs received.
Each AXFR response message SHOULD contain a sufficient number of RRs Each AXFR response message SHOULD contain a sufficient number of RRs
to reasonably amortize the per-message overhead, up to the largest to reasonably amortize the per-message overhead, up to the largest
number that will fit within a DNS message (taking the required number that will fit within a DNS message (taking the required
content of the other sections into account, as described below). content of the other sections into account, as described below).
Some old AXFR clients expect each response message to contain only a Some old AXFR clients expect each response message to contain only a
single RR. To interoperate with such clients, the server MAY single RR. To interoperate with such clients, the server MAY
restrict response messages to a single RR. As there is no standard restrict response messages to a single RR. As there is no standard
way to automatically detect such clients, this typically requires way to automatically detect such clients, this typically requires
manual configuration at the server. manual configuration at the server.
To indicate an error in an AXFR response, the AXFR server sends a To indicate an error in an AXFR response, the AXFR server sends a
single DNS message when the error condition is detected, with the single DNS message when the error condition is detected, with the
response code set to the appropriate value for the condition response code set to the appropriate value for the condition
encountered, Such a message terminates the AXFR session; it MUST encountered. Such a message terminates the AXFR session; it MUST
contain a copy of the Question section from the AXFR query in its contain a copy of the Question section from the AXFR query in its
Question section, but the inclusion of the terminating SOA resource Question section, but the inclusion of the terminating SOA resource
record is not necessary. record is not necessary.
An AXFR server may send a number of AXFR response messages free of an An AXFR server may send a number of AXFR response messages free of an
error condition before it sends the message indicating an error. error condition before it sends the message indicating an error.
2.2.1. 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 'mbz' -- see Note d) AD "mbz" -- see Note d)
CD 'mbz' -- see Note d) CD "mbz" -- see Note d)
RCODE See Note e) 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 f) ANCOUNT See Note f)
NSCOUNT MUST be 0 NSCOUNT MUST be 0
skipping to change at page 13, line 4 skipping to change at page 12, line 50
RCODE See Note e) 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 f) ANCOUNT See Note f)
NSCOUNT MUST be 0 NSCOUNT MUST be 0
ARCOUNT See Note g) ARCOUNT See Note g)
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
A client SHOULD discard responses that do not correspond (via the client SHOULD discard responses that do not correspond (via the
message ID) to any outstanding queries. message ID) to any outstanding queries.
Unless the client is sure that the server will consistently set Unless the client is sure that the server will consistently set
the ID field to the query's ID, the client is NOT RECOMMENDED to the ID field to the query's ID, the client is NOT RECOMMENDED to
issue any other queries until the end of the zone transfer. issue any other queries until the end of the zone transfer. A
A client MAY become aware of a server's abilities via a client MAY become aware of a server's abilities via a
configuration setting. configuration setting.
b) If the RCODE is 0 (no error), then the AA bit MUST be 1. b) If the RCODE is 0 (no error), then the AA bit MUST be 1. For any
For any other value of RCODE, the AA bit MUST be set according to other value of RCODE, the AA bit MUST be set according to the
the rules for that error code. If in doubt, it is RECOMMENDED rules for that error code. If in doubt, it is RECOMMENDED that it
that it be set to 1. It is RECOMMENDED that the value be ignored be set to 1. It is RECOMMENDED that the value be ignored by the
by the AXFR client. AXFR client.
c) It is RECOMMENDED that the server set the value to 0, the client c) It is RECOMMENDED that the server set the value to 0; the client
MUST ignore this value. MUST ignore this value.
The server MAY set this value according to the local policy The server MAY set this value according to the local policy
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 cannot 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) In the absence of an error, the server MUST set the value of this e) 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 OPT resource record sent to an old server will result of an OPT resource record sent to an old server will result in a
in a FormErr(1) value. This value is not set as part of the AXFR- 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.
f) 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 response messages with a single resource client will only accept response messages with a single resource
record, 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.
g) The server MUST set this field to the number of resource records g) The server MUST set this field to the number of resource records
it places into the Additional section. In the absence of explicit it places into the Additional section. In the absence of explicit
specification of new RRs to be carried in the Additional section specification of new RRs to be carried in the Additional section
of AXFR response messages, the value MAY be 0, 1 or 2. See 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 Section 2.1.5 above for details on the currently applicable RRs
and Section 2.2.5 for additional considerations specific to AXFR and Section 2.2.5 for additional considerations specific to AXFR
servers. servers.
2.2.2. 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
Section 2.2), this section MUST be copied as well. The content of (see Section 2.2), this section MUST be copied as well. The content
this section MAY be used to determine the context of the message, of 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.3. Answer Section 2.2.3. Answer Section
The Answer section MUST be populated with the zone contents. See The Answer section MUST be populated with the zone contents. See
Section 3 below on encoding zone contents. Section 3 below on encoding zone contents.
2.2.4. Authority Section 2.2.4. Authority Section
The Authority section MUST be empty. The Authority section MUST be empty.
2.2.5. Additional Section 2.2.5. Additional Section
The contents of this section MUST follow the guidelines for the OPT, The contents of this section MUST follow the guidelines for the OPT,
TSIG, and SIG(0) RRs, or whatever other future record is possible TSIG, and SIG(0) RRs, or whatever other future record is possible
here. The contents of Section 2.1.5 apply analogously as well. here. The contents of Section 2.1.5 apply analogously as well.
The following considerations specifically apply to AXFR responses: The following considerations specifically apply to AXFR responses:
If the client has supplied an EDNS OPT RR in the AXFR query and if If the client has supplied an EDNS OPT RR in the AXFR query and if
the server supports EDNS as well, it SHOULD include one OPT RR the server supports EDNS as well, it SHOULD include one OPT RR in the
in the first response message and MAY do so in subsequent response first response message and MAY do so in subsequent response messages
messages (see Section 2.2); the specifications of EDNS options to be (see Section 2.2); the specifications of EDNS options to be carried
carried in the OPT RR may impose stronger requirements. in the OPT RR may impose stronger requirements.
If the client has supplied a transaction security resource record If the client has supplied a transaction security resource record
(currently a choice of TSIG and SIG(0)) and the server supports the (currently a choice of TSIG and SIG(0)) and the server supports the
method chosen by the client, it MUST place the corresponding resource method chosen by the client, it MUST place the corresponding resource
record into the AXFR response message(s), according to the rules record into the AXFR response message(s), according to the rules
specified for that method. 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
skipping to change at page 15, line 21 skipping to change at page 15, line 25
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 as to whether the connection closure was the result of determination as to whether the connection closure was the result of
network activity or due to 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
to react, but the implemented reaction SHOULD NOT be either an to react, but the implemented reaction SHOULD NOT be either an
endless cycle of retries or 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 implementer 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, in order to permit the AXFR client to faithfully contents of a zone, in order to permit the AXFR client to faithfully
reconstruct the zone as it exists at the primary server for the given reconstruct the zone as it exists at the primary server for the given
skipping to change at page 16, line 9 skipping to change at page 16, line 12
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.
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):
"The RRs that describe cuts ... should be exactly the same as the The RRs that describe cuts ... should be exactly the same as the
corresponding RRs in the top node of the subzone." corresponding RRs in the top node of the subzone.
There has been some controversy over this statement and the impact on There has been some controversy over this statement and the impact on
which NS resource records are included in a zone transfer. which NS resource records are included in a zone transfer.
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 second bullet historical. The current DNSSEC core document set (see second bullet
in Section 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 to 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
in the respective zone; simple queries for RRSIG resource records in the respective zone; simple queries for RRSIG resource records
may return both RRSets at once if the same server is authoritative may return both RRSets at once if the same server is authoritative
for the parent zone and the child zone (Section 3.1.5 of RFC 4035 for the parent zone and the child zone (Section 3.1.5 of RFC 4035
describes how to distinguish these RRs); this seeming ambiguity describes how to distinguish these RRs); this seeming ambiguity
does not occur for AXFR, since each such RRSIG RRset belongs to a does not occur for AXFR, since each such RRSIG RRset belongs to a
single zone. single zone.
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
to make it apparent (if it is unplanned) and to make it clear once taken to make it apparent (if it is unplanned).
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
side of the cut point. side of the cut point.
When facing a situation in which a cut point's NS resource records do When facing a situation in which a cut point's NS resource records do
not match the authoritative set, the question arises whether an AXFR not match the authoritative set, the question arises whether an AXFR
server responds with the NS resource record set that is in the zone server responds with the NS resource record set that is in the zone
skipping to change at page 17, line 43 skipping to change at page 18, line 8
The AXFR response MUST contain the cut point NS resource record set The AXFR response MUST contain the cut point NS resource record set
registered with the zone whether it agrees with the authoritative set registered with the zone whether it agrees with the authoritative set
or not. "Registered with" can be widely interpreted to include data or not. "Registered with" can be widely interpreted to include data
residing in the zone file of the zone for the particular serial residing in the zone file of the zone for the particular serial
number (in zone file environments) or as any data configured to be in number (in zone file environments) or as any data configured to be in
the zone (database), statically or dynamically. the zone (database), statically or dynamically.
The reasons for this requirement are: The reasons for this requirement are:
1) The AXFR server might not be able to determine that there is an 1) The AXFR server might not be able to determine that there is an
inconsistency given local data, hence requiring consistency would inconsistency given local data; hence, requiring consistency would
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.
authoritative server ought not be required to perform any queries. An 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
that is not authoritative for both, the error is exposed. For client that is not authoritative for both, the error is exposed.
example, an authorized administrator can manually request the AXFR For example, an authorized administrator can manually request the
and inspect the results to see the inconsistent records. (A server AXFR and inspect the results to see the inconsistent records. (A
authoritative for both halves would otherwise always answer from the server authoritative for both halves would otherwise always answer
more authoritative set, concealing the error.) from the 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
as the source of the transfer. chosen 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 parent-side NS RRset in the zone RRset of a child zone instead of a parent-side NS RRset in the zone
being transferred, the set of records returned could vary depending being transferred, the set of records returned could vary depending
on whether or not the server happened to be authoritative for the on whether or not the server happened to be authoritative for the
child 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
well-defined set of records is necessary for the correct operation of single, well-defined set of records is necessary for the correct
incremental transfer protocols such as IXFR [RFC1995]. For example, operation of incremental transfer protocols such as IXFR [RFC1995].
a client may retrieve a zone by AXFR from one server, and then apply For example, a client may retrieve a zone by AXFR from one server,
an incremental change obtained by IXFR from a different server. If and then apply an incremental change obtained by IXFR from a
the two servers have different ideas of the zone contents, the client different server. If the two servers have different ideas of the
can end up attempting to incrementally add records that already exist zone contents, the client can end up attempting to incrementally add
or to delete records that do not exist. records that already exist or to delete records that do not exist.
3.3. Glue Records 3.3. Glue Records
As quoted in the previous section, Section 4.2.1 of RFC 1034 provides As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
guidance and rationale for the inclusion of glue records as part of guidance and rationale for the inclusion of glue records as part of
an AXFR transfer. And, as also argued in the previous section of an AXFR response. And, as also argued in the previous section of
this document, even when there is an inconsistency between the this document, even when there is an inconsistency between the
address in a glue record and the authoritative copy of the name address in a glue record and the authoritative copy of the name
server's address, the glue resource record that is registered as part server's address, the glue resource record that is registered as part
of the zone for that serial number is to be included. of the zone for that serial number is to be included.
This applies to glue records for any address family [IANA-AF]. This applies to glue records for any address family [IANA-AF].
The AXFR response MUST contain the appropriate glue records as The AXFR response MUST contain the appropriate glue records as
registered with the zone. The interpretation of "registered with" in registered with the zone. The interpretation of "registered with" in
the previous section applies here. Inconsistent glue records are an the previous section applies here. Inconsistent glue records are an
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:
name or label, you should preserve its case." ("Should" in the quote
predates [BCP14].) When you receive a domain name or label, you should preserve its
case.
("Should" in the quote predates [BCP14].)
Since the primary objective of AXFR is to enable the client to serve Since the primary objective of AXFR is to enable the client to serve
the same zone content as the server, unlike such normal DNS responses the same zone content as the server, unlike such normal DNS responses
that are expected to preserve the case in the query, the actual zone that are expected to preserve the case in the query, the actual zone
transfer needs to retain the case of the labels in the zone content. transfer needs to retain the case of the labels in the zone content.
Hence, name compression in an AXFR message SHOULD be performed in a Hence, name compression in an AXFR message SHOULD be performed in a
case-preserving manner, unlike how it is done for 'normal' DNS case-preserving manner, unlike how it is done for "normal" DNS
responses. That is, although when comparing a domain name for responses. That is, although when comparing a domain name for
matching, "a" equals "A", when comparing for the purposes of message 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 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 the usual definition of name comparison in the DNS protocol and
represents a new understanding of the requirement on AXFR servers. 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 their
interaction with DNAME [RFC2672], can have a side effect of occluding interaction with DNAME [RFC2672], can have a side effect of occluding
names in a zone. The addition of a delegation point via dynamic names in a zone. The addition of a delegation point via dynamic
update will render all subordinate domain names to be in a limbo, update will render all subordinate domain names to be in a limbo,
still part of the zone but not available to the lookup process. The still part of the zone but not available to the lookup process. The
addition of a DNAME resource record has the same impact. The addition of a DNAME resource record has the same impact. The
subordinate names are said to be "occluded". subordinate names are said to be "occluded".
Occluded names MUST be included in AXFR responses. An AXFR client Occluded names MUST be included in AXFR responses. An AXFR client
MUST be able to identify and handle occluded names. The rationale MUST be able to identify and handle occluded names. The rationale
for this action is based on a speedy recovery if the dynamic update for this action is based on a speedy recovery if the dynamic update
operation was in error and is to be undone. operation was in error and is to be undone.
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, which states:
reliable protocol must be used for AXFR requests." The restriction
to TCP is also mentioned in Section 6.1.3.2. of "Requirements for Because accuracy is essential, TCP or some other reliable protocol
Internet Hosts - Application and Support" [RFC1123]. must be used for AXFR requests.
The restriction to TCP is also mentioned in Section 6.1.3.2 of
"Requirements for 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 most response, and then close the connection. But variations of that most
simple scenario are legitimate and likely: in particular, sending a simple scenario are legitimate and likely: in particular, sending 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 have found
desirable to be able to have multiple concurrent zone transfers in it 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 can begin. RFC 1035 did not transfer to complete before the next can begin. RFC 1035 did not
exclude this possibility, but legacy implementations failed to exclude this possibility, but legacy implementations failed to
support this functionality efficiently, over a single TCP connection. support this functionality efficiently, over a single TCP connection.
The remaining presence of such legacy implementations makes it The remaining presence of such legacy implementations makes it
necessary that new general purpose client implementations still necessary that new general-purpose client implementations still
provide options for graceful fallback to the old behavior in their provide options for graceful fallback to the old behavior in their
support of concurrent DNS transactions and AXFR sessions on a single support of concurrent DNS transactions and AXFR sessions on a single
TCP connection. 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 Question 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
AXFR server, the server ought to operate within the specification for newer AXFR server -- the server ought to operate within the
an older server. specification for 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 that sessions will be coming, or if there is other query/response
anticipated or currently on the open connection, then there is traffic anticipated or currently on the open connection, then there
"apparent need". is "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
skipping to change at page 21, line 31 skipping to change at page 22, line 10
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- This exemplifies the general complications for clients in connection-
oriented protocols not receiving meaningful error responses. 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
then the AXFR client SHOULD NOT attempt to reuse an open connection reason, then the AXFR client SHOULD NOT attempt to reuse an open
with the specific AXFR server until the AXFR server is updated (which connection with the specific AXFR server until the AXFR server is
is, of course, not an event captured in the DNS protocol). updated (which 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 to 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 response code and not see the response with the appropriate response code and not see the
connection 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 that 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.
5. Authorization 5. Authorization
A zone administrator has the option to restrict AXFR access to a A zone administrator has the option to restrict AXFR access to a
zone. This was not envisioned in the original design of the DNS but zone. This was not envisioned in the original design of the DNS but
skipping to change at page 22, line 34 skipping to change at page 23, line 15
questionable, but this document, driven by the desire to leverage the questionable, but this document, driven by the desire to leverage the
interoperable practice that has evolved since RFC 1035, acknowledges interoperable practice that has evolved since RFC 1035, acknowledges
the factual requirement to provide mechanisms to restrict AXFR. the factual requirement to provide mechanisms to restrict AXFR.
A DNS implementation SHOULD provide means to restrict AXFR sessions A DNS implementation SHOULD provide means to restrict AXFR sessions
to specific clients. to specific clients.
An implementation SHOULD allow access to be granted to Internet An implementation SHOULD allow access to be granted to Internet
Protocol addresses and ranges, regardless of whether a source address Protocol addresses and ranges, regardless of whether a source address
could be spoofed. Combining this with techniques such as Virtual could be spoofed. Combining this with techniques such as Virtual
Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be
effective. effective.
A general purpose implementation is RECOMMENDED to implement access A general-purpose implementation is RECOMMENDED to implement access
controls based upon "Secret Key Transaction Authentication for DNS" controls based upon "Secret Key Transaction Authentication for DNS
[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures
[RFC2931]. ( SIG(0)s )" [RFC2931].
A general purpose implementation SHOULD allow access to be open to A general-purpose implementation SHOULD allow access to be open to
all AXFR requests. I.e., an operator ought to be able to allow any all AXFR requests. That is, an operator ought to be able to allow
AXFR query to be granted. any AXFR query to be granted.
A general purpose implementation SHOULD NOT have a default policy for A general-purpose implementation SHOULD NOT have a default policy for
AXFR requests to be "open to all". For example, a default could be AXFR requests to be "open to all". For example, a default could be
to restrict transfers to addresses selected by the DNS to restrict transfers to addresses selected by the DNS
administrator(s) for zones on the server. administrator(s) for zones on the server.
6. Zone Integrity 6. Zone Integrity
An AXFR client MUST ensure that only a successfully transferred copy An AXFR client MUST ensure that only a successfully transferred copy
of the zone data can be used to serve this zone. Previous of the zone data can be used to serve this zone. Previous
description and implementation practice have introduced a two-stage description and implementation practice has introduced a two-stage
model of the whole zone synchronization procedure: Upon a trigger model of the whole zone synchronization procedure: Upon a trigger
event (e.g., polling of a SOA resource record detects change in the event (e.g., when polling of a SOA resource record detects a change
SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is
initiated, whereby the zone data are saved in a zone file or data received), the AXFR session is initiated, whereby the zone data are
base (this latter step is necessary anyway to ensure proper restart saved in a zone file or database (this latter step is necessary
of the server); upon successful completion of the AXFR operation and anyway to ensure proper restart of the server); upon successful
some sanity checks, this data set is 'loaded' and made available for completion of the AXFR operation and some sanity checks, this data
serving the zone in an atomic operation, and flagged 'valid' for use set is "loaded" and made available for serving the zone in an atomic
during the next restart of the DNS server; if any error is detected, operation, and flagged "valid" for use during the next restart of the
this data set MUST be deleted, and the AXFR client MUST continue to DNS server; if any error is detected, this data set MUST be deleted,
serve the previous version of the zone, if it did before. The and the AXFR client MUST continue to serve the previous version of
externally visible behavior of an AXFR client implementation MUST be the zone, if it did before. The externally visible behavior of an
equivalent to that of this two-stage model. AXFR client implementation MUST be equivalent to that of this two-
stage model.
If an AXFR client rejects data contained in an AXFR session, it If an AXFR client rejects data obtained in an AXFR session, it SHOULD
SHOULD remember the serial number and MAY attempt to retrieve the remember the serial number and MAY attempt to retrieve the same zone
same zone version again. The reason the same retrieval could make version again. The reason the same retrieval could make sense is
sense is that the reason for the rejection could be rooted in an that the reason for the rejection could be rooted in an
implementation detail of one AXFR server used for the zone and not implementation detail of one AXFR server used for the zone and not
present in another AXFR server used for the zone. present in another AXFR server used for the zone.
Ensuring that an AXFR client does not accept a forged copy of a zone Ensuring that an AXFR client does not accept a forged copy of a zone
is important to the security of a zone. If a zone operator has the is important to the security of a zone. If a zone operator has the
opportunity, protection can be afforded via dedicated links, physical opportunity, protection can be afforded via dedicated links, physical
or virtual via a VPN among the authoritative servers. But there are or virtual via a VPN among the authoritative servers. But there are
instances in which zone operators have no choice but to run AXFR instances in which zone operators have no choice but to run AXFR
sessions over the global public Internet. sessions over the global public Internet.
Besides best attempts at securing TCP connections, DNS Besides best attempts at securing TCP connections, DNS
implementations SHOULD provide means to make use of "Secret Key implementations SHOULD provide means to make use of "Secret Key
Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS
Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow
to verify the contents. These techniques MAY also be used for AXFR clients to verify the contents. These techniques MAY also be
authorization. used for authorization.
7. Backwards Compatibility 7. Backwards Compatibility
Describing backwards compatibility is difficult because of the lack Describing backwards compatibility is difficult because of the lack
of specifics in the original definition. In this section some hints of specifics in the original definition. In this section, some hints
at building in backwards compatibility are given, mostly repeated at building in backwards compatibility are given, mostly repeated
from the relevant earlier sections. from the relevant earlier sections.
Backwards compatibility is not necessary, but the greater the extent Backwards compatibility is not necessary, but the greater the extent
of an implementation's compatibility the greater its of an implementation's compatibility, the greater its
interoperability. For turnkey implementations this is not usually a interoperability. For turnkey implementations, this is not usually a
concern. For general purpose implementations this takes on varying concern. For general-purpose implementations, this takes on varying
levels of importance depending on the implementer's desire to levels of importance, depending on the implementer's desire to
maintain interoperability. maintain interoperability.
It is unfortunate that a need to fall back to older behavior cannot It is unfortunate that a need to fall back to older behavior cannot
be discovered, hence needs to be noted in a configuration file. An be discovered, and thus has to be noted in a configuration file. An
implementation SHOULD, in its documentation, encourage operators to implementation SHOULD, in its documentation, encourage operators to
periodically review AXFR clients and servers it has made notes about periodically review AXFR clients and servers it has made notes about
repeatedly, as old software gets updated from time to time. repeatedly, as old software gets updated from time to time.
7.1. Server 7.1. Server
An AXFR server has the luxury of being able to react to an AXFR An AXFR server has the luxury of being able to react to an AXFR
client's abilities with the exception of knowing whether the client client's abilities, with the exception of knowing whether the client
can accept multiple resource records per AXFR response message. The can accept multiple resource records per AXFR response message. The
knowledge that a client is so restricted cannot be discovered, hence knowledge that a client is so restricted cannot be discovered; hence,
it has to be set by configuration. it has to be set by configuration.
An implementation of an AXFR server MAY permit configuring, on a per An implementation of an AXFR server MAY permit configuring, on a per
AXFR client basis, the necessity to revert to single resource record AXFR client basis, the necessity to revert to a single resource
per message; in that case, the default SHOULD be to use multiple record per message; in that case, the default SHOULD be to use
records per message. multiple records per message.
7.2. Client 7.2. Client
An AXFR client has the opportunity to try other features (i.e., those An AXFR client has the opportunity to try other features (i.e., those
not defined by this document) when querying an AXFR server. not defined by this document) when querying an AXFR server.
Attempting to issue multiple DNS queries over a TCP transport for an Attempting to issue multiple DNS queries over a TCP transport for an
AXFR session SHOULD be aborted if it interrupts the original request, AXFR session SHOULD be aborted if it interrupts the original request,
and SHOULD take into consideration whether the AXFR server intends to and SHOULD take into consideration whether the AXFR server intends to
close the connection immediately upon completion of the original close the connection immediately upon completion of the original
skipping to change at page 25, line 15 skipping to change at page 25, line 31
8. Security Considerations 8. Security Considerations
This document is a clarification of a mechanism outlined in RFCs 1034 This document is a clarification of a mechanism outlined in RFCs 1034
and 1035 and as such does not add any new security considerations. and 1035 and as such does not add any new security considerations.
RFC 3833 [RFC3833] is devoted entirely to security considerations for RFC 3833 [RFC3833] is devoted entirely to security considerations for
the DNS; its Section 4.3 delineates zone transfer security aspects the DNS; its Section 4.3 delineates zone transfer security aspects
from the security threats addressed by DNSSEC. from the security threats addressed by DNSSEC.
Concerns regarding authorization, traffic flooding, and message Concerns regarding authorization, traffic flooding, and message
integrity are mentioned in "Authorization" (Section 5), "TCP" integrity are mentioned in "Authorization" (Section 5), "TCP"
(Section 4.2) and "Zone Integrity" (Section 6). (Section 4.1), and "Zone Integrity" (Section 6).
9. IANA Considerations 9. IANA Considerations
IANA has added a reference to this RFC in the AXFR (252) row of the IANA has added a reference to this RFC in the AXFR (252) row of the
"Resource Record (RR) TYPEs" subregistry of the "Domain Name System "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
(DNS) Parameters" registry. (DNS) Parameters" registry.
10. Internationalization Considerations 10. Internationalization Considerations
The AXFR protocol is transparent to the parts of DNS zone content The AXFR protocol is transparent to the parts of DNS zone content
that can possibly be subject to Internationalization considerations. that can possibly be subject to Internationalization considerations.
It is assumed that for DNS labels and domain names, the issue has It is assumed that for DNS labels and domain names, the issue has
been solved via "Internationalizing Domain Names in Applications been solved via "Internationalizing Domain Names in Applications
(IDNA)" [RFC3490] or its successor(s). (IDNA)" [RFC3490] or its successor(s).
11. Acknowledgments 11. Acknowledgments
Earlier editions of this document have been edited by Andreas Earlier draft versions of this document have been edited by Andreas
Gustafsson. In his latest version, this acknowledgment appeared: Gustafsson. In his latest draft 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
Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin
Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton,
Trenholme, and Brian Wellington." Peter Koch, Sam Trenholme, and Brian Wellington.
Comments since the -05 version have come from these individuals: Comments on later draft versions 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, Niall O'Reilly, Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
Bill Manning, and other participants of the DNSEXT working group. Bill Manning, and other participants of the DNSEXT working group.
Significant comments from the IETF at large have been received from
Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani.
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 below -- like all RFCs -- and information about
at the URLs: http://rfc-editor.org/rfc.html the RFC series can be obtained from the RFC Editor web site at
or http://rfc-editor.org/rfcsearch.html ; http://www.rfc-editor.org.
information regarding this organization can be found at the following
URL: http://rfc-editor.org/
12.1. Normative References 12.1. Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and
STD 13, RFC 1034, November 1987. facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
and Support", STD 3, RFC 1123, October 1989. Application and Support", STD 3, RFC 1123, October 1989.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996. August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
RFC 2671, August 1999. 2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
RFC 2672, August 1999. 2672, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for
(TSIG)", RFC 2845, May 2000. DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, September 2000.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000. ( SIG(0)s )", RFC 2931, September 2000.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
November 2002. 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements", RFC
RFC 4033, March 2005. 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006 (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message
Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", Authentication Code, Secure Hash Algorithm) TSIG
RFC 4635, August 2006. Algorithm Identifiers", RFC 4635, August 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008 Existence", RFC 5155, March 2008.
[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA [RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 5395, November 2008. Considerations", BCP 42, RFC 5395, November 2008.
[RFC5702] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702, and RRSIG Resource Records for DNSSEC", RFC 5702, October
October 2009. 2009.
12.2. Informative References 12.2. Informative References
[DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters",
http://www.iana.org/assignments/dns-parameters http://www.iana.org/.
[IANA-AF] IANA Registry "Address Family Numbers", [IANA-AF] IANA Registry "Address Family Numbers",
http://www.iana.org/assignments/Address-family-numbers/ . http://www.iana.org/.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000. Networks", RFC 2764, February 2000.
[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.
[RFC3833] Atkins, D., and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[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", Work in Progress,
draft-ietf-dnsext-dnssec-bis-updates-10 (work in March 2010.
progress), March 2010.
Authors' Addresses Authors' Addresses
Edward Lewis Edward Lewis
46000 Center Oak Plaza 46000 Center Oak Plaza
Sterling, VA, 22033, US Sterling, VA 20166
US
Email: ed.lewis@neustar.biz EMail: ed.lewis@neustar.biz
Alfred Hoenes, Editor 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 ]]
Comments on this draft ought to be addressed to the editors and/or to
namedroppers@ops.ietf.org.
 End of changes. 132 change blocks. 
391 lines changed or deleted 419 lines changed or added

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