| DNSext Working Group | A. Hoenes |
| Internet-Draft | TR-Sys |
| Obsoletes: 1995 (if approved) | O.S. Sury |
| Intended status: Standards Track | CZ.NIC |
| Expires: October 29, 2011 | April 27, 2011 |
DNS Incremental Zone Transfer Protocol (IXFR)
draft-ah-dnsext-rfc1995bis-ixfr-02
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 likely be preferred over IXFR in specific deployments.
This document obsoletes and replaces RFC 1995.
This draft targets adoption by the DNSEXT working group. Comments should be sent to the authors and/or the namedroppers mailing list.
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 October 29, 2011.
Copyright (c) 2011 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.
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 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 in such scenarios 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, in this document.
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 whenever the chosen IXFR server does not have the wanted delta-update information available, but another possible IXFR server would, which incurs the additional overhead that the client wanted to avoid whenever possible by his initial choice to use IXFR. 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 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 they supply management, security, and IANA considerations.
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", "AXFR 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, for instance 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, for instance the primary server for a zone as specified in STD 13 or a secondary server that already has synchronized with the primary server, and that 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".
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 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 DNS server. Thus, all usage of normative BCP 14 [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.
Each version of the authoritative date of a DNS zone is identified 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, say, sn_o of a particular zone receives a trigger that it should incrementally update the zone data, it sends one of the two flavors of an IXFR request to an IXFR server, with the expectation to obtain in the IXFR response the change information necessary to transform the sn_o 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 from 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 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.
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, for the sake of resilience and/or load sharing, gives IXFR clients a choice of multiple IXFR servers to contact. All these configuration details are a strictly local matter and do not affect interoperability; hence, these details are out of scope for this specification. 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 6.3 for more details on Condensation.
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 IXFR, 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 an alternate IXFR server that might (still) serve the client's sn_o and not to immediately incur 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 (conceptionally and on the wire) by a sequence 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 copies of the new SOA RR (at sn_n) that serve as "sentinels". It is important to point out that SOA RR is used only as a marker in this context and can appear multiple times, as opposed to RRSIG(SOA) RR which is treated as a common record and needs to appear only once in the zone. That also means that RRSIG(SOA) RR for sn_o has to be deleted and RRSIG(SOA) RR for sn_n has to be added. In other words RRSIG(SOA) doesn't get any special treatment in the context of IXFR and SOA RRs used as "sentinels".
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:
In contrast, in the case of fallback to AXFR, the IXFR response would convey, in order:
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 or more response messages in return.
All these messages adhere to the basic DNS message format as 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.
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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:
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 response 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.
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 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.
NSCOUNT Number of entries in Authority section; MUST be 1
The specification for AXFR query messages in Section 2.1.1 of RFC 5936 applies likewise for IXFR queries, with a single exception:
QNAME the name of the zone requested
QTYPE one of the two pseudo-RR types for incremental zone
transfer: IXFR (= 251) or IXFR-ONLY (= {TBD1})
[DNSVALS]
QCLASS the class of the zone requested [DNSVALS]
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: Section 3.2.
The Answer section MUST be empty, as indicated by ANCOUNT=0 in the DNS message header.
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).
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 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.
In order to support extended RCODE for CannotIXFR, the IXFR-ONLY requires EDNS0 support (RFC 2671 [RFC2671]).
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).
The conceptional "answer" carried in a multi-message response is the concatenation of the content of the Answer sections in these response messages, in the order they are sent; this is unambiguous from the point of view of the IXFR client as well since the applicable connection-oriented transport preserves the order of messages sent.
If the server detects an error condition that makes it impossible to fulfill the request, it immediately sends an error response, that is a response message with non-zero RCODE. In case of connectionless transport (UDP), this is the single response message sent. In case of connection-oriented transport (TCP), 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 3.3.
If an IXFR server is not able or willing to send the incremental zone change information to transform the client's version (sn_o) to its newer version (sn_n), the server SHOULD, in the case of QTYPE=IXFR, fall back to AXFR (see below). In the case of QTYPE=IXFR-ONLY, it MUST respond with an appropriate error, e.g., CannotIXFR (see below).
Any non-error IXFR response starts with the server's version of the SOA resource record, sn_n.
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 query received over connectionless transport (UDP) cannot be placed into a single response message, this SOA record is the only answer RR 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 4, and the final "sentinel" 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 ?? ]]
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 MUST 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 assigned on behalf of this document (see Section 10).
In the first response message, the IXFR server MUST copy this section literally from the corresponding IXFR query message. For subsequent response 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).
When it is present, 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].
The Answer section MUST be populated with the zone change information or, in the case of fallback to AXFR, the full zone contents.
For multi-message IXFR responses, the conceptional answer is split into segments that are sent in order. Each segment is comprised of an integer number of full RRs, and for transport efficiency, the response messages should be filled up with answer RRs as much as possible for the response message size chosen by the IXFR server, taking into account the space needed for the other sections in the messages.
See Section 4 below for the normative details of the resource record ordering requirements.
Corresponding to NSCOUNT=0 in the DNS message header, the Authority section in IXFR response messages MUST be empty.
All considerations from Section 2.2.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. See also Section 3.1.5 of this document.
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.
This section describes the structure of the sequence of resource records (RRs) sent in IXFR reponses and how the IXFR client can distinguish the various cases covered.
If the IXFR server discovers an error condition before it sends the first (or only) response message, the response content in the Answer section is empty, and consequentially, ANCOUNT is set to 0 in that message.
Whenever in the above cases the text says that the IXFR client "MUST discard the message", the following behavior is implied: The IXFR client MUST regard the IXFR session as terminated; this results in subsequent silent discarding of further response messages that still pretend to belong to the same IXFR session by means of the query ID and the echoed Question, if present, because the IXFR client does not maintain corresponding IXFR query/session state any more. The IXFR client MAY log the event and SHOULD regard the IXFR server as broken; hence, it SHOULD refrain from using the same IXFR server again -- at least for considerable time, or until the usage has been reinstated by an implementation-dependent management interaction.
From the above decision tree for the client it also follows that, to allow unambiguous client behavior, if an IXFR server has to send a response comprised of two or more RRs, it MUST send at least the first two RRs in the first response message.
If the IXFR server discovers an error condition lately, after having sent one or more response messages (all with RCODE set to 0), it can abort the IXFR session by sending another response message with empty Answer section and a non-zero RCODE. This MUST be the last message sent in response to the IXFR query, that is, this error message aborts the ongoing IXFR session.
In an incremental response, the leading sn_n SOA RR is followed by one or more change information chunks and concluded by a second copy of the sn_n SOA RR.
Each change information chunk describes the changes to be performed on a given "origin" version of the zone to obtain a "target" version of the zone (i.e., one SOA serial change of the zone). It consists of (1) a set of old RRs to be deleted from the "origin" zone version and (2) a set of new RRs to be added after these deletions to obtain the "target" version of the zone. (In this model, a change in a single RR is represented by an RR deletion followed by an RR addition.) These two sets are sent in this order, with each set serialized as a sequence of the related SOA RR followed by other, non-SOA RRs in a arbitrary order. This way, each SOA RR indicates the end of the sequence of (zero or more) non-SOA RRs that precedes it, and at the same time it either starts the next set of RRs or is the trailing sn_n SOA of the response.
The "origin" sn of each change information chunk MUST precede its "target" sn in the sense of sequence number arithmentics.
The change information chunks in an incremental response MUST be ordered oldest first, newest last; in more detail: The first change information chunk in an incremental response must have the client's version (sn_o) as its origin sn; the origin sn of each subsequent change information chunk MUST be the same as the target sn of the preceding chunk, and the last change information chunk in an incremental response MUST have the server's version (sn_n) as its target sn. This "chaining" of chunks ensures that the client can correctly construct the sn_n version from the sn_o version it holds by conceptionally applying single-RR deletions and additions in the order the RRs appear in the IXFR response.
Note that, as a consequence of the aforementioned rules, a valid incremental IXFR response MUST contain exactly one copy of the sn_o SOA RR (sent as the second RR in the response) and exactly three copies of the sn_n SOA RR -- one as the first RR in the response, one as the leading RR of the second sequence (set of RRs to be added) in the last change information chunk, and one as the final "sentinel" RR that indicates the end of the response contents.
Any IXFR response classified as a (non-empty) incremental response by the decision tree presented above in Section 4 that violates any of the above rules MUST cause the IXFR client to regard the response as bogus; it MUST discard a response message in case its content allows the client to detect such violation, with the caveats for "discard" given in Section 4.
In support of avoiding clients to draw wrong conclusions on the end of an incremental response, it is RECOMMENDED that an IXFR server not send the aforementioned second instance of the sn_n SOA RR as the last RR in a (non-final) response message.
IXFR servers and IXFR clients MUST support transport over UDP and TCP (see RFC 5966 [RFC5966]). As with all DNS transactions, IXFR responses MUST be sent on the same transport association over which the query arrives at the server.
If an IXFR server cannot send a full IXFR response for an IXFR query received over UDP within a single response message over UDP due to message size limitations, it MUST return the special form of response that indicates to the client to retry over TCP (single-RR response with the server SOA only, as described in Sections 3.2 and 4).
Given the limitation of the basic DNS message size over UDP to 512 octets, it is strongly RECOMMENDED that implementations of IXFR servers and IXFR clients support RFC 2671, "Extension Mechanisms for DNS (EDNS0)" [RFC2671]) and chose extended DNS message size limits appropriate for their environment. The default behavior of IXFR clients regarding the EDNS message size, and the maximum accepted by servers, SHOULD both be configurable.
The considerations for AXFR transport over TCP in Section 4 of RFC 5936 [RFC5936] apply similarly for IXFR. However, IXFR is commonly being used much more frequently than AXFR between a given pair of authoritiative servers, and often not authorized for use by servers outside the set of authorities for a zone, which are all under the control of a single administrative domain or a small number of cooperating administrative domains. In this environment, it might make sense for the sake of efficiency to maintain (and reuse) persistent TCP connections between the configured IXFR peers. Therefore, implementations of IXFR should allow to configure relatively high TCP User Timeout values and support the TCP UTO mechanism ([RFC5482]) that allows the peers to exchange their view of the TCP User Timeout and adapt the behavior of their TCP accordingly.
General considerations on IXFR server behavior, in particular response message generation and packet processing, are spread all over this document; in particular, see Sections 3.2 and 4.
In addition to the current zone content, IXFR servers need to maintain history information on the zone content that enables them to respond with incremental responses for a sufficient range of versions. What is considered "sufficient" and how this history information is maintained, is a local matter. It may be appropriate to maintain the history information on stable storage as well to make it available spanning restarts of an IXFR server, as it is already required for the current zone content.
An IXFR server cannot be required to hold all previous versions forever and may delete them anytime. In general, there is a trade-off between the size of storage space and the possibility and need of using IXFR.
Information about older versions should be purged as soon as the total length of an IXFR response would otherwise become larger than that of an AXFR response. Given that the purpose of IXFR is to reduce AXFR overhead, this strategy is quite reasonable. The strategy assures that the amount of storage required is at most twice that of the current zone information.
Information older than the SOA expire period may also be purged.
The Condensation techniques explored below in Section 6.3 might pose an opportunity to get rid of more recent, yet less relevant history information and as such might allow to cover a larger span of SOA versions than otherwise possible within the same amount of storage.
An IXFR server MAY optionally condense a number of immediately succeeding change information chunks into a single chunk, thus dropping information on intermediate zone versions.
This may be beneficial if a lot of versions, not all of which are useful, are generated. For example, if multiple ftp servers share a single DNS name and the IP address associated with the name is changed once a minute to balance load between the ftp servers, it is not so important to keep track of all the history of changes.
Another example is where statefully managed client systems get IP addresses assigned dynamically by DHCP servers, and where the DHCP server(s) and/or the clients register their current contact information via DNS UPDATE whenever leases are given out or renewed. These transactions could be comprised of several independent update steps, for forward and reverse address resolution, for service discovery, etc., where multiple parts of the related information are maintained in the same zone. Intelligent condensation strategies might be able to identify subsequent incremental changes related to a single end-user system and collapse this information in a single change information chunk.
But this feature may not be so useful if an IXFR client has access to two IXFR servers, A and B, with inconsistent condensation results. The current version of the IXFR client, received from server A, may be unknown to server B. In such a case, server B cannot provide incremental data from the unknown version and a full zone transfer is necessary. Therefore, it is highly desirable that alternative IXFR servers for a given set of IXFR clients expose similar (or at best, the same) condensation behavior.
Condensation can be performed in two stages, perhaps in a complementary manner: Firstly, the history information stored on an IXFR server can be condensed to reduce storage requirements *and* IXFR response sizes to some degree. Additionally, IXFR servers can perform condensation "on the fly" in preparing IXFR responses; this might provide additional savings in IXFR response size while reducing the likelihood that IXFR queries cannot be responded with incremental responses due to the requested sn being "condensed out" of the stored history information.
Condensation is completely optional. Clients cannot detect from the response whether or not the server has condensed the reply.
For interoperability, IXFR servers, including those without the condensation feature, SHOULD NOT send an error response in case they receive a client's IXFR request with an unknown version number and SHOULD, instead, attempt to perform a full zone transfer. Of course, this does not apply if the client indicates its desire to try its luck in such case at another candidate IXFR server, by initiating the request with IXFR-ONLY.
The considerations for AXFR presented in Section 5 of RFC 5936 [RFC5936] apply in a similar fashion for IXFR.
Given the basic desire for frequent use and the resulting processing load, operational considerations will, even more likely than for AXFR, dictate the need to closely restrict the usage of IXFR to the set of authoritiative servers for a given zone, and to precisely configure the IXFR distribution graph within the set of servers, by means of access lists on the server side and by configuring a prioritized IXFR server search list on the client side.
Since IP addresses can be spoofed rather trivially in large parts of the open Internet, better authentication methods are needed as a base for authorization decisions unless the IXFR distribution graph can be restricted to protected networks under control of the same administration as the participating DNS servers.
In particular, as detailed in the Section of RFC 5936 quoted above, implementations of IXFR SHOULD also support at least one flavor of DNS transaction security. Virtual private networks, virtual LANs, IPsec ([RFC4301]), and TCP-AO ([RFC5925] might also be applicable solutions to ensure proper authentication to base authorization decisions on. See Section 9 for more information.
It is RECOMMENDED that IXFR client implementations supporting IXFR-ONLY allow to configure its usage per IXFR server, as part of the IXFR distribution graph configuration.
An IXFR client SHOULD set an appropriate guard timeout whenever the content of a response message indicates that this is not the final message of an IXFR response. In case this timeout period elapses without another response message arriving, it SHOULD regard the IXFR session as failed and apply the caveats for the "discard" case presented in Section 4.
The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936 [RFC5936] apply in a similar fashion for IXFR.
However, during the receipt of an incremental IXFR response, and upon successful processing of an SOA RR that serves as a sentinel for the end of any change information chunk, an IXFR client MAY immediately apply and commit to stable storage the SOA serial number change described by that chunk (and previous chunks, if not already done). This operation MUST externally appear as an atomar operation.
Despite a few potentially misleading statements in the previous specification, only a single detail has been identified so far that could give rise to backward compatibility concerns. This is addressed by the compatibility rules in Section 4 that allow an IXFR client to process an "empty incremental response" consisting of only a pair of instances of the server's SOA RR.
The introduction of IXFR-ONLY creates further interoperability considerations. An IXFR server utilizing IXFR-ONLY may receive an error response different from CannotIXFR persistently. (The actual RCODE reveived may depend on whether or not the server is aware of the allocation of the range of RR types set aside for Q Types in [RFC5395], from which the IXFR-ONLY code point has been assigned.) This event likely indicates that the IXFR server chosen does not support IXFR-ONLY. In such case, the client will mark the server as "unusable of IXFR-ONLY" in his server list and try another potential IXFR server, or, if all candidates fail, retry the scan with bare IXFR, or alternatively try to immediately start an AXFR session. The latter should always be the method of last resort in case of persistent IXFR failures.
This document presents a more detailed specification for the mechanism previously specified in RFC 1995, which has similar protocol behavior and security properties as the AXFR mechanism described in RFC 5936. Hence, beyond the general security considerations for the DNS laid down in RFC 3833 [RFC3833], similar considerations apply.
Thus, the sections on Transport, Authorization and Zone Integrity that all include by reference the respective sections of RFC 5936 [RFC5936] largely address the relevant concerns. Deployments of IXFR might be interested in using large values for the EDNS message size and thereby become more exposed to the various security threats against IP fragmentation; these and suitable mitigations are discussed in [I-D.ietf-opsec-ip-security].
Since IXFR is likely to be used in a more frequent and continuous manner and hence a possible candidate for making use of long-lived, persistent TCP connections for its transport, besides IPsec (RFC 4301 [RFC4301]), the more lightweight TCP Authentication mechanism described in RFC 5925 (TCP-AO, [RFC5925]) might, once deployed, be a suitable candidate for peer authentication and integrity protection of IXFR sessions.
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 of this memo 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 RFC.
Upon publication of this memo as an RFC, IANA also will assign / has assigned the Q Type {TBD1} to the TYPE mnemonic IXFR-ONLY, with description "incremental zone transfer w/o fallback", and pointing to this memo.
RCODE Name Description Reference
--------- ---------- ---------------------------------- ---------
{TBD2} CannotIXFR IXFR not possible, would fall back [RFCthis]
[[ Do we want one of the remaining five basic RCODEs (11..15), or
would an Extended RCODE from the 23..3840 range be acceptable? ]]
IANA is requested to allocate / has allocated from the "DNS RCODEs" sub-registry of the "Domain Name System (DNS) Parameters" Registry [DNSVALS] a new RCODE value for CannotIXFR:
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.
The DNSEXT working group and its predecessor (DNSIND) are acknowledged for their discussion on the above documents. Substantial text has been borrowed from there and from [RFC5936].
Your name could be here. ...
| [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. |
| [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", 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. |
IXFR is an efficient means to transfer changes in zones from IXFR servers to IXFR clients. However, when an IXFR client has multiple IXFR servers for a single zone, it is possible that not all IXFR servers hold the zone content with the same serial number(s). In this case, if an IXFR client attempts an IXFR from an IXFR server that does not have the zone content with the serial number used by the IXFR client, the IXFR server will fall back to a full zone transfer (AXFR) when it has a version of the zone with serial number greater than the serial requested by the IXFR client.
For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the same zone. An IXFR client that has the zone content with serial number 2 and sends an IXFR request to IXFR server NS2 will get a full zone transfer (AXFR) of the zone at serial number 3. This is because NS2 does not know the zone with serial number 2, and therefore is not able to report the differences are between zone with serial number 2 and 3.
If the IXFR client in this example had known to send the query to IXFR server NS1, then it could have gotten an incremental transfer. But an IXFR clients can only know what the *latest* version of the zone is at an IXFR server -- this information is available via an SOA query.
The IXFR-ONLY query type provides a way for the IXFR client to ask each IXFR server to return an error instead of sending the current version of the zone via full zone transfer. By using this, an IXFR client can check each IXFR server until it finds one able to actually provide an incremental transfer. If it doesn't succeed, it can fall back and try with bare IXFR instead of IXFR-ONLY, or it can immediately start an AXFR session with an AXFR server of its choice (the preferred AXFR server might be distinct from the most prefered IXFR server).
By providing IXFR-ONLY support, the policy control over the zone synchronization operation switches to the client side, which is preferable under various operational settings.