draft-ietf-dnsext-axfr-clarify-11.txt   draft-ietf-dnsext-axfr-clarify-12.txt 
DNS Extensions Working Group Edward Lewis
INTERNET-DRAFT NeuStar, Inc. DNS Extensions Working Group Edward Lewis
Expires: Octopber 1, 2009 April 2009 Internet-Draft NeuStar, Inc.
Updates: 1034, 1035 (if approved) Updates: 1034, 1035 (if approved) A. Hoenes
Intended status: Standards Track Intended status: Standards Track TR-Sys
Expires: June 6, 2010 December 6, 2009
DNS Zone Transfer Protocol (AXFR) DNS Zone Transfer Protocol (AXFR)
draft-ietf-dnsext-axfr-clarify-11.txt draft-ietf-dnsext-axfr-clarify-12
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the The Domain Name System standard mechanisms for maintaining coherent
provisions of BCP 78 and BCP 79. servers for a zone consist of three elements. One mechanism is the
Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
The definition of AXFR has proven insufficient in detail, thereby
forcing implementations intended to be compliant to make assumptions,
impeding interoperability. Yet today we have a satisfactory set of
implementations that do interoperate. This document is a new
definition of AXFR -- new in the sense that is it recording an
accurate definition of an interoperable AXFR mechanism.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 Internet-Draft is submitted to IETF in full conformance with the
and may be updated, replaced, or obsoleted by other documents at any provisions of BCP 78 and BCP 79. This document may contain material
time. It is inappropriate to use Internet-Drafts as reference from IETF Documents or IETF Contributions published or made publicly
material or to cite them other than as "work in progress." 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.
The list of current Internet-Drafts can be accessed at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/1id-abstracts.html Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html 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".
This Internet-Draft will expire on October 1, 2009. The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with and restrictions with respect to this document.
respect to this document.
Abstract Table of Contents
The Domain Name System standard mechanisms for maintaining coherent 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
servers for a zone consist of three elements. One mechanism is the 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
The definition of AXFR, has proven insufficient in detail, forcing 1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5
implementations intended to be compliant to make assumptions, impeding 1.4. Coverage and Relationship to Original AXFR Specification . 5
interoperability. Yet today we have a satisfactory set of 2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7
implementations that do interoperate. This document is a new 2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8
definition of the AXFR, new in the sense that is it recording an 2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9
accurate definition of an interoperable AXFR mechanism. 2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10
2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10
2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. "0 Message" Response . . . . . . . . . . . . . . . . . . 11
2.2.2. Header Values . . . . . . . . . . . . . . . . . . . . . 12
2.2.3. Question Section . . . . . . . . . . . . . . . . . . . . 14
2.2.4. Answer Section . . . . . . . . . . . . . . . . . . . . . 14
2.2.5. Authority Section . . . . . . . . . . . . . . . . . . . 14
2.2.6. Additional Section . . . . . . . . . . . . . . . . . . . 14
2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 14
3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15
3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16
3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18
3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20
4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21
4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22
6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24
7.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
10. Internationalization Considerations . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27
13. Editor's Address . . . . . . . . . . . . . . . . . . . . . 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 servers for a zone consist of three elements. Authoritative Transfer
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 Names [RFC1034] (referred to in this document as RFC 1034) and "Domain
- Implementation and Specification" [RFC1035] (aka RFC 1035). Names - Implementation and Specification" [RFC1035] (henceforth
Incremental Zone Transfer (IXFR) is defined in "Incremental Zone RFC 1035). Incremental Zone Transfer (IXFR) is defined in
Transfer in DNS" [RFC1995]. A mechanism for prompt notification of "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt
zone changes (NOTIFY) is defined in "A Mechanism for Prompt notification of zone changes (NOTIFY) is defined in "A Mechanism for
Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The
these mechanisms is to enable a set of DNS name servers to remain goal of these mechanisms is to enable a set of DNS name servers to
coherently authoritative for a given zone. remain coherently authoritative for a given zone.
Comments on this draft ought to be addressed to the editor or to This document re-specifies the AXFR mechanism as it is deployed in
namedroppers@ops.ietf.org. the Internet at large, hopefully with the precision expected from
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].
"Newer"/"New" DNS 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.
1.2 Scope "General purpose DNS implementation" refers to DNS software developed
for wide-spread use. This includes resolvers and servers freely
accessible as libraries and standalone processes. This also includes
proprietary implementations used only in support of DNS service
offerings.
In the greater context there are many ways to achieve coherency among "Turnkey DNS implementation" refers to custom made, single use
a set of name servers. The AXFR, IXFR and NOTIFY mechanisms form implementations of DNS. Such implementations consist of software
just one, the one defined in the RFCs cited. For example, there are that employs the DNS protocol message format yet does not conform to
DNS implementations that assemble answers from data stored in the entire range of DNS functionality.
relational databases (as opposed to master files) relying on the
database's non-DNS means to synchronize the database instances. Some
of these non-DNS solutions interoperate in some fashion. As far as
it is known, AXFR, IXFR and NOTIFY are the only in-band mechanisms
that provide an interoperable solution to the desire for coherency
within the definition of DNS, they certainly are the only mechanisms
documented by the IETF.
This document does not cover incoherent DNS situations. There are The terms "AXFR session", "AXFR server" and "AXFR client" will be
applications of the DNS in which servers for a zone are designed to be introduced in the first paragraph of Section 2, after some more
incoherent. For these configurations, a coherency mechanism as context has been established.
described here would be unsuitable.
"General purpose DNS implementation" refers to DNS software developed 1.2. Scope
for wide-spread use. This includes resolvers and servers freely
accessible as libraries and standalone processes. This also includes
proprietary implementations used only in support of DNS service
offerings.
"Turnkey DNS implementation" refers to custom made, single use In general terms, authoritative name servers for a given zone can use
implementations of DNS. Such implementations consist of software various means to achieve coherency of the zone contents they serve.
that employs the DNS protocol message format yet do not conform to For example, there are DNS implementations that assemble answers from
the entire range of DNS functionality. data stored in relational databases (as opposed to master files),
relying on the database's non-DNS means to synchronize the database
instances. Some of these non-DNS solutions interoperate in some
fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-
defined in-band mechanisms to provide coherence of a set of name
servers, and they are the only mechanisms specified by the IETF.
A DNS implementation is not required to support AXFR, IXFR and NOTIFY. This document does not cover incoherent DNS situations. There are
A DNS implementation SHOULD have some means for maintaining name server applications of the DNS in which servers for a zone are designed to
coherency. A general purpose DNS implementation SHOULD include AXFR be incoherent. For these configurations, a coherency mechanism as
(and in the same vein IXFR and NOTIFY), but turnkey DNS implementations described here would be unsuitable.
MAY exist without AXFR. (An editorial note to readers of this section.
The mention of IXFR and NOTIFY is for context and illustration, this
document does not make any normative comments on those mechanisms.)
1.3 Context A DNS implementation is not required to support AXFR, IXFR, and
NOTIFY, but it should have some means for maintaining name server
coherency. A general purpose DNS implementation will likely support
AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
implementations may exist without AXFR.
Besides describing the mechanisms themselves, there is the context in 1.3. Context
which they operate to consider. When AXFR, IXFR and NOTIFY were
defined, there was little consideration given to security and privacy
issues. Since the original definition of AXFR, new opinions have
appeared on the access to an entire zone's contents. In this document,
the basic mechanisms will be discussed separately from the permission
to use these mechanisms.
1.4 Coverage and Relationship to Original AXFR Specification Besides describing the mechanisms themselves, there is the context in
which they operate to consider. In the initial specifications of
AXFR (and IXFR and NOTIFY), little consideration was given to
security and privacy issues. Since the original definition of AXFR,
new opinions have appeared on the access to an entire zone's
contents. In this document, the basic mechanisms will be discussed
separately from the permission to use these mechanisms.
This document concentrates on just the definition of AXFR. Any effort 1.4. Coverage and Relationship to Original AXFR Specification
to update the IXFR or NOTIFY mechanisms would be done in different
documents.
The original "specification" of the AXFR sub-protocol is scattered This document concentrates on just the definition of AXFR. Any
depicts the scenario for which AXFR has been designed. Section 4.3.5 effort to update the specification of the IXFR or NOTIFY mechanisms
of RFC 1034 describes the zone synchronization strategies in general is left to different documents.
and rules for the invocation of a full zone transfer via AXFR; the
fifth paragraph of that section contains a very short sketch of the
AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
the code point for the AXFR QTYPE (see section 2.1.2 below for more
details). Section 4.2 of RFC 1035 discusses the transport layer use
of DNS and shortly explains why UDP transport is deemed inappropriate
for AXFR; the last paragraph of Section 4.2.2 gives details for the
TCP connection management with AXFR. Finally, the second paragraph
of Section 6.3 in RFC 1035 mandates server behavior when zone data
changes occur during an ongoing zone transfer using AXFR.
This document will update the specification of AXFR in fully The original "specification" of the AXFR sub-protocol is scattered
specifying the record formats and processing rules for AXFR, largely through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5)
expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing depicts the scenario for which AXFR has been designed. Section 4.3.5
the transport considerations for AXFR, thus amending Section 4.2.2 of of RFC 1034 describes the zone synchronization strategies in general
RFC 1035. Furthermore, it discusses backward compatibility issues and rules for the invocation of a full zone transfer via AXFR; the
and provides policy/management considerations as well as specific fifth paragraph of that section contains a very short sketch of the
Security Considerations for AXFR. The goal of this document is to AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
define AXFR as it exists, or is supposed to exist, currently. flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
the code point for the AXFR QTYPE (see Section 2.1.2 below for more
details). Section 4.2 of RFC 1035 discusses the transport layer use
of DNS and shortly explains why UDP transport is deemed inappropriate
for AXFR; the last paragraph of Section 4.2.2 gives details for the
TCP connection management with AXFR. Finally, the second paragraph
of Section 6.3 in RFC 1035 mandates server behavior when zone data
changes occur during an ongoing zone transfer using AXFR.
2 AXFR Messages This document will update the specification of AXFR. To this end, it
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
details the transport considerations for AXFR, thus amending Section
4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility
issues and provides policy/management considerations as well as
specific Security Considerations for AXFR. The goal of this document
is to define AXFR as it exists, or is supposed to exist, currently.
An AXFR session consists of an AXFR query message and the sequence of 2. AXFR Messages
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
responder. (Use of terms such as master, slave, primary, secondary
are not important to defining AXFR.) The use of the word "session"
without qualification refers to an AXFR session.
An important aspect to keep in mind is that the definition of AXFR is An AXFR session consists of an AXFR query message and the sequence of
restricted to TCP [RFC0793]. The design of the AXFR process has AXFR response messages returned for it. In this document, the AXFR
certain inherent features that are not easily ported to UDP [RFC0768]. client is the sender of the AXFR query and the AXFR server is the
responder. (Use of terms such as master, slave, primary, secondary
are not important to defining AXFR.) The use of the word "session"
without qualification refers to an AXFR session.
The basic format of an AXFR message is the DNS message as defined in An important aspect to keep in mind is that the definition of AXFR is
RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: restricted to TCP [RFC0793]. The design of the AXFR process has
- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996] certain inherent features that are not easily ported to UDP
- "Domain Name System (DNS) IANA Considerations" [RFC5395] [RFC0768].
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- "Clarifications to the DNS Specification" [RFC2181]
- "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- "Use of SHA-256 in DNSSEC ... (DS) ... (RRs)" [RFC4509]
- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
- "... (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155]
For completeness, the following, in process, documents contain The basic format of an AXFR message is the DNS message as defined in
information about the DNS message. These documents ought not interfere Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
with AXFR but these documents are helpful in understanding what will following documents.
be carried via AXFR.
- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource o The 'Basic' DNS specification:
Records for DNSSEC" [DRAFT1]
- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2]
The upper limit on the permissible size of a DNS message over TCP is - "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)"
only restricted by the TCP framing defined in RFC 1035, section 4.2.2 [RFC1996]
which specifies a two-octet message length field, understood to be - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
unsigned, and thus causing a limit of 65535 octets. Unlike DNS - "Clarifications to the DNS Specification" [RFC2181]
messages over UDP, this limit is not changed by EDNS0. - "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
- "Domain Name System (DNS) IANA Considerations" [RFC5395]
Note that the TC (truncation) bit is never set by an AXFR server nor o Further additions related to the DNS Security Extensions (DNSSEC),
considered/read by an AXFR client. defined in these base documents:
Field names used in this document will correspond to the names as they - "DNS Security Introduction and Requirements" [RFC4033]
appear in the IANA registry for DNS Header Flags [DNSFLGS]. - "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
- "DNS Security 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]
2.1 AXFR query These documents contain information about the syntax and semantics of
DNS messages. They ought not interfere with AXFR but are also
helpful in understanding what will be carried via AXFR.
An AXFR query is sent by a client whenever there is a reason to ask. For convenience, the synopsis of the DNS message header from
This might be because of zone maintenance activities or as a result of [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
a command line request, say for debugging. reproduced here informally:
An AXFR query is sent by a client whenever there is a reason to ask. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
This might be because of scheduled or triggered zone maintenance +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
activities (see section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], | ID |
respectively) or as a result of a command line request, say for +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
debugging. |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2.1.1 Header Values 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
capitalized in this document for clarity, e.g., "Additional section".
These are the DNS message header values for an AXFR query. The DNS message size limit from [RFC1035] for DNS over UDP (and its
extension via the EDNS0 mechanism specified in [RFC2671]) is not
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
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
causing a limit of 65535 octets. This limit is not changed by EDNS0.
ID See note 2.1.1.a Note that the TC (truncation) bit is never set by an AXFR server nor
QR MUST be 0 (Query) considered/read by an AXFR client.
OPCODE MUST be 0 (Standard Query)
AA See note 2.1.1.b
TC See note 2.1.1.b
RD See note 2.1.1.b
RA See note 2.1.1.b
Z See note 2.1.1.c
AD See note 2.1.1.b
CD See note 2.1.1.b
RCODE MUST be 0 (No error)
QDCOUNT MUST be 1
ANCOUNT MUST be 0
NSCOUNT MUST be 0
ARCOUNT See note 2.1.1.d
Note 2.1.1.a Set to any value that the client is not already using 2.1. AXFR query
with the same server. There is no specific means for selecting the
value in this field. (Recall that AXFR is done only via TCP
connections.)
A server MUST reply using messages that use the same message ID to An AXFR query is sent by a client whenever there is a reason to ask.
allow a client to meaningfully have multiple AXFR queries outstanding. This might be because of scheduled or triggered zone maintenance
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
debugging.
Note 2.1.1.b The value in this field has no meaning in the context of 2.1.1. Header Values
AXFR query messages. For the client, it is RECOMMENDED that the
value be zero. The server MUST ignore this value.
Note 2.1.1.c The client MUST set this bit to 0, the server MUST ignore These are the DNS message header values for an AXFR query.
it.
Note 2.1.1.d The client MUST set this field to be the number of ID Selected by client; see Note a)
resource records appearing in the additional section. See Section
2.1.5 "Additional Section" for details.
The value MAY be 0, 1 or 2. If it is 2, the additional QR MUST be 0 (Query)
section MUST contain both an EDNS0 [RFC2671] OPT resource record and
a record carrying transaction integrity and authentication data,
currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
value is 1, then the additional section MUST contain either only an
EDNS0 OPT resource record or a record carrying transaction integrity
and authentication data. If the value is 0, the additional section
MUST be empty.
2.1.2 Query Section OPCODE MUST be 0 (Standard Query)
The Query section of the AXFR query MUST conform to section 4.1.2 of Flags:
RFC 1035, and contain the following values: AA 'n/a' -- see Note b)
TC 'n/a' -- see Note b)
RD 'n/a' -- see Note b)
RA 'n/a' -- see Note b)
Z 'mbz' -- see Note c)
AD 'n/a' -- see Note b)
CD 'n/a' -- see Note b)
QNAME the name of the zone requested RCODE MUST be 0 (No error)
QTYPE AXFR(= 252), the pseudo-RR type for zone transfer [DNSVALS]
QCLASS the class of the zone requested
2.1.3 Answer Section QDCOUNT Number of entries in Question section; MUST be 1
MUST be empty. ANCOUNT Number of entries in Answer section; MUST be 0
2.1.4 Authority Section NSCOUNT Number of entries in Authority section; MUST be 0
MUST be empty. ARCOUNT Number of entries in Additional section -- see Note d)
2.1.5 Additional Section Notes:
The client MAY include an EDNS0 OPT [RFC2671] resource record. If the a) Set to any value that the client is not already using with the
server has indicated that it does not support EDNS0, the client MUST same server. There is no specific means for selecting the value
send this section without an EDNS0 OPT resource record if there is a in this field. (Recall that AXFR is done only via TCP connections
retry. Indication that a server does not support EDNS0 is not an -- see Section 4 "Transport".)
explicit element in the protocol, it is up to the client to interpret.
Most likely, the server will return a FORMERR which might be related to
the OPT resource record.
The client MAY include a transaction integrity and authentication A server MUST reply using messages that use the same message ID to
resource record, currently a choice of TSIG [RFC2845] or SIG(0) allow a client to have multiple queries outstanding concurrently
[RFC2931]. If the server has indicated that it does not recognize the over the same TCP connection -- see Note a) in Section 2.2.2 for
resource record, and that the error is indeed caused by the resource more details.
record, the client probably ought not try again. Removing the security
data in the face of an obstacle ought to only be done with full
awareness of the implication of doing so.
In general, if an AXFR client is aware that an AXFR server does not b) 'n/a' -- The value in this field has no meaning in the context of
support a particular mechanism, the client SHOULD NOT attempt to engage AXFR query messages. For the client, it is RECOMMENDED that the
the server using the mechanism (or at all). A client could become value be zero. The server MUST ignore this value.
aware of a server's abilities via a configuration setting or via some
other (as yet) undefined means.
The range of permissible resource records that MAY appear in the c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
additional section might change over time. If either a change to an it.
existing resource record (like the OPT RR for EDNS0) is made or
a new additional section record is created, the new definitions ought
to include a discussion on the impact upon AXFR. Although this is not
predictable, future additional section residing records may have an
effect that is orthogonal to AXFR, so can ride through the session as
opaque data. In this case, a "wise" implementation ought to be able
to pass these records through without disruption.
2.2 AXFR response d) The client MUST set this field to the number of resource records
appearing in the Additional section. See Section 2.1.5
"Additional Section" for details.
The AXFR response will consist of 0 or more messages. A "0 message" The value MAY be 0, 1 or 2. If it is 2, the Additional section
response is covered in section 2.2.1. MUST contain both an EDNS0 [RFC2671] OPT resource record and a
record carrying transaction integrity and authentication data,
currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
value is 1, then the Additional section MUST contain either only
an EDNS0 OPT resource record or a record carrying transaction
integrity and authentication data. If the value is 0, the
Additional section MUST be empty.
An AXFR response that is transferring the zone's contents will consist 2.1.2. Question Section
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 SOA
resource record of the zone, the last message MUST conclude with the
same SOA resource record. Intermediate messages MUST NOT contain the
SOA resource record. The first message MUST copy the Query Section
from the corresponding AXFR query message in to the first response
message's query section. Subsequent messages MAY do the same.
An AXFR response that is indicating an error MUST consist of a single The Query section of the AXFR query MUST conform to Section 4.1.2 of
DNS message with the return code set to the appropriate value for the RFC 1035, and contain a single resource record with the following
condition encountered - once the error condition is detected. Such values:
a message MUST terminate the AXFR session; it MUST copy the Query
Section from the AXFR query into its Query Section, but the inclusion
of the terminating SOA resource record is not necessary.
An AXFR client might receive a number of AXFR response messages QNAME the name of the zone requested
free of an error condition before the message indicating an error
is received.
2.2.1 "0 Message" Response QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
[DNSVALS]
A legitimate "0 message" response, i.e., the client sees no response QCLASS the class of the zone requested [DNSVALS]
whatsoever, is very exceptional and controversial. Unquestionably it
is unhealthy for there to be 0 responses in a protocol that is designed
around a query - response paradigm over an unreliable transport. The
lack of a response could be a sign of underlying network problems and
cause the protocol state machine to react accordingly. However, AXFR
uses TCP and not UDP, eliminating undetectable network errors.
A "0 message response" is reserved for situations in which the server 2.1.3. Answer Section
has a reason to suspect that the query is sent for the purpose of
abuse. Due to the use of this being so controversial, a "0 message
response" is not being defined as a legitimate part of the protocol
but the use of it is being acknowledged as a warning to AXFR client
implementations. Any earnest query has the expectation of some
response but may not get one.
2.2.2 Header Values The Answer section MUST be empty.
ID See note 2.2.2.a 2.1.4. Authority Section
QR MUST be 1 (Response)
OPCODE MUST be 0 (Standard Query)
AA See note 2.2.2.b
TC MUST be 0 (Not truncated)
RD RECOMMENDED copy request's value, MAY be set to 0
RA See note 2.2.2.c
Z See note 2.2.2.d
AD See note 2.2.2.e
CD See note 2.2.2.e
RCODE See note 2.2.2.f
QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all
following
ANCOUNT See note 2.2.2.g
NSCOUNT MUST be 0
ARCOUNT See note 2.2.2.h
Note 2.2.2.a Because some old implementations behave differently than The Authority section MUST be empty.
is now 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 in each AXFR response message for the session. AXFR clients MUST
be able to manage sessions resulting from the issuance of multiple
outstanding queries, whether AXFR queries or other DNS queries. A
client SHOULD discard responses that do not correspond (via the
message ID) to any outstanding queries.
Unless the client is sure that the server will consistently set the ID 2.1.5. Additional Section
field to the query's ID, the client is NOT RECOMMENDED to issue any
other queries until the end of the zone transfer. A client MAY become
aware of a server's abilities via a configuration setting.
Note 2.2.2.b If the RCODE is 0 (no error), then the AA bit MUST be 1. The client MAY include an EDNS0 OPT [RFC2671] resource record. If
For any other value of RCODE, the AA bit MUST be set according to rules the server does not support EDNS0, the client MUST send this section
for that error code. If in doubt, it is RECOMMENDED that it be set without an EDNS0 OPT resource record if there is a retry. However,
to 1. It is RECOMMENDED that the value be ignored by the AXFR client. the protocol does not define an explicit indication that the server
does not support EDNS0; that needs to be inferred by the client.
Often, the server will return a FormErr(1) which might be related to
the OPT resource record.
Note 2.2.2.c It is RECOMMENDED that the server set the value to 0, The client MAY include a transaction integrity and authentication
the client MUST ignore this value. resource record, currently a choice of TSIG [RFC2845] or SIG(0)
[RFC2931]. If the server has indicated that it does not recognize
the resource record, and that the error is indeed caused by the
resource record, the client probably should not try again. Removing
the security data in the face of an obstacle ought to only be done
with full awareness of the implication of doing so.
The server MAY set this value according to the local policy regarding In general, if an AXFR client is aware that an AXFR server does not
recursive service, but doing so might confuse the interpretation of the support a particular mechanism, the client SHOULD NOT attempt to
response as AXFR can not be retrieved recursively. A client MAY note engage the server using the mechanism (or at all). A client could
the server's policy regarding recursive service from this value, but become aware of a server's abilities via a configuration setting or
SHOULD NOT conclude that the AXFR response was obtained recursively via some other (as yet) undefined means.
even if the RD bit was 1 in the query.
Note 2.2.2.d The server MUST set this bit to 0, the client MUST ignore The range of permissible resource records that MAY appear in the
it. Additional section might change over time. If either a change to an
existing resource record (like the OPT RR for EDNS0) is made or a new
Additional section record is created, the new definitions ought to
include a discussion on the impact upon AXFR. Future resource
records residing in the Additional section might have an effect that
is orthogonal to AXFR, so can ride through the session as opaque
data. In this case, a "wise" implementation ought to be able to pass
these records through without disruption.
Note 2.2.2.e If the implementation supports the DNS Security Extensions 2.2. AXFR Response
(see below) then this value MUST be set according to the rules in RFC
4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response".
If the implementation does not support the DNS Security Extensions,
then this value MUST be set to 0 and MUST be ignored upon receipt.
The DNS Security Extensions (DNSSEC) is defined in these base The AXFR response will consist of 0 or more messages. A "0 message"
documents: response is covered in Section 2.2.1.
- "DNS Security Introduction and Requirements" [RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
- "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
as well pending documents, such as these: 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
messages. In such a series, the first message MUST begin with the
SOA resource record of the zone, the last message MUST conclude with
the same SOA resource record. Intermediate messages MUST NOT contain
the SOA resource record. The AXFR server MUST copy the Question
section from the corresponding AXFR query message in to the first
response message's Question section. Subsequent messages MAY do the
same or contain an empty Question section.
- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource An AXFR response indicates an error via a single DNS message with the
Records for DNSSEC" [DRAFT1] return code set to the appropriate value for the condition
- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2] encountered, sent once the error condition is detected. Such a
message terminates the AXFR session; it MUST copy the Query Section
from the AXFR query into its Query Section, but the inclusion of the
terminating SOA resource record is not necessary.
Note 2.2.2.f In the absence of an error, the server MUST set the value An AXFR server may send a number of AXFR response messages free of an
of this field to NoError. If a server is not authoritative for the error condition before it sends the message indicating an error.
queried zone, the server SHOULD set the value to NotAuth. (Reminder,
consult the appropriate IANA registry [DNSVALS].) If a client
receives any other value in response, it MUST act according to the
error. For example, a malformed AXFR query or the presence of an EDNS0
OPT resource record sent to an old server will garner a FormErr value.
This value is not set as part of the AXFR-specific response processing.
The same is true for other error-indicating values.
Note 2.2.2.g The count of answer records MUST equal the number of 2.2.1. "0 Message" Response
resource records in the AXFR Answer Section. When a server is aware
that a client will only accept one resource record per response
message, then the value MUST be 1. A server MAY be made aware of a
client's limitations via configuration data.
Note 2.2.2.h The client MUST set this field to be the number of A legitimate "0 message" response, i.e., the client sees no response
resource records appearing in the additional section. The whatsoever, is very exceptional and controversial. Unquestionably it
considerations in Note 2.1.1.d above apply equally; see Section is unhealthy for there to be 0 responses in a protocol that is
2.2.6 "Additional Section" below for more details. designed around a query - response paradigm over an unreliable
transport. The lack of a response could be a sign of underlying
network problems and cause the protocol state machine to react
accordingly. However, AXFR uses TCP and not UDP, eliminating
undetectable network errors.
2.2.3 Query Section A "0 message response" is reserved for situations in which the server
has a reason to suspect that the query is sent for the purpose of
abuse. Due to the use of this being so controversial, a "0 message
response" is not being defined as a legitimate part of the protocol
but the use of it is being acknowledged as a warning to AXFR client
implementations. Any earnest query has the expectation of some
response but nevertheless may not get one.
In the first response message, this section MUST be copied from the 2.2.2. Header Values
query. In subsequent messages, this section MAY be copied from the
query or it MAY be empty. The content of this section MAY be used to
determine the context of the message, that is, the name of the zone
being transferred.
2.2.4 Answer Section These are the DNS message header values for AXFR responses.
MUST be populated with the zone contents. See later section on ID MUST be copied from request -- see Note a)
encoding zone contents.
2.2.5 Authority Section QR MUST be 1 (Response)
MUST be empty. OPCODE MUST be 0 (Standard Query)
2.2.6 Additional Section Flags:
AA normally 1 -- see Note b)
TC MUST be 0 (Not truncated)
RD RECOMMENDED: copy request's value, MAY be set to 0
RA SHOULD be 0 -- see Note c)
Z 'mbz' -- see Note d)
AD covered by DNSSEC rules -- see Note e)
CD covered by DNSSEC rules -- see Note e)
The contents of this section MUST follow the guidelines for EDNS0, RCODE See Note f)
TSIG, SIG(0), or what ever other future record is possible here. The
contents of section 2.1.5 apply here as well.
2.3 TCP Connection Aborts QDCOUNT MUST be 1 in the first message;
MUST be 0 or 1 in all following messages;
MUST be 1 if RCODE indicates an error
If an AXFR client sends a query on a TCP connection and the connection ANCOUNT See Note g)
is closed at any point, the AXFR client MUST consider the AXFR session
terminated. The message ID MAY be used again on a new connection,
even if the question and AXFR server are the same. Facing a dropped
connection a client SHOULD try to make some determination whether the
connection closure was the result of network activity or a decision
by the AXFR server. This determination is not an exact science. It
is up to the AXFR client implementor to react, but the reaction
SHOULD NOT be an endless cycle of retries nor an increasing (in
frequency) retry rate.
An AXFR server implementor SHOULD take into consideration the dilemma NSCOUNT MUST be 0
described above when a connection is closed with an outstanding query
in the pipeline. For this reason, a server ought to reserve this
course of action for situations in which it believes beyond a doubt
that the AXFR client is attempting abusive behavior.
3 Zone Contents ARCOUNT See Note h)
The objective of the AXFR session is to request and transfer the Notes:
contents of a zone. The objective is to permit the AXFR client to
reconstruct the zone as it exists at the server for the given zone
serial number. Over time the definition of a zone has evolved from
denoting a static set of records to also cover a dynamically updated
set of records, and then a potentially continually regenerated set of
records as well.
3.1 Records to Include a) Because some old implementations behave differently than is now
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
in each AXFR response message for the session. AXFR clients MUST
be able to manage sessions resulting from the issuance of multiple
outstanding queries, whether AXFR queries or other DNS queries.
A client SHOULD discard responses that do not correspond (via the
message ID) to any outstanding queries.
In the answer section of AXFR response messages the resource records Unless the client is sure that the server will consistently set
within a zone for the given serial number MUST appear. The definition the ID field to the query's ID, the client is NOT RECOMMENDED to
of what belongs in a zone is described in RFC 1034, Section 4.2, "How issue any other queries until the end of the zone transfer.
the database is divided into zones", in particular, section 4.2.1, A client MAY become aware of a server's abilities via a
"Technical considerations", and it has been clarified in Section 6 of configuration setting.
RFC 2181.
Unless the AXFR server knows that the AXFR client is old and expects b) If the RCODE is 0 (no error), then the AA bit MUST be 1.
just one resource record per AXFR response message, an AXFR server For any other value of RCODE, the AA bit MUST be set according to
SHOULD populate an AXFR response message with as many complete the rules for that error code. If in doubt, it is RECOMMENDED
resource record sets as will fit within a DNS message. that it be set to 1. It is RECOMMENDED that the value be ignored
by the AXFR client.
Zones for which it is impractical to list the entire zones for a serial c) It is RECOMMENDED that the server set the value to 0, the client
number are not suitable for AXFR retrieval. A typical (but not MUST ignore this value.
limiting) description of such a zone is a zone consisting of responses
generated via other database lookups and/or computed based upon ever
changing data.
3.2 Delegation Records The server MAY set this value according to the local policy
regarding recursive service, but doing so might confuse the
interpretation of the response as AXFR can not be retrieved
recursively. A client MAY note the server's policy regarding
recursive service from this value, but SHOULD NOT conclude that
the AXFR response was obtained recursively even if the RD bit was
1 in the query.
In RFC 1034, section 4.2.1, this text appears (keep in mind that the d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
"should" in the quotation predates [BCP14], cf. section 1.1) "The RRs it.
that describe cuts ... should be exactly the same as the corresponding
RRs in the top node of the subzone." There has been some controversy
over this statement and the impact on which NS resource records are
included in a zone transfer.
The phrase "that describe cuts" is a reference to the NS set and e) If the implementation supports the DNS Security Extensions (DNSSEC
applicable glue records. It does not mean that the cut point and apex -- see Section 2), then this value MUST be set according to the
resource records are identical. For example, the SOA resource record rules in RFC 4035, Section 3.1.6, "The AD and CD Bits in an
is only found at the apex. The discussion here is restricted to just Authoritative Response". If the implementation does not support
the NS resource record set and glue as these "describe cuts". the DNS Security Extensions, then this value MUST be set to 0 and
MUST be ignored upon receipt.
DNSSEC resource records have special specifications regarding their f) In the absence of an error, the server MUST set the value of this
occurrence at a zone cut and the apex of a zone. This has for the field to NoError(0). If a server is not authoritative for the
first time been described in Sections 5.3 ff. and 6.2 of RFC 2181 queried zone, the server SHOULD set the value to NotAuth(9).
(for the initial specification of DNSSEC), which now is historical. (Reminder, consult the appropriate IANA registry [DNSVALS].) If a
The current DNSSEC core document set (see Note 2.2.2.e above) gives client receives any other value in response, it MUST act according
the full details for DNSSEC(bis) resource record placement, and to the error. For example, a malformed AXFR query or the presence
Section 3.1.5 of RFC 4035 normatively specifies their treatment during of an EDNS0 OPT resource record sent to an old server will garner
AXFR; the alternate NSEC3 resource record defined later in RFC 5155 a FormErr(1) value. This value is not set as part of the AXFR-
behaves identically as the NSEC RR, for the purpose of AXFR. specific response processing. The same is true for other values
indicating an error.
Informally: g) The count of answer records MUST equal the number of resource
o The DS RRSet only occurs at the parental side of a zone cut and is records in the AXFR Answer Section. When a server is aware that a
authoritative data in the parent zone, not the secure child zone. client will only accept one resource record per response message,
o The DNSKEY RRSet only occurs at the APEX of a signed zone and is then the value MUST be 1. A server MAY be made aware of a
authoritative part of the zone it serves. client's limitations via configuration data.
o Independent RRSIG RRSets occur at the signed parent side and of a
zone cut and at the apex of a signed zone; they are authoritative
part of the respective zone; simple queries for RRSIG resource
records may return bth RRSets at once if the same server is
authoritative for the parent zone and the child zone (Section
3.1.5 of RFC 4035 describes how to distinguish these RRs); this
seeming ambiguity does not occur for AXFR, since each such RRSIG
RRset belongs to a single zone.
o Different NSEC [RFC4034] or NSEC3 [RFC5155] resource records
equally may occur at the parental siede of a zone cut and at the
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.
The issue is that in operations there are times when the NS resource h) The client MUST set this field to the number of resource records
records for a zone might be different at a cut point in the parent and appearing in the Additional section. The considerations of Note
at the apex of a zone. Sometimes this is the result of an error and d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional
sometimes it is part of an ongoing change in name servers. The DNS Section" below for more details.
protocol is robust enough to overcome inconsistencies up to (but not
including) there being no parent indicated NS resource record
referencing a server that is able to serve the child zone. This
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
to make it apparent (if it is unplanned) and to make it clear once
the inconsistency has been removed.
Another issue is that the AXFR server could be authoritative for a 2.2.3. Question Section
different set of zones than the AXFR client. It is possible that the
AXFR server be authoritative for both halves of an inconsistent cut
point and that the AXFR client is authoritative for just the parent of
the cut point.
The question that arises is, when facing a situation in which a cut In the first response message, this section MUST be copied from the
point's NS resource records do not match the authoritative set, whether query. In subsequent messages, this section MAY be copied from the
an AXFR server responds with the NS resource record set that is in the query or it MAY be empty. However, in an error response message (see
zone being transferred or is at the authoritative location. Section 2.2), this section MUST be copied as well. The content of
this section MAY be used to determine the context of the message,
that is, the name of the zone being transferred.
The AXFR response MUST contain the cut point NS resource record set 2.2.4. Answer Section
registered with the zone whether it agrees with the authoritative set
or not. "Registered with" can be widely interpreted to include data
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
the zone (database), statically or dynamically.
The reasons for this requirement are: MUST be populated with the zone contents. See Section 3 below on
encoding zone contents.
1) The AXFR server might not be able to determine that there is an 2.2.5. Authority Section
inconsistency given local data, hence requiring consistency would mean
a lot more needed work and even network retrieval of data. An
authoritative server ought not be required to perform any queries.
2) By transferring the inconsistent NS resource records from a server The Authority section MUST be empty.
that is authoritative for both the cut point and the apex to a client
that is not authoritative for both, the error is exposed. For example,
an authorized administrator can manually request the AXFR and inspect
the results to see the inconsistent records. (A server authoritative
for both halves would otherwise always answer from the more
authoritative set, concealing the error.)
3) The inconsistent NS resource record set might indicate a problem 2.2.6. Additional Section
in a registration database.
4) This requirement is necessary to ensure that retrieving a given The contents of this section MUST follow the guidelines for EDNS0 and
(zone,serial) pair by AXFR yields the exact same set of resource TSIG, SIG(0), or whatever other future record is possible here. The
records no matter which of the zone's authoritative servers is contents of Section 2.1.5 apply analogously as well.
chosen as the source of the transfer.
If an AXFR server were allowed to respond with the authoritative 2.3. TCP Connection Aborts
NS RRset of a child zone instead of a glue NS RRset in the zone
being transferred, the set of records returned could vary depending
on whether or not the server happens to also be authoritative for
the child zone.
The property that a given (zone,serial) pair corresponds to a If an AXFR client sends a query on a TCP connection and the
single, well-defined set of records is necessary for the correct connection is closed at any point, the AXFR client MUST consider the
operation of incremental transfer protocols such as IXFR AXFR session terminated. The message ID MAY be used again on a new
[RFC1995]. For example, a client may retrieve a zone by AXFR from connection, even if the question and AXFR server are the same.
one server, and then apply an incremental change obtained by IXFR
from a different server. If the two servers have different ideas
of the zone contents, the client can end up attempting to
incrementally add records that already exist or to delete records
that do not exist.
3.3 Glue Records Facing a dropped connection, a client SHOULD try to make some
determination whether the connection closure was the result of
network activity or a decision by the AXFR server. This
determination is not an exact science. It is up to the AXFR client
implementor to react, but the reaction SHOULD NOT be an endless cycle
of retries nor an increasing (in frequency) retry rate.
As quoted in the previous section, section 4.2.1 of RFC 1034 provides An AXFR server implementor SHOULD take into consideration the dilemma
guidance and rationale for the inclusion of glue records as part of described above when a connection is closed with an outstanding query
an AXFR transfer. And, as also argued in the previous section of this in the pipeline. For this reason, a server ought to reserve this
document, even when there is an inconsistency between the address in a course of action for situations in which it believes beyond a doubt
glue record and the authoritative copy of the name server's address, that the AXFR client is attempting abusive behavior.
the glue resource record that is registered as part of the zone for
that serial number is to be included.
This applies to glue records for any address family [RFC1700]. 3. Zone Contents
The AXFR response MUST contain the appropriate glue records as The objective of the AXFR session is to request and transfer the
registered with the zone. The interpretation of "registered with" contents of a zone. The objective is to permit the AXFR client to
in the previous section applies here. Inconsistent glue records are reconstruct the zone as it exists at the server for the given zone
an operational matter. serial number. Over time the definition of a zone has evolved from
denoting a static set of records to also cover a dynamically updated
set of records, and then a potentially continually regenerated set of
records (e.g., RRs synthesized "on the fly" from rule sets or
database lookup results in other forms than RR format) as well.
3.4 Name Compression 3.1. Records to Include
Compression of names in DNS messages is described in RFC 1035, section In the Answer section of AXFR response messages the resource records
4.1.4, "Message compression". The issue highlighted here relates to a within a zone for the given serial number MUST appear. The
comment made in RFC 1034, section 3.1, "Name space specifications and definition of what belongs in a zone is described in RFC 1034,
terminology" which says "When you receive a domain name or label, you Section 4.2, "How the database is divided into zones" (in particular
should preserve its case." ("Should" in the quote predates [BCP14].) Section 4.2.1, "Technical considerations"), and it has been clarified
in Section 6 of RFC 2181.
Name compression in an AXFR message MUST preserve the case of the Unless the AXFR server knows that the AXFR client is old and expects
original domain name. That is, although when comparing a domain name, just one resource record per AXFR response message, an AXFR server
"a" equals "A", when comparing for the purposes of message compression, SHOULD populate an AXFR response message with as many complete
"a" is not equal to "A". Note that this is not the usual definition resource record sets as will fit within a DNS message.
of name comparison in the DNS protocol and represents a new
requirement on AXFR servers.
Rules governing name compression of RDATA in an AXFR message MUST Zones for which it is impractical to list the entire zone for a
abide by the specification in "Handling of Unknown DNS Resource Record serial number are not suitable for AXFR retrieval. A typical (but
(RR) Types" [RFC3597], specifically, section 4 on "Domain Name not limiting) description of such a zone is a zone consisting of
Compression." responses generated via other database lookups and/or computed based
upon ever changing data.
3.5 Occluded Names 3.2. Delegation Records
Dynamic Update [RFC2136] operations, and in particular its interaction In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
with DNAME [RFC2672], can have a side effect of occluding names in a the "should" in the quotation predates [BCP14], cf. Section 1.1):
zone. The addition of a delegation point via dynamic 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 addition of a
DNAME resource record has the same impact. The subordinate names are
said to be "occluded."
Occluded names MUST be included in AXFR responses. An AXFR client MUST "The RRs that describe cuts ... should be exactly the same as the
be able to identify and handle occluded names. The rationale for this corresponding RRs in the top node of the subzone."
action is based on a speedy recovery if the dynamic update operation
was in error and is to be undone.
4 Transport There has been some controversy over this statement and the impact on
which NS resource records are included in a zone transfer.
AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC The phrase "that describe cuts" is a reference to the NS set and
1034 that states: "Because accuracy is essential, TCP or some other applicable glue records. It does not mean that the cut point and
reliable protocol must be used for AXFR requests." The restriction to apex resource records are identical. For example, the SOA resource
TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet record is only found at the apex. The discussion here is restricted
Hosts - Application and Support" [RFC1123]. to just the NS resource record set and glue as these "describe cuts".
The most common scenario is for an AXFR client to open a TCP connection DNSSEC resource records have special specifications regarding their
to the AXFR server, send an AXFR query, receive the AXFR response, and occurrence at a zone cut and the apex of a zone. This was first
then close the connection. There are variations on this, such as a described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
query for the zone's SOA resource record first, and so on. Note that specification of DNSSEC), which parts of RFC 2181 now in fact are
this is documented as a most common scenario. historical. The current DNSSEC core document set (see Note e) in
Section 2.2.2 above) gives the full details for DNSSEC(bis) resource
record placement, and Section 3.1.5 of RFC 4035 normatively specifies
their treatment during AXFR; the alternate NSEC3 resource record
defined later in RFC 5155 behaves identically as the NSEC RR, for the
purpose of AXFR.
The assumption that a TCP connection is dedicated to the single AXFR Informally:
session is incorrect, this has led to implementation choices that
prevent either multiple concurrent zone transfers or the use of the
open connection for other queries.
Being able to have multiple concurrent zone transfers is considered o The DS RRSet only occurs at the parental side of a zone cut and is
desirable by operators who have sets of name servers that are authoritative data in the parent zone, not the secure child zone.
authoritative for a common set of zones. It would be desirable
if the name server implementations did not have to wait for one
zone to transfer before the next could begin. The desire here is to
tighten the specification, not a change, but adding words to the
unclear areas, to define what is needed to permit two servers to
share a TCP connection among concurrent AXFR sessions. The challenge
is to design this in a way that can fall back to the old behavior if
either the AXFR client or AXFR server is incapable of performing
multiple concurrent AXFR sessions.
With the addition of EDNS0 and applications which require many o The DNSKEY RRSet only occurs at the APEX of a signed zone and is
small zones such as in web hosting and some ENUM scenarios, AXFR part of the authoritative data of the zone it serves.
sessions on UDP would now be possible and seem desirable. However,
there are still some aspects of the AXFR session that are not easily
translated to UDP. This document leaves AXFR over UDP undefined.
4.1 TCP 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
in the respective zone; simple queries for RRSIG resource records
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
describes how to distinguish these RRs); this seeming ambiguity
does not occur for AXFR, since each such RRSIG RRset belongs to a
single zone.
In the original definition there is an implicit assumption (probably o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
unintentional) that a TCP connection is used for one and only one equally may occur at the parental side of a zone cut and at the
AXFR session. This is evidenced in no requirement to copy neither apex of a zone; each such resource record belongs to exactly one
the Query Section nor the message ID in responses, no explicit of these zones and is to be included in the AXFR of that zone.
ordering information within the AXFR response messages and the lack
of an explicit notice indicating that a zone transfer continues in the
next message.
The guidance given here is intended to enable better performance of One issue is that in operations there are times when the NS resource
the AXFR exchange as well as guidelines on interactions with older records for a zone might be different at a cut point in the parent
software. Better performance includes being able to multiplex DNS and at the apex of a zone. Sometimes this is the result of an error
message exchanges including zone transfer sessions. Guidelines for and sometimes it is part of an ongoing change in name servers. The
interacting with older software are generally applicable to new AXFR DNS protocol is robust enough to overcome inconsistencies up to (but
clients. In the reverse situation, older AXFR client and newer AXFR not including) there being no parent indicated NS resource record
server ought to induce the server to operate within the specification referencing a server that is able to serve the child zone. This
for an older server. 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
to make it apparent (if it is unplanned) and to make it clear once
the inconsistency has been removed.
4.1.1 AXFR client TCP 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
AXFR server be authoritative for both halves of an inconsistent cut
point and that the AXFR client is authoritative for just the parent
side of the cut point.
An AXFR client MAY request a connection to an AXFR server for any When facing a situation in which a cut point's NS resource records do
reason. An AXFR client SHOULD close the connection when there is not match the authoritative set, the question arises whether an AXFR
no apparent need to use the connection for some time period. The server responds with the NS resource record set that is in the zone
AXFR server ought not have to maintain idle connections, the burden being transferred or the one that is at the authoritative location.
of connection closure ought to be on the client. Apparent need for
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 sessions will be coming or if there is other query/response
traffic anticipated or currently on the open connection, then there
is "apparent need."
An AXFR client MAY cancel delivery of a zone only by closing the The AXFR response MUST contain the cut point NS resource record set
connection. However, this action will also cancel all other outstanding registered with the zone whether it agrees with the authoritative set
activity using the connection. There is no other mechanism by which or not. "Registered with" can be widely interpreted to include data
an AXFR response can be cancelled. 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
the zone (database), statically or dynamically.
When a TCP connection is closed remotely (relative to the client), The reasons for this requirement are:
whether by the AXFR server or due to a network event, the AXFR client
MUST cancel all outstanding sessions and non-AXFR transactions.
Recovery from this situation is not straightforward. If the disruption
was a spurious event, attempting to restart the connection would be
proper. If the disruption was caused by a medium or long term
disruption, the AXFR client would be wise to not spend too many
resources trying to rebuild the connection. Finally, if the connection
was dropped because of a policy at the AXFR server (as can be the case
with older AXFR servers), the AXFR client would be wise to not retry
the connection. Unfortunately, knowing which of the three cases above
(momentary disruption, failure, policy) applies is not possible with
certainty, and can only be assessed by heuristics.
An AXFR client MAY use an already opened TCP connection to start an 1) The AXFR server might not be able to determine that there is an
AXFR session. Using an existing open connection is RECOMMENDED over inconsistency given local data, hence requiring consistency would
opening a new connection. (Non-AXFR session traffic can also use an mean a lot more needed work and even network retrieval of data. An
open connection.) If in doing so the AXFR client realizes that authoritative server ought not be required to perform any queries.
the responses cannot be properly differentiated (lack of matching
query IDs for example) or the connection is terminated for a remote
reason, then the AXFR client SHOULD NOT attempt to reuse an open
connection with the specific AXFR server until the AXFR server is
updated (which is of course, not an event captured in the DNS
protocol).
4.1.2 AXFR server TCP 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 not authoritative for both, the error is exposed. For
example, an authorized administrator can manually request the AXFR
and inspect the results to see the inconsistent records. (A server
authoritative for both halves would otherwise always answer from the
more authoritative set, concealing the error.)
An AXFR server MUST be able to handle multiple AXFR sessions on a 3) The inconsistent NS resource record set might indicate a problem
single TCP connection, as well as handle other query/response in a registration database.
transactions.
If a TCP connection is closed remotely, the AXFR server MUST cancel 4) This requirement is necessary to ensure that retrieving a given
all AXFR sessions in place. No retry activity is necessary; that is (zone,serial) pair by AXFR yields the exact same set of resource
initiated by the AXFR client. records no matter which of the zone's authoritative servers is chosen
as the source of the transfer.
Local policy MAY dictate that a TCP connection is to be closed. Such If an AXFR server were allowed to respond with the authoritative NS
an action SHOULD be in reaction to limits such as those placed on RRset of a child zone instead of a glue NS RRset in the zone being
the number of outstanding open connections. Closing a connection in transferred, the set of records returned could vary depending on
response to a suspected security event SHOULD be done only in extreme whether or not the server happens to be authoritative for the child
cases, when the server is certain the action is warranted. An zone as well.
isolated request for a zone not on the AXFR server SHOULD receive
a response with the appropriate return code and not see the connection
broken.
4.2 UDP The property that a given (zone,serial) pair corresponds to a single,
well-defined set of records is necessary for the correct operation of
incremental transfer protocols such as IXFR [RFC1995]. For example,
a client may retrieve a zone by AXFR from one server, and then apply
an incremental change obtained by IXFR from a different server. If
the two servers have different ideas of the zone contents, the client
can end up attempting to incrementally add records that already exist
or to delete records that do not exist.
AXFR sessions over UDP transport are not defined. 3.3. Glue Records
5 Authorization 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
an AXFR transfer. And, as also argued in the previous section of
this document, even when there is an inconsistency between the
address in a glue record and the authoritative copy of the name
server's address, the glue resource record that is registered as part
of the zone for that serial number is to be included.
A zone administrator has the option to restrict AXFR access to a zone. This applies to glue records for any address family [IANA-AF].
This was not envisioned in the original design of the DNS but has
emerged as a requirement as the DNS has evolved. Restrictions on AXFR
could be for various reasons including a desire (or in some instances,
having a legal requirement) to keep the bulk version of the zone
concealed or to prevent the servers from handling the load incurred in
serving AXFR. All reasons are arguable, but the fact remains that
there is a requirement to provide mechanisms to restrict AXFR.
A DNS implementation SHOULD provide means to restrict AXFR sessions to The AXFR response MUST contain the appropriate glue records as
specific clients. registered with the zone. The interpretation of "registered with" in
the previous section applies here. Inconsistent glue records are an
operational matter.
An implementation SHOULD allow access to be granted to Internet 3.4. Name Compression
Protocol addresses and ranges, regardless of whether a source address
could be spoofed. Combining this with techniques such as Virtual
Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
effective.
A general purpose implementation is RECOMMENDED to implement access Compression of names in DNS messages is described in RFC 1035,
controls based upon "Secret Key Transaction Authentication for DNS" Section 4.1.4, "Message compression". The issue highlighted here
[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" relates to a comment made in RFC 1034, Section 3.1, "Name space
[RFC2931]. specifications and terminology" which says "When you receive a domain
name or label, you should preserve its case." ("Should" in the quote
predates [BCP14].)
A general purpose implementation SHOULD allow access to be open to Name compression in an AXFR message MUST preserve the case of the
all AXFR requests. I.e., an operator ought to be able to allow any original domain name. That is, although when comparing a domain
AXFR query to be granted. name, "a" equals "A", when comparing for the purposes of message
compression, "a" is not equal to "A". Note that this is not the
usual definition of name comparison in the DNS protocol and
represents a new requirement on AXFR servers.
A general purpose implementation SHOULD NOT have a default policy Rules governing name compression of RDATA in an AXFR message MUST
for AXFR requests to be "open to all." For example, a default could abide by the specification in "Handling of Unknown DNS Resource
be to restrict transfers to addresses selected by the DNS Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
administrator(s) for zones on the server. Compression".
6 Zone Integrity 3.5. Occluded Names
An AXFR client MUST ensure that only a successfully transferred Dynamic Update [RFC2136] operations, and in particular its
copy of the zone data can be used to serve this zone. Previous interaction with DNAME [RFC2672], can have a side effect of occluding
description and implementation practice have introduced a two-stage names in a zone. The addition of a delegation point via dynamic
model of the whole zone synchronization procedure: Upon a trigger update will render all subordinate domain names to be in a limbo,
event (e.g., polling of SOA resource record detects change in the still part of the zone but not available to the lookup process. The
SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session addition of a DNAME resource record has the same impact. The
is initiated, whereby the zone data are saved in a zone file or subordinate names are said to be "occluded".
data base (this latter step is necessary anyway to ensure proper
restart of the server); upon successful completion of the AXFR
operation and some sanity checks, this data set is 'loaded' and
made available for serving the zone in an atomic operation, and
flagged 'valid' for use during the next restart of the DNS server;
if any error is detected, this data set MUST be deleted, and the
AXFR client MUST continue to serve the previous version of the zone,
if it did before. The externally visible behavior of an AXFR client
implementation MUST be equivalent to that of this two-stage model.
If a server rejects data contained in an AXFR session, the server Occluded names MUST be included in AXFR responses. An AXFR client
SHOULD remember the serial number and MAY attempt to retrieve the MUST be able to identify and handle occluded names. The rationale
same zone version again. The reason the same retrieval could make for this action is based on a speedy recovery if the dynamic update
sense is that the reason for the rejection could be rooted in an operation was in error and is to be undone.
implementation detail of one AXFR server used for the zone and not
in another AXFR server used for the zone.
Ensuring that an AXFR client does not accept a forged copy of a zone is 4. Transport
important to the security of a zone. If a zone operator has the
opportunity, protection can be afforded via dedicated links, physical
or virtual via a VPN among the authoritative servers. But there are
instances in which zone operators have no choice but to run AXFR
sessions over the global public Internet.
Besides best attempts at securing TCP connections, DNS implementations AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
SHOULD provide means to make use of "Secret Key Transaction 1034 that states: "Because accuracy is essential, TCP or some other
Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction reliable protocol must be used for AXFR requests." The restriction
Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the to TCP is also mentioned in Section 6.1.3.2. of "Requirements for
contents. These techniques MAY also be used for authorization. Internet Hosts - Application and Support" [RFC1123].
7 Backwards Compatibility 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
response, and then close the connection. But variations of that
most simple scenario are legitimate and likely, in particular sending
a query for the zone's SOA resource record first over the same TCP
connection, and reusing an existing TCP connection for other queries.
Describing backwards compatibility is difficult because of the lack of Therefore, the assumption that a TCP connection is dedicated to a
specifics in the original definition. In this section some hints at single AXFR session is incorrect. This wrong assumption has led to
building in backwards compatibility are given, mostly repeated from the implementation choices that prevent either multiple concurrent zone
earlier sections. transfers or the use of an open connection for other queries.
Backwards compatibility is not necessary, but the greater the extent of Since the early days of the DNS, operators who have sets of name
an implementation's compatibility the greater it's interoperability. servers that are authoritative for a common set of zones found it
For turnkey implementations this is not usually a concern. For general desirable to be able to have multiple concurrent zone transfers in
purpose implementations this takes on varying levels of importance progress; this way a name server does not have to wait for one zone
depending on the implementer's desire to maintain interoperability. transfer to complete before the next could begin. RFC 1035 did not
exclude this possibility, but legacy implementations missed to
support this functionality. The remaining presence of such legacy
implementations makes it necessary that new general purpose server
implementation still provide options for gracefull fallback to the
old behavior in their support of concurrent DNS transactions and AXFR
sessions on a single TCP connection.
It is unfortunate that a need to fall back to older behavior cannot be 4.1. TCP
discovered, hence needs to be noted in a configuration file. An
implementation SHOULD, in it's documentation, encourage operators to
periodically review AXFR clients and servers it has made notes about as
old software periodically gets updated.
7.1 Server In the original definition there arguably is an implicit assumption
(probably unintentional) that a TCP connection is used for one and
only one AXFR session. This is evidenced in the lack of an explicit
requirement to copy the Query section and/or the message ID into
responses, no explicit ordering information within the AXFR response
messages, and the lack of an explicit notice indicating that a zone
transfer continues in the next message.
An AXFR server has the luxury of being able to react to an AXFR The guidance given below is intended to enable better performance of
client's abilities with the exception of knowing if the client can the AXFR exchange as well as provide guidelines on interactions with
accept multiple resource records per AXFR response message. The older software. Better performance includes being able to multiplex
knowledge that a client is so restricted apparently cannot be DNS message exchanges including zone transfer sessions. Guidelines
discovered, hence it has to be set by configuration. for interacting with older software are generally applicable to new
AXFR clients. In the reverse situation, older AXFR client and newer
AXFR server, the server ought to operate within the specification for
an older server.
An implementation of an AXFR server MAY permit configuring, on a per 4.1.1. AXFR client TCP
AXFR client basis, a need to revert to single resource record per
message; in that case, the default SHOULD be to use multiple records
7.2 Client 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
apparent need to use the connection for some time period. The AXFR
server ought not have to maintain idle connections, the burden of
connection closure ought to be on the client. "Apparent need" for
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
sessions will be coming, or if there is other query/response traffic
anticipated or currently on the open connection, then there is
"apparent need".
An AXFR client has the opportunity to try other features (i.e., those An AXFR client can cancel the delivery of a zone only by closing the
not defined by this document) when querying an AXFR server. connection. However, this action will also cancel all other
outstanding activity using the connection. There is no other
mechanism by which an AXFR response can be cancelled.
Attempting to issue multiple DNS queries over a TCP transport for an When a TCP connection is closed remotely (relative to the client),
AXFR session SHOULD be aborted if it interrupts the original request, whether by the AXFR server or due to a network event, the AXFR client
and SHOULD take into consideration whether the AXFR server intends to MUST cancel all outstanding sessions and non-AXFR transactions.
close the connection immediately upon completion of the original Recovery from this situation is not straightforward. If the
(connection-causing) zone transfer. disruption was a spurious event, attempting to restart the connection
would be proper. If the disruption was caused by a failure that
proved to be persistent, the AXFR client would be wise to not spend
too many resources trying to rebuild the connection. Finally, if the
connection was dropped because of a policy at the AXFR server (as can
be the case with older AXFR servers), the AXFR client would be wise
to not retry the connection. Unfortunately, knowing which of the
three cases above (momentary disruption, failure, policy) applies is
not possible with certainty, and can only be assessed by heuristics.
8 Security Considerations An AXFR client MAY use an already opened TCP connection to start an
AXFR session. Using an existing open connection is RECOMMENDED over
opening a new connection. (Non-AXFR session traffic can also use an
open connection.) If in doing so the AXFR client realizes that the
responses cannot be properly differentiated (lack of matching query
IDs for example) or the connection is terminated for a remote reason,
then the AXFR client SHOULD NOT attempt to reuse an open connection
with the specific AXFR server until the AXFR server is updated (which
is, of course, not an event captured in the DNS protocol).
Concerns regarding authorization, traffic flooding, and message 4.1.2. AXFR server TCP
integrity are mentioned in "Authorization" (section 5), "TCP" (section
4.2) and "Zone Integrity" (section 6).
9 IANA Considerations An AXFR server MUST be able to handle multiple AXFR sessions on a
single TCP connection, as well as handle other query/response
transactions over it.
No new registries or new registrations are included in this document. If a TCP connection is closed remotely, the AXFR server MUST cancel
all AXFR sessions in place. No retry activity is necessary; that is
initiated by the AXFR client.
10 Internationalization Considerations 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
number of outstanding open connections. Closing a connection in
response to a suspected security event SHOULD be done only in extreme
cases, when the server is certain the action is warranted. An
isolated request for a zone not on the AXFR server SHOULD receive a
response with the appropriate return code and not see the connection
broken.
The AXFR protocol is transparent to the parts of DNS zone content that 4.2. UDP
can possibly be subject to Internationalization considerations.
It is assumed that for DNS labels and domain names, the issue has been
solved via "Internationalizing Domain Names in Applications (IDNA)"
[RFC3490].
11 Acknowledgements With the addition of EDNS0 and applications which require many small
zones such as in web hosting and some ENUM scenarios, AXFR sessions
on UDP would now seem desirable. However, there are still some
aspects of AXFR sessions that are not easily translated to UDP.
Earlier editions of this document have been edited by Andreas Therefore, this document does not update RFC 1035 in this respect:
Gustafsson. In his latest version, this acknowledgement appeared. AXFR sessions over UDP transport are not defined.
"Many people have contributed input and commentary to earlier versions 5. Authorization
of this document, including but not limited to Bob Halley, Dan
Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme,
and Brian Wellington."
Comments since the -05 version have come from these individuals: A zone administrator has the option to restrict AXFR access to a
Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain zone. This was not envisioned in the original design of the DNS but
Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, has emerged as a requirement as the DNS has evolved. Restrictions on
and other participants of the DNSEXT working group. AXFR could be for various reasons including a desire (or in some
instances, having a legal requirement) to keep the bulk version of
the zone concealed or to prevent the servers from handling the load
incurred in serving AXFR. It has been argued that these reasons are
questionable, but this document, driven by the desire to leverage the
interoperable practice that has evolved since RFC 1035, acknowledges
the factual requirement to provide mechanisms to restrict AXFR.
12 References A DNS implementation SHOULD provide means to restrict AXFR sessions
to specific clients.
All references prefixed by "RFC" can be obtained from the RFC Editor An implementation SHOULD allow access to be granted to Internet
web site at the URLs: http://rfc-editor.org/rfc.html Protocol addresses and ranges, regardless of whether a source address
or http://rfc-editor.org/rfcsearch.html ; could be spoofed. Combining this with techniques such as Virtual
information regarding this organization can be found at the following Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
URL: http://rfc-editor.org/ effective.
12.1 Normative A general purpose implementation is RECOMMENDED to implement access
controls based upon "Secret Key Transaction Authentication for DNS"
[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
[RFC2931].
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, A general purpose implementation SHOULD allow access to be open to
September 1981. all AXFR requests. I.e., an operator ought to be able to allow any
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August AXFR query to be granted.
1980.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC
2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations",
BCP 42, RFC 5395, November 2008.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Existence",
RFC 5155, March 2008
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
RFC 4635, August 2006.
[DNSFLGS] http://www.iana.org/assignments/dns-header-flags
[DNSVALS] http://www.iana.org/assignments/dns-parameters
12.2 Informative A general purpose implementation SHOULD NOT have a default policy for
AXFR requests to be "open to all". For example, a default could be
to restrict transfers to addresses selected by the DNS
administrator(s) for zones on the server.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate 6. Zone Integrity
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private Networks",
RFC 2764, February 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", RFC
3490, March 2003.
[DRAFT1] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY and
RRSIG Resource Records for DNSSEC",
draft-ietf-dnsext-dnssec-rsasha256-12, work in progress.
[DRAFT2] Weiler, S., and D. Blacka, "Clarifications and Implementation
Notes for DNSSECbis",
draft-ietf-dnsext-dnssec-bis-updates-08, work in progress.
13 Editor's Address An AXFR client MUST ensure that only a successfully transferred copy
of the zone data can be used to serve this zone. Previous
description and implementation practice have introduced a two-stage
model of the whole zone synchronization procedure: Upon a trigger
event (e.g., polling of a SOA resource record detects change in the
SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is
initiated, whereby the zone data are saved in a zone file or data
base (this latter step is necessary anyway to ensure proper restart
of the server); upon successful completion of the AXFR operation and
some sanity checks, this data set is 'loaded' and made available for
serving the zone in an atomic operation, and flagged 'valid' for use
during the next restart of the DNS server; if any error is detected,
this data set MUST be deleted, and the AXFR client MUST continue to
serve the previous version of the zone, if it did before. The
externally visible behavior of an AXFR client implementation MUST be
equivalent to that of this two-stage model.
Edward Lewis If an AXFR client rejects data contained in an AXFR session, it
46000 Center Oak Plaza SHOULD remember the serial number and MAY attempt to retrieve the
Sterling, VA, 22033, US same zone version again. The reason the same retrieval could make
+1-571-434-5468 sense is that the reason for the rejection could be rooted in an
ed.lewis@neustar.biz implementation detail of one AXFR server used for the zone and not
present in another AXFR server used for the 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
opportunity, protection can be afforded via dedicated links, physical
or virtual via a VPN among the authoritative servers. But there are
instances in which zone operators have no choice but to run AXFR
sessions over the global public Internet.
Besides best attempts at securing TCP connections, DNS
implementations SHOULD provide means to make use of "Secret Key
Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and
Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients
to verify the contents. These techniques MAY also be used for
authorization.
7. Backwards Compatibility
Describing backwards compatibility is difficult because of the lack
of specifics in the original definition. In this section some hints
at building in backwards compatibility are given, mostly repeated
from the relevant earlier sections.
Backwards compatibility is not necessary, but the greater the extent
of an implementation's compatibility the greater its
interoperability. For turnkey implementations this is not usually a
concern. For general purpose implementations this takes on varying
levels of importance depending on the implementer's desire to
maintain interoperability.
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
implementation SHOULD, in its documentation, encourage operators to
periodically review AXFR clients and servers it has made notes about
repeatedly, as old software gets updated from time to time.
7.1. Server
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
can accept multiple resource records per AXFR response message. The
knowledge that a client is so restricted cannot be discovered, hence
it has to be set by configuration.
An implementation of an AXFR server MAY permit configuring, on a per
AXFR client basis, the necessity to revert to single resource record
per message; in that case, the default SHOULD be to use multiple
records per message.
7.2. Client
An AXFR client has the opportunity to try other features (i.e., those
not defined by this document) when querying an AXFR server.
Attempting to issue multiple DNS queries over a TCP transport for an
AXFR session SHOULD be aborted if it interrupts the original request,
and SHOULD take into consideration whether the AXFR server intends to
close the connection immediately upon completion of the original
(connection-causing) zone transfer.
8. Security Considerations
Concerns regarding authorization, traffic flooding, and message
integrity are mentioned in "Authorization" (Section 5), "TCP"
(Section 4.2) and "Zone Integrity" (Section 6).
9. IANA Considerations
[[ Note to RFC-Ed: this section may be deleted before publication. ]]
No new registries or new registrations are included in this document.
10. Internationalization Considerations
The AXFR protocol is transparent to the parts of DNS zone content
that can possibly be subject to Internationalization considerations.
It is assumed that for DNS labels and domain names, the issue has
been solved via "Internationalizing Domain Names in Applications
(IDNA)" [RFC3490] or its successor(s).
11. Acknowledgments
Earlier editions of this document have been edited by Andreas
Gustafsson. In his latest version, this acknowledgment appeared:
"Many people have contributed input and commentary to earlier
versions of this document, including but not limited to Bob Halley,
Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert
Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
Trenholme, and Brian Wellington."
Comments since the -05 version have come from these individuals:
Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
Ian Jackson, Andreas Gustafsson, Brian Wellington, and other
participants of the DNSEXT working group.
Edward Lewis served as a patiently listening sole document editor for
two years.
12. References
All "RFC" references by can be obtained from the RFC Editor web site
at the URLs: http://rfc-editor.org/rfc.html
or http://rfc-editor.org/rfcsearch.html ;
information regarding this organization can be found at the following
URL: http://rfc-editor.org/
12.1. Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
November 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
RFC 4635, August 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008
[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 5395, November 2008.
[RFC5702] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
12.2. Informative References
[DNSVALS] IANA Registry "Domain Name System (DNS) Parameters",
http://www.iana.org/assignments/dns-parameters
[IANA-AF] IANA Registry "Address Family Numbers",
http://www.iana.org/assignments/Address-family-numbers/ .
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
Implementation Notes for DNSSECbis",
draft-ietf-dnsext-dnssec-bis-updates-09 (work in
progress), September 2009.
13. Editors' Addresses
Edward Lewis
46000 Center Oak Plaza
Sterling, VA, 22033, US
Email: ed.lewis@neustar.biz
Alfred Hoenes
TR-Sys
Gerlinger Str. 12
Ditzingen D-71254
Germany
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. 190 change blocks. 
855 lines changed or deleted 793 lines changed or added

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