INTERNET-DRAFT                                            Edward Lewis
draft-ietf-dnsext-axfr-clarify-08.txt                    NeuStar, Inc.
DNSEXT WG                                                February 2008

Updates: 1034, 1035 (if approved)     Intended status: Standards Track

                      DNS Zone Transfer Protocol (AXFR)
Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on September December 1, 2008.

Copyright Notice

Copyright (C) The IETF Trust (2008).


The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements.  The Authoritative
Transfer (AXFR) is defined in RFC 1034 and RFC 1035.  The Incremental
Zone Transfer (IXFR) is defined in RFC 1995.  A mechanism for prompt
notification of zone changes (NOTIFY) is defined in RFC 1996.  The base
definition of these facilities, that of the AXFR, has proven
insufficient in detail, resulting in no implementation complying with
it. Yet today we have a satisfactory set of implementations that do
interoperate. This document is a new definition of the AXFR, new in the
sense that is it recording an accurate definition of an interoperable
AXFR mechanism.

1 Introduction

The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements.  Authoritative
Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities"
[RFC1034] (referred to in this document as RFC 1034) and "Domain Names
- Implementation and Specification" [RFC1035] (aka  RFC 1035).
Incremental Zone Transfer (IXFR) is defined in "Incremental Zone
Transfer in DNS" [RFC1995].  A mechanism for prompt notification of
zone changes (NOTIFY) is defined in "A Mechanism for Prompt
Notification of Zone Changes (DNS NOTIFY)" [RFC1996].  The goal of
these mechanisms is to enable a set of DNS name servers to remain
coherently authoritative for a given zone.

Comments on this draft ought to be addressed to the editor or to

1.1 Definition of Terms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [BCP14].


"Newer"/"New" DNS and "older"/"old" DNS refers to implementations
written after and prior to the publication of this document.

1.2 Scope

In the greater context, context there are many ways to achieve coherency among
a set of name servers.  These  The AXFR, IXFR and NOTIFY mechanisms form
just one, the one defined in the RFCs cited.  For example, there are
DNS implementations that assemble answers from data stored in commercial
relational databases (as opposed to open
source, etc.) database instances, and rely master files) relying on the
proprietary or otherwise external-to-DNS non-DNS means to synchronize the database instances.  Some
of these non-DNS solutions might even interoperate in some fashion.  As far as
it is known, AXFR, IXFR, IXFR and NOTIFY are the only 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
applications of the DNS in which servers for a zone are designed to be
incoherent.  For these configurations, a coherency mechanism as
described here would be unsuitable.

"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

"Turnkey DNS implementation" refers to custom made, single use
implementations of DNS.  Such implementations consist of software
that employes the DNS protocol message format yet do not conform to
the entire range of DNS functionality.

A DNS implementation is not required to support AXFR, IXFR, IXFR and NOTIFY.
A DNS implementation SHOULD have some means for maintaining name server
coherency.  A general purpose DNS implementation SHOULD include AXFR,
IXFR and NOTIFY, but turnkey DNS implementations MAY operate without

1.3 Context

Besides describing the mechanisms themselves, there is the context in
which they operate to consider.  When AXFR, IXFR, 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

This document concentrates on just the definition of AXFR.  Any effort
to update the IXFR or NOTIFY mechanisms would be done in different
documents.  This is not strictly a clarification of the definition in
RFC 1034 and RFC 1035.  This document will update those sections, and
invalidate at least one part of that definition.  The goal of this
document is to define AXFR as it exists, or is supposed to exist,

2 AXFR Messages

An AXFR message exchange (or session) consists of an AXFR query message
and a set of AXFR response messages.  In this document, 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 the AXFR exchange.)  The reason for the imbalance
in number of messages derives from large zones whose contents cannot be
fit into the limited permissible size of a DNS message.

An important aspect to keep in mind is that the definition of AXFR is
restricted to TCP [RFC0793].  The design of the AXFR process has
certain inherit features that are not easily ported to UDP [RFC0768].
Nonetheless, AXFR over UDP has some potential use cases.  AXFR over UDP
is not defined here and might some day appear in an extension document.

The basic format of an AXFR message is the DNS message as defined in
RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following:
- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996]
- "Domain Name System (DNS) IANA Considerations" [RFC2929]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- "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]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]

The upper limit on the permissible size of a DNS message over TCP is
defined in RFC 1035, section 2.3.4, and supplemented in RFC 2671, section 4.5.
The limit on the permissible size of a 4.2.2.  Unlike DNS message will be referenced
a few times in messages over UDP,
this document. limit is not changed by EDNS0.

Field names used in this document will correspond to the names as they
appear in the IANA registry for DNS Header Flags [DNSFLGS].

2.1 AXFR query

An AXFR query is sent by a client whenever there is a reason to ask.
This might be because of zone maintenance activities or as a result of
a command line request, say for debugging.

2.1.1 Header Values

These are the DNS message header values for an AXFR query.

ID          See note 2.1.1.a
QR          MUST be 0 (Query)
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)
ARCOUNT     See note 2.1.1.d

Note 2.1.1.a Set to any value that the client desires.  There
is no specific means for selecting the value in this field.  However,
consideration can be given to making it harder for forged messages to be
accepted by referencing the work in progress "Measures for making DNS
more resilient against forged answers" [FORGERY].
(Recall that AXFR is done only via TCP connections.)

Note 2.1.1.b The value in this field has no meaning in the context of
AXFR query messages.  For the client, it is RECOMMENDED that the
value be zero.  For the server, it is RECOMMENDED ignoring  The server MUST ignore this value.

Note 2.1.1.c The client MUST set to 0, the server MUST ignore.

Note 2.1.1.d The value MAY be 0, 1 or 2.  If it is 2, the additional
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.

A note on "future proofing" this document.  It is possible that in the
future more records might be introduced that share the property of
being placed in the additional section.  Such records might be other
options to, say, TSIG and SIG(0) for message authentication or may
be completely unrelated to that service.  In any case, each new record
that might appear in the additional section might expand the range of
values that this field can take on.  As predicting the future is still
an unproven field, further details are not available.  Check back
later for updates.

2.1.2 Query Section

The Query section of the AXFR query MUST conform to section 4.1.2 of
RFC 1035, and contain the following values:

QNAME       the name of the zone requested
QTYPE       AXFR [DNSVALS], see       AXFR(= 252), the registry pseudo-RR type for the numeric value zone transfer [DNSVALS]
QCLASS      the class of the zone requested

2.1.3 Answer Section

MUST be empty.

2.1.4 Authority Section

MUST be empty.

2.1.5 Additional Section

The client MAY include an EDNS0 OPT resource record.  If the server
has indicated that it does not support EDNS0, the client MUST send
this section without an EDNS0 OPT resource record if there is a retry.
Indication that a server does not support EDNS0 is not an 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
resource record, currently a choice of TSIG or SIG(0).  If the server
has indicated that it does not recognize the resource record, and
that the client
MUST send this section without such a resource record if there error is a

If indeed caused by the client is aware that the server does not support EDNS0, it is
RECOMMENDED that this section be sent without the OPT resource record.
If resource record, the client is aware that the server will
probably ought not participate try again.  Removing the security data in TSIG or
SIG(0), it is RECOMMENDED that the client not try
face of an obstacle ought to send such a record. 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
support a particular mechanism, the client SHOULD NOT attempt to engage
the server using the mechanism. mechanism (or at all).  A client MAY become aware
of a server's abilities via a configuration setting.

2.2 AXFR response

The AXFR response will consist of 0 or more messages.

A 0 message response is very exceptional.  It is unhealthy for there
to be 0 responses in a protocol that is designed around a query -
response paradigm.  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.  Therefore any earnest query has the expectation
of some response.

An AXFR response that is transferring the zone's contents will consist
of a series of DNS messages bounded in size by the limited permissible
size.  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 message 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.

Editorial note "MAY" or SHOULD/are RECOMMENDED TO

An AXFR response that is indicating an error MUST consist of a single
DNS message with the return code set to the appropriate value for the
condition encountered. encountered - once the error condition is detected.  Such
a message MUST copy the AXFR query Query Section into its Query

An AXFR client might receive a number of AXFR response messages
free of an error condition before the message indicating the error
is received.  But once an error is reported, the AXFR client can
assume this the reporting message is the last.

An AXFR client MUST be able to react to no AXFR response Messages messages from
the server. An AXFR server MAY elect to silently discard the AXFR
query but this is only RECOMMENDED if the server has reasons to deduce
that the query was sent maliciously.

An AXFR server MAY elect to close the underlying TCP connection in
response to an AXFR query.  Because this action could impact other
DNS queries and responses, it is RECOMMENDED that this tactic only be
employed when there are strong indications of malicious activity.
Still, an AXFR client MUST be able to adequately react to this

2.2.1 Header Values

ID          See note 2.2.1.a
QR          MUST be 1 (Response)
OPCODE      MUST be 0 (Standard Query)
AA          See note 2.2.1.b
TC          MUST be 0 (Not truncated)
RD          RECOMMENDED copy request's value, MAY be set to 0
RA          See note 2.2.1.c
Z           See note 2.2.1.d
AD          See note 2.2.1.e
CD          See note 2.2.1.e
RCODE       See note 2.2.1.f
QDCOUNT     MUST be 1 in the first message; MUST be 0 or 1 in all
ANCOUNT     See note 2.2.1.g
ARCOUNT     See note 2.2.1.h

Note 2.2.1.a Because of old implementations, the requirement
on this section 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.  New AXFR clients MUST be able to accept sessions in
which the responses do not have the same ID field.

If a client detects or is aware that the server is new, that is, all of
the responses have the same ID value as the query, the client MAY issue
other DNS queries (of any type) to the server using the same transport.
Unless the client is sure that the server will consistently set the ID
field to the query's ID, the client is NOT RECOMMENDED to 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.1.b If the RCODE is 0 (no error), then the AA bit MUST be 1.
For any other value of RCODE, the AA bit MUST be set according to rules
for that error code.  If in doubt, it is RECOMMENDED that is be set
to 1.  It is RECOMMENDED that the value be ignored by the AXFR client.

Note 2.2.1.c It is RECOMMENDED that the server set the value to 0,
it is RECOMMENDED that
the client MUST ignore this value.

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 from this value, but SHOULD NOT
conclude that the AXFR response was obtained recursively even if the RD
bit was 1 in the query.

Note 2.2.1.d The server MUST set to 0, and the client MUST ignore.

Note 2.2.1.e If the implementation supports the DNS Security Extensions
(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
- "DNS Security Introduction and Requirements" [RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]

Note 2.2.1.f In the absence of an error, the server MUST set the value
of this field to NoError.  If a server is not authoritative for the
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 response processing.  The
same is true for other error-indicating values.

Note 2.2.1.g The count of answer records MUST equal the number of
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.1.h The value MAY be 0, 1 or 2.  If it is 2, the additional
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.

A note on "future proofing" this document.  It is possible that in the
future more records might be introduced that share the property of
being placed in the additional section.  Such records might be other
options to, say, TSIG and SIG(0), for message authentication or may
be completely unrelated to that service.  In any case, each new record
that might appear in the additional section might expand the range of
values that this field can take on.  As predicting the future is still
an unproven field, further details are not available.  Check back
later for updates.

2.2.2 Query Section

In the first response message, this section MUST be copied from the
query.  In subsequent messages this section MAY be copied from the
query, 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.3 Answer Section

MUST be populated with the zone contents.  See later section on
encoding zone contents.

2.2.4 Authority Section

MUST be empty.

2.2.5 Additional Section

The contents of this section MUST follow the guidelines for EDNS0,
TSIG, SIG(0), or what ever other future record is possible here.  See
the appropriate specifications for instructions and restrictions.

3 Zone Contents

The objective of the AXFR session is to request and transfer the
contents of a zone.  The objective is to permit the 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 a
static set of records to a dynamically updated set of records to a
continually regenerated set of records.

3.1 Records to Include

In the answer section of AXFR response messages the resource records
within a zone for the given serial number MUST appear.  The definition
of what belongs in a zone is described in RFC 1034, Section 4.2, "How
the database is divided into zones", and in particular, section 4.2.1,
"Technical considerations".

The first resource record of the first AXFR response message sent by
the AXFR server MUST be the zone's SOA resource record.   The last
resource record of the final AXFR response message sent by the AXFR
server MUST be the zone's SOA resource record.  The order and grouping
of all other records in the AXFR is arbitrary, but the AXFR server
SHOULD group resource record sets together.

Unless the AXFR server knows that the AXFR client expects just one
resource record per AXFR response message, an AXFR server SHOULD
populate an AXFR response message with as many complete resource
records as will fit within the limited permissible message size.

Zones for which it is impractical to list the entire zones for a serial
number (because changes happen too quickly) are not suitable for AXFR

3.2 Delegation Records

In RFC 1034, section 4.2.1, this text appears (keep in mind that the use
of the word
"should" in the quotation is exempt from the interpretation
in predates [BCP14], cf. section 1.1) "The RRs
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
applicable glue records.  It does not mean that the cut points and the
apex resource records are identical.  For example, the SOA resource
record is only found at the apex, as well as a slew of DNSSEC resource
records.  There are also some DNSSEC resource record sets that are
explicitly different between the cut point and the apex.  The
discussion here is restricted to just the NS resource record set and
glue as these "describe cuts."

The issue is that in operations there are times when the NS resource
records for a zone might be different at a cut point in the parent and
at the apex of a zone.  Sometimes this is the result of an error and
sometimes it is part of an ongoing change in name servers.  The DNS
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 a 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
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
point's NS resource records do not match the authoritative set, whether
an AXFR server responds with the NS resource record set that is in the
zone or is at the authoritative location.

The AXFR response MUST contain the cut point NS resource record set
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:

1) The AXFR server might not be able to determine that there is an
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
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
in a registration database.

4) Beginning with an error state of two servers for a zone having
inconsistent zone contents for a given zone serial number, if a client
requests and recieves an IXFR transfer from one server followed by
another IXFR transfer from the other server, the client can encounter
an IXFR protocol error state where an attempt is made to incrementally
add a record that already exists or to delete a record that does not

(Editorial note, the 4th reason was suggested, but I don't see how
it relates.  A nudge for updated text on this.)

3.3 Glue Records

As quoted in the previous section, RFC 1034, section 4.2.1, 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.

This applies for glue records for any address family.

The AXFR response MUST contain the appropriate glue records as
registered with the zone.  The interpretation of "registered with"
in the previous section applies here.  Inconsistent glue records are
an operational matter.

3.4 Name Compression

Compression of names in DNS messages is described in RFC 1035, section
4.1.4, "Message compression".  The issue highlighted here relates to a
comment made in RFC 1034, section 3.1, "Name space specifications and
terminology" which says "When you receive a domain name or label, you
should preserve its case." ("Should" in the quote predates [BCP14].)

Name compression in an AXFR message MUST preserve the case of the
original domain name.  That is, although when comparing a domain name,
"a" equals "A", when comparing for the purposes of message comparison, compression,
"a" is not equal 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.

Rules governing name compression of RDATA in an AXFR message MUST
abide by the specification in "Handling of Unknown DNS Resource Record
(RR) Types" [RFC3597], specifically, section 4 on "Domain Name

3.5 Occluded Names

Dynamic Update [RFC2136] (and including DNAME [2672]) operations can
have a side effect of occluding names in a 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 for to
the look up process.  The addition of a DNAME resource record set has
the same impact.  The subordinate names are said to be "occluded."

Occluded names MUST be included in AXFR responses.  An AXFR client MUST
be able to identify and handle occluded names.  The rationale for this
action is based on a speedy recovery if the dynamic update operation
was in error and is to "A".

Name compression of RDATA in an AXFR message MAY only be done on
resource record types which explicitly permit such compression. undone.

4 Transport

AXFR sessions are currently restricted to TCP by RFC 1034, section 4.3.5's "because 4.3.5 of RFC
1034 that states: "Because accuracy is essential, TCP or some other
reliable protocol must be used for AXFR requests." 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.  There are variations on this, such as a query
for the zone's SOA resource record first, and so on.

Two issues have emerged since the original specification of AXFR.
One is that lack of specificity has yielded some implementations
that assume the TCP connection is dedicated to the single AXFR
session, which has led to implementation choices that prevent either
multiple concurrent zone transfers or the use of the open connection
for other queries.  The other issue is the prospect of using UDP as a
transport has come to look promising because of trends in the past
two decades.

Being able to have multiple concurrent zone transfers is considered
desirable by operators who have sets of name servers that are
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 fallback 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
small zones such as in web hosting and some ENUM scenarios, AXFR
sessions on UDP are now possible and 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,
with the issue to be discussed and possibly appear in a separate

4.1 TCP

In the original definition there is an implicit assumption (probably
unintentional) that a TCP connection is used for one and only one
AXFR session.  This is evidenced in no requirement to copy neither
the Query Section nor the message ID in 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.

The guidance given here is intended to enable better performance of
the AXFR exchange as well as guidelines on interactions with older
software.  Better performance includes being able to multiplex DNS
message exchanges including zone transfer sessions.  Guidelines for
interacting with older software are generally applicable to AXFR
clients as reversing the situation, older AXFR client and newer
AXFR server ought to induce the server to operate within the
specification for an older server.

4.1.1 AXFR client TCP

An AXFR client MAY request an connection to an AXFR server upon for any
reason.  An AXFR client SHOULD close the connection when there is
no apparent need to use the connection for some time period.  This
latter comment is made so that the The
AXFR server does ought not have to keep open maintain idle connections, and placing the planning for a burden of
connection closure ought to be on the client.  Apparent need for
the connection is a judgement for the AXFR client and the DNS client in general, if
client. If the connection is used for multiple sessions, or it is know
known sessions will be coming, coming or is there is other query/response
traffic on the open connection, that is "apparent need."

An AXFR client MAY cancel delivery of a zone only by closing the
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.

When a TCP connection is closed remotely (relative to the client),
whether by the AXFR server or due to a network event, the AXFR client
MUST cancel all outstanding sessions.  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 applies is not
clear (momentary disruption, failure, policy).

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 that 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

4.1.2  AXFR server TCP

An AXFR server MUST be able to handle multiple AXFR sessions on a
single TCP connection, as well as handle other query/response sessions.

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.

Local policy MAY dictate that a TCP connection is to be closed.  Such
as 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

4.2 UDP

AXFR sessions over UDP transport are not defined.

5 Authorization

A zone administrator has the option to restrict AXFR access to a zone.
This was not envisioned in the original design of the DNS but 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
specific clients.  By default, a DNS implementation SHOULD only allow
the designated authoritative servers to have access to the zone.

An implementation SHOULD allow access to be granted to Internet
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

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 )"

A general purpose implementation SHOULD allow access to be open to
all AXFR requests.  I.e., an operator ought to be able to allow any
AXFR query to be granted.

A general purpose implementation SHOULD NOT have a default policy
for AXFR requests to be "open to all."

6 Zone Integrity

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 sessions, 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 a the lack of
specifics in the original definition.  In this section some hints at
building in backwards compatibility are given, mostly repeated from the
earlier sections.

Backwards compatibility is not necessary, but the greater extent of an
implementation's compatibility increases it's interoperability.  For
turnkey implementations this is not usually a concern.  For general
purpose implementations this takes on varying levels of importance
depending on the implementers implementer's desire to maintain interoperability.

It is unfortunate that needs a need to fall back to older behavior cannot be
discovered, hence need 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

An AXFR server has the luxury of being able to react to an AXFR
client's abilities with the exception of knowing if the client can
accept multiple resource records per AXFR response message.  The
knowledge that a client is so restricted apparently cannot be
discovered, hence it has to be set by configuration.

An implementation of an AXFR server SHOULD permit configuring, on a per
AXFR client basis, a need to revert to single resource record per
message.  The default SHOULD be to use multiple records per message.

7.2 Client

An AXFR client has the opportunity to try extensions when querying
an AXFR server.

The use of EDNS0 to increase the DNS message size, offer authorizing
proof, or to invoke message integrity can be tried and rejected by the
AXFR server via the methods already described as part of the EDNS0

If an AXFR client attempts to use the UDP transport, non-response from
the AXFR server or other error message can indicate not to retry that.

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

No new registries or new registrations are included in this document.

10 Internationalization Considerations

It is assumed that supporting of international domain names has been
solved via "Internationalizing Domain Names in Applications (IDNA)"

11 Acknowledgements

Earlier editions of this document have been edited by Andreas
Gustafsson. In his latest version, this acknowledgement 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:
Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain
Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington,

12 References

All references prefixed by "RFC" can be obtained from the RFC Editor,
information regarding this organization can be found at the following
Additionally, these documents can be obtained via the IETF web site.

12.1 Normative

[RFC0793] Postel, J., "Transmission Control Protocol." J. Postel. Protocol", STD 7, RFC 793,
          September 1981.
[RFC0768] Postel, J., "User Datagram Protocol. " J. Postel. Protocol", STD 6, RFC 768, August
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities.", P.V. Mockapetris.
           Nov-01-1987. facilities",
          STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification." P.V.
           Mockapetris. Nov-01-1987.
          specification", STD 13, RFC 1035, November 1987.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS." M. Ohta. DNS", RFC 1995,
          August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
          Changes (DNS
           NOTIFY)." P. Vixie. 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)."
           P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. UPDATE)", RFC
          2136, April 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)." P. Vixie. (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)."
           P.  Vixie, O. Gudmundsson, D. Eastlake, B. Wellington.
          (TSIG)", RFC 2845, May 2000.
[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
          "Domain Name System (DNS) IANA Considerations." D. Eastlake
           3rd, E.  Brunner-Williams, B. Manning. Considerations", BCP 42, RFC
          2929, September 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)." D. Eastlake.
          RR)", RFC 2930, September 2000.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
          ( SIG(0)s)."
           D. Eastlake. SIG(0)s )", RFC 2931, September 2000.
[RFC3425] Lawrence, D., "Obsoleting IQUERY." D. Lawrence. 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."
           R. Requirements", RFC 4033,
          March 2005.
[RFC4034] Arends, R. R., Austein, M. R., Larson, D. M., Massey, D., and S. Rose. March
          Rose, "Resource Records for the DNS Security Extensions."
           R. Extensions",
          RFC 4034, March 2005.
[RFC4035] Arends, R. R., Austein, M. R., Larson, D. M., Massey, D., and S. Rose. March
          Rose, "Protocol Modifications for the DNS Security Extensions."
           R.  Arends, R. Austein, M. Larson, D. Massey, S. Rose.
          Extensions", RFC 4035, March 2005.
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
          Code, Secure Hash Algorithm) TSIG Algorithm Identifiers." D. Eastlake 3rd. Identifiers",
          RFC 4635, August 2006.

12.2 Informative

[BCP14]   Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels."
           S. Bradner. Levels", BCP 14, RFC 2119, March 1997.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
          Malis, "A Framework for IP Based Virtual Private Networks." B.
           Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. Networks",
          RFC 2764, February 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
          "Internationalizing Domain Names in Applications (IDNA)." P.
           Faltstrom, P. Hoffman, A. Costello. (IDNA)", RFC
          3490, March 2003.
[FORGERY] "Measures for making DNS more resilient against forged
           answers." A. Hubert, R. van Mook. Work in Progress.

13 Editor's Address

Edward Lewis
46000 Center Oak Plaza
Sterling, VA, 22033, US

Full Copyright Statement

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at


Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).