DNSext Working Group A. Hoenes
Internet-Draft TR-Sys
Obsoletes: 1995 (if approved) O. Sury
Intended status: Standards Track CZ.NIC
Expires: April 22, 2011 October 19, 2010
DNS Incremental Zone Transfer Protocol (IXFR)
draft-ah-dnsext-rfc1995bis-ixfr-00
Abstract
The standard means within the Domain Name System protocol for
maintaining coherence among a zone's authoritative name servers
consists of three mechanisms. Incremental Zone Transfer (IXFR) is
one of the mechanisms and originally was defined in RFC 1995.
This document aims to provide a more detailed and up-to-date
specification of the IXFR mechanism and to align it with the current
specification of the primary zone transfer mechanism, AXFR, given in
RFC 5936. Further, based on operational experience, this document
juxtaposes to the original IXFR query a new query type, IXFR-ONLY,
that will be preferred over IXFR in specific deployments.
This document obsoletes and replaces RFC 1995.
Discussion
This is a (still) incomplete, initial draft version. Readers are
encouraged to defer detailed comments until the next draft version,
which is expected to be available soon.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 22, 2011.
Hoenes & Sury Expires April 22, 2011 [Page 1]
Internet-Draft DNS Incremental Zone Transfer October 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Hoenes & Sury Expires April 22, 2011 [Page 2]
Internet-Draft DNS Incremental Zone Transfer October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Definition of Terms and Requirements Language . . . . . . 5
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Principles of IXFR Protocol Operation . . . . . . . . . . . . 6
3. IXFR Messages . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. IXFR Query . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Header Values . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Question Section . . . . . . . . . . . . . . . . . . . 11
3.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . 11
3.1.4. Authority Section . . . . . . . . . . . . . . . . . . 11
3.1.5. Additional Section . . . . . . . . . . . . . . . . . . 11
3.2. IXFR Response . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Header Values . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Question Section . . . . . . . . . . . . . . . . . . . 13
3.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . 13
3.2.4. Authority Section . . . . . . . . . . . . . . . . . . 14
3.2.5. Additional Section . . . . . . . . . . . . . . . . . . 14
3.3. Connection Aborts . . . . . . . . . . . . . . . . . . . . 14
4. Response Contents . . . . . . . . . . . . . . . . . . . . . . 14
5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Purging Strategy . . . . . . . . . . . . . . . . . . . . . 14
6.3. Optional Condensation of Zone Changes . . . . . . . . . . 14
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 14
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . 15
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Motivation for IXFR-ONLY . . . . . . . . . . . . . . 17
Hoenes & Sury Expires April 22, 2011 [Page 3]
Internet-Draft DNS Incremental Zone Transfer October 2010
1. Introduction
1.1. Overview
The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements. Authoritative Transfer
(AXFR) originally was defined in STD 13: "Domain Names - Concepts and
Facilities" [RFC1034] (referred to in this document as RFC 1034) and
"Domain Names - Implementation and Specification" [RFC1035]
(henceforth RFC 1035), and is now precisely specified in "DNS Zone
Transfer Protocol (AXFR)" [RFC5936] (henceforth RFC 5936).
Incremental Zone Transfer (IXFR) was originally 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.
For large domains that incur frequent changes that need to be
available quickly to prospective DNS clients, AXFR has proven less
suitable because it always transfers the whole zone content. The
latency incurred in the propagation of changes to the DNS database
([RFC1034], [RFC1035]) can be substantially reduced by actively
notifying secondary servers of the availability of a new version of
the authoritative zone data at the primary server for a zone; this is
accomplished by the DNS NOTIFY mechanism [RFC1996]. The time and
resources needed to accomplish the transfer of the new zone content
to the secondary servers in many cases can be reduced substantially
by only carrying forward the changes from a previous version of the
zone data. This is accomplished by the IXFR mechanism originally
specified in RFC 1996 [RFC1996] and, more precisely, below.
The original IXFR automatically falls back to AXFR behavior whenever
the IXFR server cannot fulfill the given delta-update request. In
some deployments, in particular where multiple IXFR servers are
available to the IXFR client, this can lead to premature fallback to
AXFR, which incurs the additional overhead that the client wants to
avoid whenever possible. This gap is closed by a variant of the IXFR
mechanism, dubbed "IXFR-ONLY", which originally has been proposed in
"IXFR-ONLY to Prevent IXFR Fallback to AXFR" [I-D.kerr-ixfr-only] and
which is fully specified below as well.
Thus, this document re-specifies the IXFR mechanism as it is deployed
in the Internet at large, giving more details than in the original
specification, and using RFC 5936 as its foundation. Additionally,
it newly specifies a versatile variant of IXFR, IXFR-ONLY.
This document is organized as follows: After presenting the
Hoenes & Sury Expires April 22, 2011 [Page 4]
Internet-Draft DNS Incremental Zone Transfer October 2010
terminology used and elaborations on the scope of this protocol and
its specification in the next subsections, Section 2 gives an
overview on the principles of operation of the IXFR protocol.
Section 3 normatively specifies the IXFR query and response message
format and the basic rules governing their generation and processing.
Subsequent sections detail mandatory and optional server behavior,
and supply management, security, and IANA considerations.
1.2. Definition of Terms and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" BCP 14 [RFC2119].
The terms "AXFR server", "AXFR client", "AXFRE session", "General-
purpose DNS implementation" and "Turnkey DNS implementation" are used
as defined in Section 1.1 of RFC 5936 [RFC5936]
The bare term "IXFR" is intended to refer to the generic case of an
IXFR or IXFR-ONLY query/response, unless it is clear from the context
that the original IXFR is dealt with specifically.
An "IXFR client" is a (secondary) name server for a given DNS zone
that, based on a trigger event, e.g. a DNS NOTIFY message, issues an
IXFR query to a "superordinate" authoritative server (e.g. the
primary server of the zone) and receives the IXFR response from it.
An "IXFR server" is an authoritative server that is presumed to
become aware of changes to a zone earlier than other authoritiative
servers, e.g. the primary server for a zone as specified in STD 13 or
a secondary server that already has synchronized with the primary
server, and which is configured to respond to IXFR queries.
The interaction and protocol exchange(s) performed by an IXFR client
and an IXFR server to issue an IXFR query and accomplish its
processing are collectively denoted as an "IXFR session".
1.3. Scope
In general terms, authoritative name servers for a given zone can use
various means to achieve coherency of the zone contents they serve.
For example, there are DNS implementations that assemble answers from
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
Hoenes & Sury Expires April 22, 2011 [Page 5]
Internet-Draft DNS Incremental Zone Transfer October 2010
servers, and they are the only mechanisms specified 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.
IXFR is an optional protocol component for authoritiative DNS
servers; it is not needed on DNS resolver software that does not
support the functions of an authoritative NS server. Thus, all usage
of normative [RFC2119] language is applicable only to DNS server
implementations that claim support of this specification.
Whereas the original IXFR already is widely implemented, IXFR-ONLY
offers an operational choice for administrators of zones with a non-
trivial propagation graph for the authoritative zone data, who are
looking for more options to fine-tune the synchronization efficiency
of their authoritative servers. It could be implemented without bare
IXFR, but for the sake of backwards compatibility and flexibility,
and for simplicity in documentation, we strongly recommend that IXFR-
ONLY be always implemented in concert with bare IXFR.
2. Principles of IXFR Protocol Operation
Each version of the authoritative date of a DNS zone is edentified by
the SOA serial number (cf. Section 3.3.13 of [RFC1035]); succesive
versions are tagged with monotonically increasing serial numbers.
Below, serial numbers are symbolically referred to by "sn" with some
distinguishing postfix.
When an IXFR client currently serving sn_o of a particular zone
receives a trigger that it should incrementally update the zone data,
it sends one of the flavors of an IXFR request to an IXFR server,
with the expectation to obtain in the IXFR repsonse the change
information necessary to transform the sn1 zone data into the zone
data of the current zone version, say, sn_n.
The details of which triggers can and will start such IXFR session
are implementation dependent. Possible triggers are some time
schedule or a management request, but most likely the IXFR query will
be triggered by a DNS NOTIFY message received by an authoritative
server of higher precedence in the propagation graph for the zone.
Possible IXFR servers are usually configured (per zone) on an IXFR
client, amended with some indication of precedence. Similarly, IXFR
servers are configured (per zone) with the identities of the
secondary servers they should accept as IXFR clients. This way, some
authoritative servers for a given zone may act both as an IXFR client
Hoenes & Sury Expires April 22, 2011 [Page 6]
Internet-Draft DNS Incremental Zone Transfer October 2010
and an IXFR server. Among all authoritative servers for a zone, at
least one server (the primary server of the zone) is not acting as an
IXFR client. This way, the {IXFR server, IXFR client} pairs form a
binary relation on the set of these servers that defines a directed
graph rooted at the primary server(s); this is the IXFR propagation
graph for the zone.
Note that, for the purpose of IXFR, it is possible that more than
one server can be acting as a primary server; this requires that
zone synchronization between these servers is accomplished by
other meachanisms, e.g., AXFR, or non-DNS means like distributed
database technology.
The most simple propagation graph is a star (hub and spokes)
configuration, with the primary server as the central hub. For
redundancy, important zones with many authoritative servers are
likely to be configured with a more dense propagation graph that
gives each IXFR client a choice of multiple IXFR servers to contact,
for the sake of resilience and/or load sharing. All these
configuration details are a strictly local matter and do not affect
interoperability. The only property of the propagation graph that
needs to be ensured by the zone administration is that each secondary
(i.e. non-primary) server must be reachable by at least one path in
this graph that originates in a primary server.
In order to be able to act as a useful IXFR server, a DNS server
needs to keep track of the zone history, to a certain extent (as
directed by local policy, as well). To this end, the server must
maintain knowledge of the changes that have been applied successively
to the zone content from one SOA serial up to the current version.
This does not necessarily mean that each change needs to be recorded,
however; if some parts of the zone content change frequently, it
might be preferable to coalesce subsequent chunks of change
information -- both for local storage and/or for transmission --, for
instance instead of the change information from sn_1 to sn_2 and the
change information from sn_2 to sn_3 (where sn_1 < sn_2 < sn_3), the
change information from sn_1 to sn_3 can be provided. This
condensation of data has some downsides, however: if an IXFR client
serves sn_2 and asks an IXFR server for the delta information to the
current version of the zone, but the server has performed the above
condensation, it has no way to tell the necessary information to the
IXFR client, and the IXFR request necessarily is doomed to fail.
Therefore, is becomes apparent that an IXFR server must maintain
seemless chains of change information chunks from all past SOA serial
number values it wants/needs to support (because potential IXFR
clients currently serve these zone versions) to the current zone
version. See Section XXX for more details on Condensation.
Hoenes & Sury Expires April 22, 2011 [Page 7]
Internet-Draft DNS Incremental Zone Transfer October 2010
Upon receipt of any IXFR query, the IXFR server conceptionally
constructs a chain of change information chunks from the SOA serial
number indicated by the client (sn_o) to the current zone version
(sn_n).
If this is not possible, in the case of bare IXRF, the server falls
back to AXFR, i.e. it provides the full zone content. In the case of
an IXFR-ONLY query, however, an error response is returned
immediately to the IXFR client, thus giving it a chance to try with
another IXFR server that might (still) serve the client's sn_o
without immediately incurring the potential overhead of a full zone
transfer.
In case it turns out that the IXFR client already has the current
zone version (sn_o = sn_n), the IXFR server does not reply with an
empty chain of chunks, but with the (current) SOA record of the zone.
If the IXFR server determines that it would be inefficient to
transfer the series of chunks, it also may fall back to full zone
transfer. Note that this is recommended behavior for the IXFR
server, but the correct protocol operation does not depend on this
(useful) optimization.
Ordinarily, in the generic case, the IXFR server transmits the change
information chunks in their "natural" order (by ascending sn) to the
IXFR client.
Each such change information chunk -- say from sn_a to sn_b -- is
represented by a sequences of RR deletions and a sequence of
subsequent RR additions, all of which need to be applied in order to
transform the zone content at sn_a to the zone content at sn_b. For
transfer in the IXFR response, each sequence starts with the
corresponding SOA RR as its delimiter, and the other RRs within it
can be given in arbitrary order.
The whole chain of change information chunks is embedded in a pair of
two copies of the new SOA RR (at sn_n).
For example, if the IXFR server wants to transmit the changes from
sn_o to sn_n in three chunks, based on two intermediary zone versions
at sn_1 and sn_2 (where sn_o < sn_1 < sn_2 < sn_n), i.e., the chunk
with the change information from sn_o to sn_1, the chunk from sn_1 to
sn_2, and the chunk from sn_2 to sn_n, it would deliver in the IXFR
response packet(s) the following resource records (RRs), in order:
Hoenes & Sury Expires April 22, 2011 [Page 8]
Internet-Draft DNS Incremental Zone Transfer October 2010
* SOA for sn_o # outer bracket
* SOA for sn_o # start of first chunk
* {other RRs to be deleted from the zone at sn_o}
* SOA for sn_1
* {other RRs to be added for getting the zone at sn_1}
* SOA for sn_1 # start of second chunk
* {other RRs to be deleted from the zone at sn_1}
* SOA for sn_2
* {other RRs to be added for getting the zone at sn_2}
* SOA for sn_2 # start of third chunk
* {other RRs to be deleted from the zone at sn_2}
* SOA for sn_n
* {other RRs to be added for getting the zone at sn_n}
* SOA for sn_n # outer bracket
In contrast, in the case of fallback to AXFR, the IXFR response would
convey, in order:
* SOA for sn_n # first instance
* {DNSSEC signature RRs for the SOA, if any}
* {other RRsets of the zone at sn_n, in arbitrary order}
* SOA for sn_n # repeated as trailing delimiter
3. IXFR Messages
This section specifies the format of IXFR messages and the basic
message generation and processing rules.
An IXFR session is started with an IXFR query message sent from an
IXFR client to an IXFR server, which solicits one of more response
messages in return.
All these messages adhere to the basic DNS message format specified
in RFC 1035 [RFC1035] and later amended in various ways, for which
Section 2 of RFC 5936 gives an expanded bibliography. Implementers
should be aware of the considerations in "Measures for Making DNS
More Resilient against Forged Answers" [RFC5452] and follow the
recommendations given there.
For convenience of the reader, the synopsis of the DNS message header
from RFC 5395 [RFC5395] (and the IANA registry for DNS Parameters
[DNSVALS]) is reproduced here informally:
Hoenes & Sury Expires April 22, 2011 [Page 9]
Internet-Draft DNS Incremental Zone Transfer October 2010
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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".
An IXFR session can be carried out over UDP (with tight restrictions
-- see below) and over TCP. Thus, the DNS message size limit from
RFC 1035 for DNS over UDP (and its extension specified in RFC 2671,
"Extension Mechanisms for DNS (EDNS0)" [RFC2671]) apply in the former
case. BCP 145, "Unicast UDP Usage Guidelines for Application
Designers" [RFC5405] contains valuable considerations regarding IP
level fragmentation of UDP messages, and "Security Assessment of the
Internet Protocol version 4" [I-D.ietf-opsec-ip-security] contains a
detailed security assessment of IPv4 segmentation and reassembly;
both documents should be considered by implementers when deciding on
the maximum size of DNS repsonse messages over UPD supported by an
IXFR server implementation. 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, and it
applies to IXFR over TCP.
Note that unlike with all common DNS responses, but like AXFR, the
IXFR protocol makes no use of the TC (truncation) bit. To signal
that an IXFR session needs to be retried over TCP, an IXFR server
sends a response that only contains its current version of the SOA
RR for the zone.
3.1. IXFR Query
An IXFR query is sent by a client whenever it wants to obtain the
delta information needed to update the content of a zone it is aware
of (as identified by its SOA serial number) to the most recent
Hoenes & Sury Expires April 22, 2011 [Page 10]
Internet-Draft DNS Incremental Zone Transfer October 2010
version. The predominant trigger for this is the receipt of a DNS
NOTIFY message [RFC1996], but it also can be triggered by other
mechanisms or events, for instance as a result of a command line
request, say for debugging. The details for these triggers are
implemenation dependent and out of scope for this specification.
3.1.1. Header Values
The specification for AXFR in Section 2.1.1 of RFC 5936 applies
likewise for IXFR queries, with a single exception:
NSCOUNT Number of entries in Authority section; MUST be 1
3.1.2. Question Section
The Question section of an IXFR query MUST conform to Section 4.1.2
of RFC 1035, and it MUST contain (matching QDCOUNT=1 in the DNS
message header) a single resource record with the following values:
QNAME the name of the zone requested
QTYPE one of the pseudo-RR types for incremental zone
transfer: IXFR (= 251) or IXFR-ONLY (= {IANA-TBD1})
[DNSVALS]
QCLASS the class of the zone requested [DNSVALS]
The choice of QTYPE depends on the intended IXFR server behavior in
case the request cannot be fulfilled due to lack of stored
information on the server, as detailed below in Section 3.2.
3.1.3. Answer Section
The Answer section MUST be empty, as indicated by ANCOUNT=0 in the
DNS message header.
3.1.4. Authority Section
Corresponding to NSCOUNT=1 in the DNS message header, the Authority
section MUST contain a single DNS resource record, the SOA record of
the client's version of the zone content, identified by its serial
number (denoted as sn_o in this document).
3.1.5. Additional Section
Currently, two kinds of resource records are defined that can appear
in the Additional section of IXFR queries and responses: EDNS and DNS
transaction security. Future specifications defining RRs that can be
Hoenes & Sury Expires April 22, 2011 [Page 11]
Internet-Draft DNS Incremental Zone Transfer October 2010
carried in the Additional section of normal DNS transactions need to
explicitly describe their use with IXFR, should that be desired.
All considerations from Section 2.1.5 of RFC 5936 apply in the same
manner for IXFR as they do for AXFR.
[[ Do we need to make EDNS support a MUST for IXFR-ONLY (over UDP),
in order to allow IANA to assign an extended RCODE for CannotIXFR ?
]]
3.2. IXFR Response
An IXFR server that has received an IXFR query responds to it with an
IXFR response addressed to the transport source identifier from which
the query has been received, in particular using the same transport
protocol.
An IXFR response consists of one or more response messages. If the
IXFR query has been received over a connectionless transport
(currently: UDP), the IXFR response MUST consist of a single message.
If it is not possible to send the complete response in a single DNS
message, a response only containing the currrent SOA RR at the server
is sent, whose serial sn_n being different from sn_o is the signal to
the IXFR client to retry over connection oriented transport
(currently: TCP).
If the server detects an error condition that makes it impossible to
fulfill the request, it immediately sends an error response. In case
of connetionless transport (UDP), this is the single response message
sent. In case of connection-oriented transport, the error condition
might occur after one of more response messages already have been
sent; in this case the error message is sent as soon as need arises,
and it will abort the ongoing IXFR session; i.e., the error message
is the last response message sent by the server. The special case of
a server closing the TCP connection without sending an IXFR response
message is covered in Section 2.3.
If an IXFR server is not able or willing to send the incremental zone
change information to change the client's version (sn_o) to its
version (sn_n), the server SHOULD, in the case of QTYPE=IXFR, fall
back to AXFR (see below); however, it MAY, and in the case of
QTYPE=IXFR-ONLY, it MUST respond with an appropriate error, e.g.
CannotIXFR (see below) in the case of QTYPE=IXFR-ONLY.
Any non-error IXFR response starts with the server's version of the
SOA resource record.
If the server detects that the client's version is current (sn_n =
sn_o), or if the server detects that the entire response to an IXFR
Hoenes & Sury Expires April 22, 2011 [Page 12]
Internet-Draft DNS Incremental Zone Transfer October 2010
query received over connectionless transport (UDP) cannot be placed
into a single response message, this SOA record is the only answer
sent to the client. Otherwise, the subsequent answer RRs sent form a
sequence of one or more change information chunks as described below
in Section 3.3, and the final RR sent is another copy of the current
SOA RR.
In case of fallback to AXFR, the answer contains the same RRs (and is
subject to the same ordering rules) as specified in Sections 2.2
through 3 of RFC 5936, with the single difference being the echoed
QCODE (i.e., IXFR) in the Question section.
[[ Move part of the above material to Section 4 ?? ]]
3.2.1. Header Values
The specification for AXFR in Section 2.2.1 of RFC 5936 applies
likewise for IXFR queries, where in the case of IXFR the "new"
behavior from RFC 5936 is always followed, i.e. the query ID from the
IXFR query is to be echoed in all IXFR response messages.
The only additonal rule to be followed applies to the deliberations
on the RCODE field in Note e) of Section 2.2.1 in RFC 5936: If the
IXFR server is not able to fulfill an IXFR-ONLY request, is SHOULD
respond with the (extended?) RCODE CannotIXFR (see Section
Section 10.
3.2.2. Question Section
In the first response message, the IXFR server MUST copy this section
from the corresponding IXFR query message. For subsequent messages,
it MAY do the same or leave the Question section empty. However, if
the last response message sent is an error message (RCODE unequal to
0), the query MUST also be copied. Accordingly, QDCOUNT in the DNS
message header is set to either 1 (query copied) or 0 (otherwise).
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
recipent (IXFR client) SHOULD apply the response verification rules
from RFC 5452 [RFC5452].
3.2.3. Answer Section
The Answer section MUST be populated with the zone change information
or, in the case of fallback to AXFR, the full zone contents. See
Section 3 below for details.
Hoenes & Sury Expires April 22, 2011 [Page 13]
Internet-Draft DNS Incremental Zone Transfer October 2010
3.2.4. Authority Section
Corresponding to NSCOUNT=0 in the DNS message header, the Authority
section in IXFR response messages MUST be empty.
3.2.5. Additional Section
All considerations from Section 2.1.5 (and hence, by reference, also
Section 2.1.5) of RFC 5936 apply in the same manner for IXFR as they
do for AXFR.
3.3. Connection Aborts
In case of an IXFR session carried over connection-oriented transport
(TCP), the considerations in Section 2.3 of RFC 5936 [RFC5936] apply
similarly.
In a nutshell: Servers SHOULD avoid dropping active connections
whenever possible, and clients nevertheless must be prepared to
gracefully deal with such aborts.
4. Response Contents
T. B. D.
5. Transport
T. B. D.
6. Server Behavior
T. B. D.
6.1. General
T. B. D.
6.2. Purging Strategy
T. B. D.
6.3. Optional Condensation of Zone Changes
T. B. D.
6.4. Authorization
T. B. D.
Hoenes & Sury Expires April 22, 2011 [Page 14]
Internet-Draft DNS Incremental Zone Transfer October 2010
7. Client Behavior
T. B. D.
7.1. Zone Integrity
T. B. D.
8. Backwards Compatibility
T. B. D.
9. Security Considerations
T. B. D.
10. IANA Considerations
The IANA Registry "Domain Name System (DNS) Parameters" [DNSVALS]
contains a sub-registry "Resource Record (RR) TYPEs", in which
[RFC5395] has reserved the range 128 through 255 for pseudo-RRs only
being used in DNS queries, for short "Q Types". This partial
namespace is managed under the "DNS RRTYPE Allocation Policy"
specified in RFC 5395 [RFC5395].
Since RFC 1995, the Q Type 251 has been assigned to IXFR. Upon
publication as an RFC, IANA will update / has updated the description
for that entry to say "incremental zone transfer" and the Reference
for that entry to point to this memo.
Upon publication of this memo as an RFC, IANA also will assign / has
assigned the Q Type {IANA-TBD1} to the TYPE mnemonic IXFR-ONLY, with
description "incremental zone transfer w/o fallback", and pointing to
this memo.
[[ TBD: assignment of a new, extended (??) RCODE value for CannotIXFR
({IANA_TBD2}) ]]
11. Acknowledgements
Masataka Ohta is acknowledged for his original work as the author of
RFC 1995 [RFC1995], and this extends to the contributors listed in
the Acknowledgements section of that RFC.
The specification of IXFR-ONLY in this document is based on the
original proposal [I-D.kerr-ixfr-only], whose authors are
acknowledged for identifying the operational need for this behavior
and carrying it to the IETF.
Hoenes & Sury Expires April 22, 2011 [Page 15]
Internet-Draft DNS Incremental Zone Transfer October 2010
Substantial text has been borrowed from both documents and from
[RFC5936].
The DNSEXT working group and its predecessor (DNSIND) are
acknowledged for their discussion on the above documents.
Your name could be here. ...
12. References
12.1. Normative References
[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.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC5395] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 5395, November 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, June 2010.
12.2. Informative References
[DNSVALS] IANA, ""Domain Name System (DNS) Parameters"", IANA
registry available at:,
<http://www.iana.org/assignments/dns-parameters>.
[I-D.ietf-opsec-ip-security]
Hoenes & Sury Expires April 22, 2011 [Page 16]
Internet-Draft DNS Incremental Zone Transfer October 2010
Gont, F., "Security Assessment of the Internet Protocol
version 4", draft-ietf-opsec-ip-security-03 (work in
progress), April 2010.
[I-D.kerr-ixfr-only]
Sury, O. and S. Kerr, "IXFR-ONLY to Prevent IXFR Fallback
to AXFR", draft-kerr-ixfr-only-01 (work in progress),
February 2010.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
Appendix A. Motivation for IXFR-ONLY
T. B. D.
Authors' Addresses
Alfred Hoenes
TR-Sys
Gerlinger Str. 12
Ditzingen D-71254
Germany
EMail: ah@TR-Sys.de
Hoenes & Sury Expires April 22, 2011 [Page 17]
Internet-Draft DNS Incremental Zone Transfer October 2010
Ondrej Sury
CZ.NIC
Americka 23
120 00 Praha 2
CZ
Phone: +420 222 745 110
EMail: ondrej.sury@nic.cz
Hoenes & Sury Expires April 22, 2011 [Page 18]