< draft-ietf-dnsext-rfc1995bis-ixfr-00.txt   draft-ietf-dnsext-rfc1995bis-ixfr-01.txt >
DNSext Working Group A. Hoenes DNSext Working Group A. Hoenes
Internet-Draft TR-Sys Internet-Draft TR-Sys
Obsoletes: 1995 (if approved) O. Sury Obsoletes: 1995 (if approved) O. Sury
Intended status: Standards Track CZ.NIC Intended status: Standards Track CZ.NIC
Expires: September 28, 2012 S. Kerr Expires: October 25, 2012 S. Kerr
ISC ISC
March 27, 2012 April 23, 2012
DNS Incremental Zone Transfer Protocol (IXFR) DNS Incremental Zone Transfer Protocol (IXFR)
draft-ietf-dnsext-rfc1995bis-ixfr-00 draft-ietf-dnsext-rfc1995bis-ixfr-01
Abstract Abstract
The standard means within the Domain Name System protocol for The standard means within the Domain Name System protocol for
maintaining coherence among a zone's authoritative name servers maintaining coherence among a zone's authoritative name servers
consists of three mechanisms. Incremental Zone Transfer (IXFR) is consists of three mechanisms. Incremental Zone Transfer (IXFR) is
one of the mechanisms and originally was defined in RFC 1995. one of the mechanisms and originally was defined in RFC 1995.
This document aims to provide a more detailed and up-to-date 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 IXFR mechanism and to align it with the current
specification of the primary zone transfer mechanism, AXFR, given in specification of the primary zone transfer mechanism, AXFR, given in
RFC 5936. Further, based on operational experience, this document RFC 5936. Further, based on operational experience, this document
juxtaposes to the original IXFR query a new query type, IXFR-ONLY, juxtaposes to the original IXFR query a new query type, IXFR-ONLY,
that will likely be preferred over IXFR in specific deployments. that will likely be preferred over IXFR in specific deployments.
This document obsoletes and replaces RFC 1995. This document obsoletes and replaces RFC 1995.
Discussion Discussion
This draft targets adoption by the DNSEXT working group. Comments Comments should be sent to the authors and/or the dnsext mailing
should be sent to the authors and/or the dnsext mailing list. list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2012. This Internet-Draft will expire on October 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview of DNS Zone Synchronization . . . . . . . . . . . 4 1.1. Overview of DNS Zone Synchronization . . . . . . . . . . . 4
1.2. Incremental Zone Transfer (IXFR) - Conclusions from 1.2. Incremental Zone Transfer (IXFR) - Conclusions from
Experience . . . . . . . . . . . . . . . . . . . . . . . . 4 Experience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Principles of IXFR Protocol Operation . . . . . . . . . . . . 6 2. Principles of IXFR Protocol Operation . . . . . . . . . . . . 7
3. IXFR Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 3. IXFR Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. IXFR Query . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. IXFR Query . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Header Values . . . . . . . . . . . . . . . . . . . . 12 3.1.1. Header Values . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Question Section . . . . . . . . . . . . . . . . . . . 12 3.1.2. Question Section . . . . . . . . . . . . . . . . . . . 12
3.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . 12 3.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . 12
3.1.4. Authority Section . . . . . . . . . . . . . . . . . . 12 3.1.4. Authority Section . . . . . . . . . . . . . . . . . . 12
3.1.5. Additional Section . . . . . . . . . . . . . . . . . . 13 3.1.5. Additional Section . . . . . . . . . . . . . . . . . . 13
3.2. IXFR Response . . . . . . . . . . . . . . . . . . . . . . 13 3.2. IXFR Response . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Header Values . . . . . . . . . . . . . . . . . . . . 14 3.2.1. Header Values . . . . . . . . . . . . . . . . . . . . 14
3.2.2. Question Section . . . . . . . . . . . . . . . . . . . 15 3.2.2. Question Section . . . . . . . . . . . . . . . . . . . 15
3.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . 15
3.2.4. Authority Section . . . . . . . . . . . . . . . . . . 15 3.2.4. Authority Section . . . . . . . . . . . . . . . . . . 16
3.2.5. Additional Section . . . . . . . . . . . . . . . . . . 16 3.2.5. Additional Section . . . . . . . . . . . . . . . . . . 16
3.3. Connection Aborts . . . . . . . . . . . . . . . . . . . . 16 3.3. Connection Aborts . . . . . . . . . . . . . . . . . . . . 16
4. Response Contents . . . . . . . . . . . . . . . . . . . . . . 16 4. Response Contents . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Incremental Responses . . . . . . . . . . . . . . . . . . 18 4.1. Incremental Responses . . . . . . . . . . . . . . . . . . 20
5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Purging Strategy . . . . . . . . . . . . . . . . . . . . . 21 6.2. Purging Strategy . . . . . . . . . . . . . . . . . . . . . 23
6.3. Optional Condensation of Zone Changes . . . . . . . . . . 21 6.3. Optional Condensation of Zone Changes . . . . . . . . . . 23
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 24
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . 25
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 24 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Motivation for IXFR-ONLY . . . . . . . . . . . . . . 27 Appendix A. Motivation for IXFR-ONLY . . . . . . . . . . . . . . 30
Appendix B. Substantial Changes Since RFC 1995 . . . . . . . . . 28 Appendix B. Substantial Changes Since RFC 1995 . . . . . . . . . 31
Appendix C. Evaluation of List Discussion, Draft Changes Appendix C. Change Log of WG Draft . . . . . . . . . . . . . . . 32
since Individual Draft -02 . . . . . . . . . . . . . 29 C.1. Draft Version 00 -> 01 . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
1.1. Overview of DNS Zone Synchronization 1.1. Overview of DNS Zone Synchronization
The Domain Name System (DNS) standard facilities for maintaining The Domain Name System (DNS) standard facilities for maintaining
coherent servers for a zone consist of three elements. Authoritative coherent servers for a zone consist of three elements. Authoritative
Transfer (AXFR) originally was defined in STD 13: "Domain Names - Transfer (AXFR) originally was defined in STD 13: "Domain Names -
Concepts and Facilities" [RFC1034] (referred to in this document as Concepts and Facilities" [RFC1034] (referred to in this document as
RFC 1034) and "Domain Names - Implementation and Specification" RFC 1034) and "Domain Names - Implementation and Specification"
skipping to change at page 4, line 40 skipping to change at page 4, line 40
zone; this is accomplished by the DNS NOTIFY mechanism [RFC1996]. zone; this is accomplished by the DNS NOTIFY mechanism [RFC1996].
The time and resources needed to accomplish the transfer of the new The time and resources needed to accomplish the transfer of the new
zone content to the secondary servers in many cases can be reduced zone content to the secondary servers in many cases can be reduced
substantially by only carrying forward the changes from a previous substantially by only carrying forward the changes from a previous
version of the zone data. This is accomplished by the IXFR mechanism version of the zone data. This is accomplished by the IXFR mechanism
originally specified in RFC 1995 [RFC1995] and, more precisely, in originally specified in RFC 1995 [RFC1995] and, more precisely, in
this document. this document.
1.2. Incremental Zone Transfer (IXFR) - Conclusions from Experience 1.2. Incremental Zone Transfer (IXFR) - Conclusions from Experience
The original specification for IXFR [RFC1995] has widely been
perceived as not precise and detailed enough to ensure interoperable
implementations, and multiple reports have been made to DNS working
groups of observed IXFR implementation behavior that was not regarded
as conformant with the spirit of the specification, as seen by the
rough consensus of the community. Therefore, this document aims at
giving a much more detailed and precise specification for the IXFR
protocol, incorporating experience from more than a decade and
evolved points of view -- in particular regarding security aspects of
DNS operations. Implementations of this RFC are fully backward
compatible with "proper" implementations of RFC 1995, but conformant
implementations follow some more specific requirements included in
this RFC to improve the performance and resilience of IXFR sessions.
The original IXFR automatically falls back to AXFR behavior whenever The original IXFR automatically falls back to AXFR behavior whenever
the IXFR server cannot fulfill the given delta-update request. In the IXFR server cannot fulfill the given delta-update request. In
some deployments, in particular where multiple IXFR servers are some deployments, in particular where multiple IXFR servers are
available to the IXFR client, this can lead to premature fallback to available to the IXFR client, this can lead to premature fallback to
AXFR-like behavior whenever the chosen IXFR server does not have the AXFR-like behavior whenever the chosen IXFR server does not have the
wanted delta-update information available, but another possible IXFR wanted delta-update information available, but another possible IXFR
server would, which incurs the additional overhead that the client server would, which incurs the additional overhead that the client
wanted to avoid whenever possible by his initial choice to use IXFR. wanted to avoid whenever possible by his initial choice to use IXFR.
This gap is closed by a variant of the IXFR mechanism, dubbed This gap is closed by a variant of the IXFR mechanism, dubbed
"IXFR-ONLY", which originally has been proposed in "IXFR-ONLY to "IXFR-ONLY", which originally has been proposed in "IXFR-ONLY to
skipping to change at page 5, line 28 skipping to change at page 5, line 41
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, "Key words for document are to be interpreted as described in BCP 14, "Key words for
use in RFCs to Indicate Requirement Levels" [RFC2119]. use in RFCs to Indicate Requirement Levels" [RFC2119].
1.4. Terminology 1.4. Terminology
This document makes freely use of basic DNS terminology as introduced This document freely makes use of basic DNS terminology as introduced
in RFCs 1034 and 1035 ([RFC1034], [RFC1035]) and clarified and in RFCs 1034 and 1035 ([RFC1034], [RFC1035]) and clarified and
expanded upon in RFCs 2181 and 4033 ([RFC2181], [RFC4033]). expanded upon in RFCs 2181 and 4033 ([RFC2181], [RFC4033]).
The terms "AXFR server", "AXFR client", "AXFR session", "General- The terms "AXFR server", "AXFR client", "AXFR session", "General-
purpose DNS implementation" and "Turnkey DNS implementation" are used purpose DNS implementation" and "Turnkey DNS implementation" are used
as defined in Section 1.1 of RFC 5936 [RFC5936]. as defined in Section 1.1 of RFC 5936 [RFC5936]. This document also
adopts the typographical (letter case) conventions agreed upon there
for denoting fields/parts of DNS messages -- cf. Section 3.
The bare term "IXFR" is intended to refer to the generic case of an 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 IXFR or IXFR-ONLY query/response, unless it is clear from the context
that the original IXFR is dealt with specifically. that the original IXFR Q-Type is dealt with specifically.
An "IXFR client" is a (secondary) name server for a given DNS zone 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, that, based on a trigger event, for instance a DNS NOTIFY message,
issues an IXFR query to a "superordinate" authoritative server (e.g., issues an IXFR query to a "superordinate" authoritative server (e.g.,
the primary server of the zone) and receives the IXFR response from the primary server of the zone) and receives the IXFR response from
it. it.
An "IXFR server" is an authoritative server that is presumed to An "IXFR server" is an authoritative server that is presumed to
become aware of changes to a zone earlier than other authoritiative become aware of changes to a zone earlier than other authoritiative
servers, for instance the primary server for a zone as specified in servers, for instance the primary server for a zone as specified in
skipping to change at page 6, line 13 skipping to change at page 6, line 29
primary server, and that is configured to respond to IXFR queries. primary server, and that is configured to respond to IXFR queries.
The interaction and protocol exchange(s) performed by an IXFR client The interaction and protocol exchange(s) performed by an IXFR client
and an IXFR server to issue an IXFR query and accomplish its and an IXFR server to issue an IXFR query and accomplish its
processing are collectively denoted as an "IXFR session". processing are collectively denoted as an "IXFR session".
The behavior of an IXFR server falling back to full zone transfer The behavior of an IXFR server falling back to full zone transfer
when incremental updates are unavailable or unpractical is denoted when incremental updates are unavailable or unpractical is denoted
(by common colloquial shorthand) as "Fallback to AXFR", although (by common colloquial shorthand) as "Fallback to AXFR", although
technically, no AXFR pseudo-RRs are involved in this protocol technically, no AXFR pseudo-RRs are involved in this protocol
variant. (This is sketched in Section 2 and detailed in Section 4 variant. (This is sketched in Section 2 and detailed in Section 4.)
below.)
1.5. Scope 1.5. Scope
In general terms, authoritative name servers for a given zone can use In general terms, authoritative name servers for a given zone can use
various means to achieve coherency of the zone contents they serve. various means to achieve coherency of the zone contents they serve.
For example, there are DNS implementations that assemble answers from For example, there are DNS implementations that assemble answers from
data stored in relational databases (as opposed to master files), data stored in relational databases (as opposed to master files),
relying on the database's non-DNS means to synchronize the database relying on the database's non-DNS means to synchronize the database
instances. Some of these non-DNS solutions interoperate in some instances. Some of these non-DNS solutions interoperate in some
fashion. However, AXFR, IXFR, and NOTIFY are the only protocol- fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-
skipping to change at page 6, line 39 skipping to change at page 7, line 5
applications of the DNS in which servers for a zone are designed to applications of the DNS in which servers for a zone are designed to
be incoherent. For these configurations, a coherency mechanism as be incoherent. For these configurations, a coherency mechanism as
described here would be unsuitable. described here would be unsuitable.
IXFR is an optional protocol component for authoritiative DNS IXFR is an optional protocol component for authoritiative DNS
servers; it is not needed on DNS resolver software that does not servers; it is not needed on DNS resolver software that does not
support the functions of an authoritative DNS server. Thus, all support the functions of an authoritative DNS server. Thus, all
usage of normative BCP 14 [RFC2119] language is applicable only to usage of normative BCP 14 [RFC2119] language is applicable only to
DNS server implementations that claim support of this specification. DNS server implementations that claim support of this specification.
Whereas the original IXFR already is widely implemented, IXFR-ONLY Whereas the original IXFR protocol already is widely implemented,
offers an operational choice for administrators of zones with a non- IXFR-ONLY offers an operational choice for administrators of zones
trivial propagation graph for the authoritative zone data, who are with a non-trivial propagation graph for the authoritative zone data,
looking for more options to fine-tune the synchronization efficiency who are looking for more options to fine-tune the synchronization
of their authoritative servers. It could be implemented without bare efficiency of their authoritative servers. It could be implemented
IXFR, but for the sake of backwards compatibility and flexibility, without bare IXFR, but for the sake of backwards compatibility and
and for simplicity in documentation, it is strongly RECOMMENDED that flexibility, and for simplicity in documentation, it is strongly
IXFR-ONLY be always implemented in concert with bare IXFR. RECOMMENDED that IXFR-ONLY be always implemented in concert with bare
IXFR.
2. Principles of IXFR Protocol Operation 2. Principles of IXFR Protocol Operation
Each version of the authoritative data of a DNS zone is identified by Each version of the authoritative data of a DNS zone is identified by
the SOA serial number (cf. Section 3.3.13 of [RFC1035]); succesive the SOA serial number (cf. Section 4.3.5 of [RFC1034] and Section
versions are tagged with monotonically increasing serial numbers. 3.3.13 of [RFC1035]); successive zone versions are tagged with
monotonically increasing serial numbers. Note that, as spelled out
Below, serial numbers are symbolically referred to by "sn". mostly at the former citation, "Serial number advances and comparisons use
with some distinguishing postfix. sequence space arithmetic", and IXFR implementations need to pay
particular attention to possible wraps. Below, serial numbers are
symbolically referred to by "sn", mostly with some distinguishing
postfix.
When an IXFR client currently serving, say, sn_o of a particular zone When an IXFR client currently serving, say, sn_o of a particular zone
receives a trigger that it should incrementally update the zone data, 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, 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 with the expectation to obtain in the IXFR response the change
information necessary to transform the sn_o zone data into the zone information necessary to transform the sn_o zone data into the zone
data of the current zone version, say, sn_n. data of the current zone version, say, sn_n.
The details of which triggers can and will start such IXFR session The details of which triggers can and will start such IXFR session
are implementation dependent. Possible triggers are some time are implementation dependent. Possible triggers are some time
skipping to change at page 8, line 22 skipping to change at page 8, line 41
might be preferable to coalesce subsequent chunks of change might be preferable to coalesce subsequent chunks of change
information -- both for local storage and/or for transmission --, for information -- both for local storage and/or for transmission --, for
instance instead of the change information from sn_1 to sn_2 and the 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_2 to sn_3 (where sn_1 < sn_2 < sn_3), the
change information from sn_1 to sn_3 can be provided. This change information from sn_1 to sn_3 can be provided. This
condensation of data has some downsides, however: if an IXFR client 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 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 current version of the zone, but the server has performed the above
condensation, it has no way to tell the necessary information to the condensation, it has no way to tell the necessary information to the
IXFR client, and the IXFR request necessarily is doomed to fail. IXFR client, and the IXFR request necessarily is doomed to fail.
Therefore, is becomes apparent that an IXFR server must maintain Therefore, it becomes apparent that an IXFR server must maintain
seemless chains of change information chunks from all past SOA serial seemless chains of change information chunks from all past SOA serial
number values it wants/needs to support (because potential IXFR number values it wants/needs to support (because potential IXFR
clients currently serve these zone versions) to the current zone clients currently serve these zone versions) to the current zone
version. See Section 6.3 for more details on Condensation. version. See Section 6.3 for more details on Condensation.
Upon receipt of any IXFR query, the IXFR server conceptionally Upon receipt of any IXFR query, the IXFR server conceptionally
constructs a chain of change information chunks from the SOA serial constructs a chain of change information chunks from the SOA serial
number indicated by the client (sn_o) to the current zone version number indicated by the client (sn_o) to the current zone version
(sn_n). (sn_n).
skipping to change at page 8, line 49 skipping to change at page 9, line 21
transfer. However, if the full zone content would fit into a single transfer. However, if the full zone content would fit into a single
response packet over UDP, an IXFR server MAY refrain from signalling response packet over UDP, an IXFR server MAY refrain from signalling
an error in response to an IXFR-ONLY query and behave as if the query an error in response to an IXFR-ONLY query and behave as if the query
had been IXFR. This is allowed because, in this case, the full IXFR had been IXFR. This is allowed because, in this case, the full IXFR
transaction can be executed in a single packet exchange and an error transaction can be executed in a single packet exchange and an error
return would necessitate more messages and hence cause additional return would necessitate more messages and hence cause additional
overhead and delay, contrary to the performance optimization goal of overhead and delay, contrary to the performance optimization goal of
IXFR-ONLY. IXFR-ONLY.
In case it turns out that the IXFR client already has the current 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 zone version (sn_o = sn_n) or even a more recent one (sn_o > sn_n),
empty chain of chunks, but with the (current) SOA record of the zone. the IXFR server does not reply with an empty chain of chunks, but
with only the (current) SOA record of the zone.
If the IXFR server determines that it would be inefficient to 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 the series of chunks, it also may fall back to full zone
transfer. Note that this is recommended behavior for the IXFR transfer. Note that this is recommended behavior for the IXFR
server, but the correct protocol operation does not depend on this server, but the correct protocol operation does not depend on this
(useful) optimization. (useful) optimization.
Ordinarily, in the generic case, the IXFR server transmits the change Ordinarily, in the generic case, the IXFR server transmits the change
information chunks in their "natural" order (by ascending sn) to the information chunks in their "natural" order (by ascending sn) to the
IXFR client. IXFR client.
Each such change information chunk -- say from sn_a to sn_b -- is Each such change information chunk -- say from sn_a to sn_b -- is
represented (conceptionally and on the wire) by a sequence of RR represented (conceptionally and on the wire) by a sequence of RR
deletions and a sequence of subsequent RR additions, all of which 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 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 the zone content at sn_b. For transfer in the IXFR response, each
sequence starts with the corresponding SOA RR as its delimiter, and sequence starts with the corresponding SOA RR as its delimiter, and
the other RRs within it can be given in arbitrary order. the other RRs within it can be given in arbitrary order.
The whole chain of change information chunks is embedded in a pair of 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 copies of the new SOA RR (at sn_n), which serve as "sentinels". It
important to point out that the SOA RR is used only as a marker in is important to point out that the SOA RR is used only as a marker in
this context and it can appear multiple times, as opposed to an this context and it can appear multiple times, as opposed to an
RRSIG(SOA) RR, which is treated as a common record and needs to RRSIG(SOA) RR, which is treated as a common record and needs to
appear only once in the zone. That also means that an RRSIG(SOA) RR appear only once in the zone. That also means that an RRSIG(SOA) RR
for sn_o has to be deleted and an RRSIG(SOA) RR for sn_n has to be for sn_o has to be deleted and an RRSIG(SOA) RR for sn_n has to be
added. In other words, any RRSIG(SOA) doesn't get any special added. In other words, any RRSIG(SOA) doesn't get any special
treatment in the context of IXFR, and SOA RRs are used as treatment in the context of IXFR, and SOA RRs are used as
"sentinels". "sentinels".
For example, if the IXFR server wants to transmit the changes from 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 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 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 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 sn_2, and the chunk from sn_2 to sn_n, it would deliver in the
response packet(s) the following resource records (RRs), in order: incremental IXFR response packet(s) the following resource records
(RRs), in order:
* SOA for sn_n # outer bracket * SOA for sn_n # outer bracket
* SOA for sn_o # start of first chunk * SOA for sn_o # start of first chunk
* {other RRs to be deleted from the zone at sn_o} * {0 or more other RRs to be deleted from the zone at sn_o}
* SOA for sn_1 * SOA for sn_1
* {other RRs to be added for getting the zone at sn_1} * {0 or more other RRs to be added for getting the zone at sn_1}
* SOA for sn_1 # start of second chunk * SOA for sn_1 # start of second chunk
* {other RRs to be deleted from the zone at sn_1} * {0 or more other RRs to be deleted from the zone at sn_1}
* SOA for sn_2 * SOA for sn_2
* {other RRs to be added for getting the zone at sn_2} * {0 or more other RRs to be added for getting the zone at sn_2}
* SOA for sn_2 # start of third chunk * SOA for sn_2 # start of third chunk
* {other RRs to be deleted from the zone at sn_2} * {0 or more other RRs to be deleted from the zone at sn_2}
* SOA for sn_n * SOA for sn_n
* {other RRs to be added for getting the zone at sn_n} * {0 or more other RRs to be added for getting the zone at sn_n}
* SOA for sn_n # outer bracket * SOA for sn_n # outer bracket
In contrast, in the case of fallback to AXFR, the IXFR response would In contrast, in the case of fallback to AXFR, the IXFR response would
convey, in order: convey, in order:
* SOA for sn_n # first instance * SOA for sn_n # first instance
* {DNSSEC signature RRs for the SOA, if any} * {one or more other RRs of the zone at sn_n, in arbitrary order}
* {other RRsets of the zone at sn_n, in arbitrary order}
* SOA for sn_n # repeated as trailing delimiter * SOA for sn_n # repeated as trailing delimiter
3. IXFR Messages 3. IXFR Messages
This section specifies the format of IXFR messages and the basic This section specifies the format of IXFR messages and the basic
message generation and processing rules. message generation and processing rules.
An IXFR session is started with an IXFR query message sent from an 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 IXFR client to an IXFR server, which solicits one or more response
messages in return. messages in return.
All these messages adhere to the basic DNS message format as All these messages adhere to the basic DNS message format as
specified in RFC 1035 and later amended in various ways, for which specified in RFC 1035 and later amended in various ways, for which
Section 2 of RFC 5936 gives an expanded bibliography. Implementers Section 2 of RFC 5936 gives an expanded bibliography. Implementers
should be aware of the considerations in "Measures for Making DNS should be aware of the considerations in RFC 5452, "Measures for
More Resilient against Forged Answers" [RFC5452] and follow the Making DNS More Resilient against Forged Answers" [RFC5452], and
recommendations given there. follow the recommendations given there.
For convenience of the reader, the synopsis of the DNS message header For convenience of the reader, the synopsis of the DNS message header
from RFC 6195 [RFC6195] (and the IANA registry for DNS Parameters from RFC 6195 [RFC6195] (and the IANA registry for DNS Parameters
[DNSVALS]) is reproduced here informally: [DNSVALS]) is reproduced here informally:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
skipping to change at page 13, line 34 skipping to change at page 13, line 34
An IXFR server that has received an IXFR query responds to it with an An IXFR server that has received an IXFR query responds to it with an
IXFR response addressed to the transport source identifier from which IXFR response addressed to the transport source identifier from which
the query has been received, in particular using the same transport the query has been received, in particular using the same transport
protocol. protocol.
An IXFR response consists of one or more response messages. If the An IXFR response consists of one or more response messages. If the
IXFR query has been received over a connectionless transport IXFR query has been received over a connectionless transport
(currently: UDP), the IXFR response MUST consist of a single message. (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 If it is not possible to send the complete response in a single DNS
message, a response MUST BE sent that only contains the currrent SOA message, a response MUST be sent that only contains the currrent SOA
RR at the server; whose serial sn_n being different from sn_o is the RR at the server; whose serial sn_n being larger than sn_o (in
signal to the IXFR client to retry over connection-oriented transport sequence space arithmetics) is the signal to the IXFR client to retry
(currently: TCP). over connection-oriented transport (currently: TCP).
The conceptional "answer" carried in a multi-message response is the The conceptional "answer" carried in a multi-message response is the
concatenation of the content of the Answer sections in these response concatenation of the content of the Answer sections in these response
messages, in the order they are sent; this is unambiguous from the messages, in the order they are sent; this is unambiguous from the
point of view of the IXFR client as well, since the applicable point of view of the IXFR client as well, since the applicable
connection-oriented transport preserves the order of messages sent. connection-oriented transport preserves the order of messages sent.
If the server detects an error condition that makes it impossible to If the server detects an error condition that makes it impossible to
fulfill the request, it immediately sends an error response, that is fulfill the request, it immediately sends an error response, that is
a response message with non-zero RCODE. In case of connectionless a response message with non-zero RCODE. In case of connectionless
transport (UDP), this is the single response message sent. In case transport (UDP), this is the single response message sent. In case
of connection-oriented transport (TCP), the error condition might of connection-oriented transport (TCP), the error condition might
occur after one of more response messages already have been sent; in occur after one or more response messages already have been sent; in
this case, the error message is sent as soon as need arises, and it 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 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 last response message sent by the server. The special case of a
server closing the TCP connection without sending an IXFR response server closing the TCP connection without sending an IXFR response
message is covered in Section 3.3. message is covered in Section 3.3.
If an IXFR server is not able or willing to send the incremental zone 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 change information to transform the client's version (sn_o) to its
newer version (sn_n), the behavior is specified as follows: In the newer version (sn_n), the behavior is specified as follows: In the
case of QTYPE=IXFR, the server SHOULD fall back to AXFR (see below). case of QTYPE=IXFR, the server SHOULD fall back to AXFR (see below).
In the case of QTYPE=IXFR-ONLY, it SHOULD respond with an appropriate In the case of QTYPE=IXFR-ONLY, it SHOULD respond with an appropriate
error, e.g., CannotIXFR (see below); however, in the (rather error, e.g., CannotIXFR (see below); however, in the (rather
unlikely) corner case where a full zone transfer can be sent in a unlikely) corner case where a full zone transfer can be sent in a
single response packet over connectionless transport (UDP), the IXFR single response packet over connectionless transport (UDP), the IXFR
server MAY instead proceed to send this even in response to an server MAY instead proceed to send this even in response to an
IXFR-ONLY query; doing so helps to achieve the overall performance IXFR-ONLY query; doing so helps to achieve the overall performance
optimization goals of IXFR-ONLY. optimization goals of IXFR-ONLY.
Any non-error IXFR response starts with the server's version of the Any IXFR response that is neither an immediate error response nor a
SOA resource record, sn_n. redirection to connection-oriented transport starts with the server's
If the server detects that the client's version is current (sn_n = version of the SOA resource record, sn_n, and its kind can be
sn_o), or if the server detects that the entire response to an IXFR determined from the second answer RR, if any. (See Sections 3.2.3
query received over connectionless transport (UDP) cannot be placed and 4 for a detailed discussion.)
into a single response message, this SOA record is the only answer RR If the server detects that the client's version is current (sn_o =
sent to the client. Otherwise, the subsequent answer RRs sent form a sn_n) or already is more recent than at the server (sn_o > sn_n), 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 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 in Section 4, and the final "sentinel" RR sent is another copy of the
current SOA RR. current SOA RR (sn_n).
In case of fallback to AXFR, the answer contains the same RRs (and is 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 subject to the same ordering rules) as specified in Sections 2.2
through 3 of RFC 5936, with the single difference being the echoed through 3 of RFC 5936, with the single difference being the echoed
QCODE (i.e., IXFR) in the Question section. QCODE (i.e., IXFR, or exceptionally -- as noted above -- IXFR-ONLY)
in the Question section.
3.2.1. Header Values 3.2.1. Header Values
The specification for AXFR in Section 2.2.1 of RFC 5936 applies 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" 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 behavior from RFC 5936 is always followed, i.e. the query ID from the
IXFR query MUST be echoed in all IXFR response messages. IXFR query MUST be echoed in all IXFR response messages.
Note that unlike with all common DNS responses, but like AXFR, the Note that unlike with all common DNS responses, but like AXFR, the
IXFR protocol makes no use of the TC (truncation) bit. To signal 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 that an IXFR session needs to be retried over TCP, an IXFR server
sends a response that in the Answer section solely contains its sends a response that in the Answer section solely contains its
current version of the SOA RR for the zone. current version of the SOA RR for the zone.
The only additonal rule to be followed applies to the deliberations 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 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 -- IXFR server is not able to fulfill an IXFR-ONLY request, it SHOULD
see above for the exceptional corner case -- respond with the respond with the extended RCODE CannotIXFR assigned on behalf of this
extended RCODE CannotIXFR assigned on behalf of this document (see document (see Section 10); see above for the exceptional corner case
Section 10). that allows to waive this requirement.
Note that only the lower 4 bits of the conceptual RCODE can be Note that only the lower 4 bits of the conceptual RCODE can be
carried in the RCODE message header field; the upper bits need to carried in the RCODE message header field; the upper bits need to
be placed into the EXTENDED-RCODE subfield of the "TTL" field in be placed into the EXTENDED-RCODE subfield of the "TTL" field in
the OPT RR that, in this case, is REQUIRED in the Additional the OPT RR that, in this case, is REQUIRED in the Additional
section of the response -- see Section 6.1.3 of RFC 2671bis section of the response -- see Section 6.1.3 of RFC 2671bis
[I-D.ietf-dnsext-rfc2671bis-edns0]. [I-D.ietf-dnsext-rfc2671bis-edns0].
3.2.2. Question Section 3.2.2. Question Section
skipping to change at page 15, line 29 skipping to change at page 15, line 34
empty. However, if the last response message sent is an error empty. However, if the last response message sent is an error
message (RCODE unequal to 0), the query MUST also be copied. message (RCODE unequal to 0), the query MUST also be copied.
Accordingly, QDCOUNT in the DNS message header is set to either 1 Accordingly, QDCOUNT in the DNS message header is set to either 1
(query copied) or 0 (otherwise). (query copied) or 0 (otherwise).
When it is present, the content of this section MAY be used to 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 determine the context of the message, that is, the name of the zone
being transferred. The recipent (IXFR client) SHOULD apply the being transferred. The recipent (IXFR client) SHOULD apply the
response verification rules from RFC 5452 [RFC5452]. response verification rules from RFC 5452 [RFC5452].
Subsequent response messages with empty Question section are
demultiplexed (among all open DNS transactions being carried out on a
given transport connection, which already identifies the peer) to the
proper IXFR session by means of the ID message header field only.
3.2.3. Answer Section 3.2.3. Answer Section
The Answer section MUST be populated with the zone change information The Answer section MUST be populated with the zone change information
or, in the case of fallback to AXFR, the full zone contents. or, in the case of fallback to AXFR, the full zone contents.
For multi-message IXFR responses, the conceptional answer is split For multi-message IXFR responses, the conceptional answer is split
into segments that are sent in order. Each segment is comprised of into segments that are sent in order. Each segment is comprised of
an integer number of full RRs, and for transport efficiency, the an integer number of full RRs, and for transport efficiency, the
response messages should be filled up with answer RRs as much as response messages SHOULD be filled up with answer RRs as much as
possible for the response message size chosen by the IXFR server, possible for the response message size chosen by the IXFR server,
taking into account the space needed for the other sections in the taking into account the space needed for the other sections in the
messages. messages.
See Section 4 below for the normative details of the resource record If an IXFR server intends to send a conceptual IXFR response that is
ordering requirements. comprised of at least two answer RRs, the first two answe RRs of the
response MUST be sent in the first response packet to allow the IXFR
client to immediately distinguish the kind of response coming in. An
IXFR server MUST NOT send over connection-oriented transport the kind
of (single-RR) IXFR response that indicates that the server has to
send a multi-packet response and hence the IXFR request needs to be
retried over connection-orientend transport (currently: TCP); this
kind of response is only allowed in response to an IXFR query
received over connectionless transport (currently: UDP).
See Section 4 below for the normative details of the various kinds of
conceptual IXFR responses and the respective resource record ordering
requirements, as well as how an IXFR client distinguishes these
response kinds.
3.2.4. Authority Section 3.2.4. Authority Section
Corresponding to NSCOUNT=0 in the DNS message header, the Authority Corresponding to NSCOUNT=0 in the DNS message header, the Authority
section in IXFR response messages MUST be empty. section in IXFR response messages MUST be empty.
3.2.5. Additional Section 3.2.5. Additional Section
All considerations from Section 2.2.5 (and hence, by reference, also 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 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. do for AXFR. See also Section 3.1.5 of this document.
Note that hereby the rules for any DNS transactional security
meta-RRs (SIG(0)/TSIG) applicable for AXFR are implicitly extended
to apply to multi-message IXFR responses as well; in the absence
of explicit specification saying otherwise, this also holds for
future DNS transactional security methods (if any).
3.3. Connection Aborts 3.3. Connection Aborts
In case of an IXFR session carried over connection-oriented transport In case of an IXFR session carried over connection-oriented transport
(TCP), the considerations in Section 2.3 of RFC 5936 [RFC5936] apply (TCP), the considerations in Section 2.3 of RFC 5936 [RFC5936] apply
similarly. similarly.
In a nutshell: Servers SHOULD avoid dropping active connections In a nutshell: Servers SHOULD avoid dropping active connections
whenever possible, and clients nevertheless must be prepared to whenever possible, and clients nevertheless must be prepared to
gracefully deal with such aborts. gracefully deal with such aborts.
4. Response Contents 4. Response Contents
This section describes the structure of the sequence of resource This section describes the structure of the sequence of resource
records (RRs) sent in IXFR reponses and how the IXFR client can records (RRs) sent in IXFR reponses and how the IXFR client can
distinguish the various cases covered. immediately distinguish the various cases covered.
The possible IXFR responses can be classified into various kinds of
responses by the number of answer RRs in the conceptual response.
(1) immediate-error: empty answer, non-zero RCODE;
(2) you-are-current: single SOA RR for sn_o = sn_n, RCODE = NoError;
(3) you-are-more-recent: single SOA RR for sn_o > sn_n, RCODE =
NoError;
(4) redirect-to-conn: single SOA RR for sn_o < sn_n, RCODE =
NoError;
(5) incremental: multiple RRs, starting and ending with the SOA RR
for sn_n (where sn_o < sn_n), which enclose a sequence of one
or more change information chunks, the first of which starts
with the SOA RR for sn_o (which consequentially is different
from sn_n);
this is detailed below in Section 4.1
(if need arises, a packetized incremental response can be
aborted in the second or later response message by sending an
empty Answer section and non-zero RCODE);
(6) full-xfr: multiple RRs, starting and ending with the SOA RR for
sn_n (where sn_o < sn_n), enclosing a serialization of all
other RRs in the zone for sn_n; this enclosed sequence of RRs
is non-empty -- since any zone needs to contain at least one
non-SOA RR, namely an NS RR --, does not contain any other SOA
RR, and thus cannot start with another SOA RR;
this is detailed in [RFC5936]
(if need arises, a packetized full-xfr response can be aborted
in the second or later response message by sending an empty
Answer section and non-zero RCODE).
If the IXFR server discovers an error condition before it sends the If the IXFR server discovers an error condition before it sends the
first (or only) response message, the response content in the Answer first (or only) response message, the response content in the Answer
section is empty, and consequentially, ANCOUNT is set to 0 in that section is empty, and consequentially, ANCOUNT is set to 0 in that
message. message ("immediate-error" response, kind (1) above).
Otherwise, the response content starts with a copy of the current SOA Otherwise, the response content starts with a copy of the current SOA
RR at the IXFR server (sn_n). There are several cases: RR at the IXFR server (sn_n). There are several cases:
a. The server serial (sn_n) is the same as the client serial (sn_o) a. The server serial (sn_n) is the same as the client serial (sn_o)
sent in the Authority section of the IXFR query. In this case, sent in the Authority section of the IXFR query. In this case,
this SOA RR is the only RR in the response message, indicating to this SOA RR is the only RR in the response message, indicating to
the IXFR client that it already has the current zone content. the IXFR client that it already has the current zone content
("you-are-current" response, kind (2) above).
b. The server serial (sn_n) differs from the client serial (sn_o) b. The server serial (sn_n) is older than the client serial (sn_o)
sent in the Authority section of the IXFR query, and this SOA RR
is the only RR in the response message. This indicates that the
zone content held at the IXFR server actually lags behind the
IXFR client, and so the IXFR server cannot provide an update to
the zone data at the client ("you-are-more-recent" response, kind
(3) above).
c. The server serial (sn_n) is newer than the client serial (sn_o)
sent in the Authority section of the IXFR query, and this SOA RR sent in the Authority section of the IXFR query, and this SOA RR
is the only RR in the response message. This indicates to the is the only RR in the response message. This indicates to the
IXFR client that its zone content is outdated and the IXFR server IXFR client that its zone content is outdated and the IXFR server
is willing to send the incremental zone change information, but is willing to send the incremental zone change information, but
is unable to do so in a single response message due to message is unable to do so in a single response message due to message
size limitations. size limitations.
An IXFR server MUST NOT send this type of IXFR response over An IXFR server MUST NOT send this type of IXFR response over
connection-oriented transport (TCP), but it MAY use this type of connection-oriented transport (TCP), but it MAY use this type of
response over connectionless transport (UDP). response over connectionless transport (UDP) to indicate to the
IXFR client that it should retry the IXFR query over connection-
oriented transport ("redirect-to-conn" response, kind (4) above).
An IXFR client that receives over connection-oriented transport An IXFR client that receives over connection-oriented transport
an IXFR response message (as the first response message related an IXFR response message (as the first response message related
to its IXFR query) that contains only a single SOA RR with sn_n to its IXFR query) that contains only a single SOA RR with sn_n
unequal to sn_o MUST discard the response message (see below). higher than sn_o MUST discard the response message (see below).
Note again that the "truncated response message" mechanism Note again that the "truncated response message" mechanism
specified in RFC 1035, which is signalled by setting the TC bit specified in RFC 1035, which is signalled by setting the TC bit
in a response message, MUST NOT be used in an IXFR response. An in a response message, MUST NOT be used in an IXFR response. An
IXFR client that receives an IXFR response message with the TC IXFR client that receives an IXFR response message with the TC
bit set MUST discard the message (see below for details). bit set MUST discard the message (see below for details).
c. The server serial (sn_n) differs from the client serial (sn_o) d. The server serial (sn_n) is newer than the client serial (sn_o)
sent in the Authority section of the IXFR query, and this SOA RR sent in the Authority section of the IXFR query, and this SOA RR
is followed by another SOA RR in the same response message. In is followed by another SOA RR in the same response message. In
this case, the IXFR response is an incremental response. this case, the IXFR response is an incremental response (kind (5)
above), as detailed in Section 4.1 below.
If this second SOA RR also carries sn_n, the IXFR client SHOULD If this second SOA RR also is for sn_n, a robust IXFR client will
assume that the server exposes behavior arguably not explicitly assume that the server exposes behavior arguably not explicitly
forbidden in RFC 1995 to signal case a) above; an IXFR client forbidden in RFC 1995 to signal case (a) above. Hence, an IXFR
SHOULD accept for resiliency an IXFR response with exactly these client MAY accept for resiliency an IXFR response with exactly
two copies of the same SOA RR sent in a single response message these two copies of the same SOA RR sent in a single response
as an "empty incremental response" indicating that the client's message as an "empty incremental response" indicating that the
version of the zone is current. Otherwise, the client MUST client's version of the zone is current; otherwise, the client
discard a response starting with two copies of the sn_n SOA RR. MUST discard a response starting with two copies of the sn_n SOA
RR.
Otherwise, if the second SOA RR carries sn_o, this indicates the Otherwise, if the second SOA RR is for sn_o, this indicates the
start of an ordinary incremental response as detailed below. start of an ordinary incremental response as detailed below.
Otherwise (if the second SOA RR carries sn_x that differs from Otherwise (if the second SOA RR is for sn_x that differs from
both sn_o (as sent by the client) and sn_n (in the first SOA RR), both sn_o (as sent by the client) and sn_n (in the first SOA RR),
the client MUST discard the response message as bogus. the client MUST discard the response message as bogus.
d. The server serial (sn_n) is not the same as the client serial e. The server serial (sn_n) is newer than the client serial (sn_o)
(sn_o) sent in the Authority section of the IXFR query, and this sent in the Authority section of the IXFR query, and this SOA RR
SOA RR is followed by another, non-SOA RR in the same response is followed by another, non-SOA RR in the same response message.
message.
This indicates a non-incremental response, "fallback to AXFR". This indicates a non-incremental response ("full-xfr" response,
In this case, the response content is structured like an AXFR kind (6) above, colloquially "fallback to AXFR"). In this case,
response, as described in RFC 5936 ("new" behavior, no backward the response content is structured like an AXFR response, as
compatibility kludges admitted); it contains the entire zone described in RFC 5936 ("new" behavior, no backward compatibility
content -- preferably with whole RRsets grouped together -- and kludges admitted); following the initial SOA RR it contains the
ends with a second copy of the sn_n SOA RR as an end-of-response entire zone content besides the SOA RR and ends with a second
marker. copy of the sn_n SOA RR as an end-of-response marker.
A non-incremental IXFR response MUST NOT be sent in response to Such non-incremental IXFR response MUST NOT be sent in response
an IXFR-ONLY query unless the entire intended IXFR response -- up to an IXFR-ONLY query unless the entire intended response -- up
to and including the trailing sentinel sn_n SOA RR -- fits into a to and including the trailing sentinel sn_n SOA RR -- fits into a
single response message with a size that allows it to be sent single response message with a size that allows it to be sent
over connectionless transport (UDP), or would have allowed that over connectionless transport (UDP), or would have allowed that
if it actually is carried over connection-oriented transport if it actually is carried over connection-oriented transport
(TCP). An IXFR client that receives an incomplete initial IXFR (TCP). An IXFR client that receives an incomplete initial IXFR
response message that indicates such non-incremental response to response message that indicates such non-incremental response to
an IXFR-ONLY query MUST discard the message as bogus. an IXFR-ONLY query MUST discard the message as bogus.
An IXFR client MUST discard any IXFR response that does not match one
of the forms described as kinds (1) through (6) above and is not
recognized by the above decision tree.
Whenever in the above cases the text says that the IXFR client "MUST Whenever in the above cases the text says that the IXFR client "MUST
discard the message", the following behavior is implied: The IXFR discard the message", the following behavior is implied: The IXFR
client MUST regard the IXFR session as terminated; this results in client MUST regard the IXFR session as terminated; this results in
subsequent silent discarding of further response messages that still subsequent silent discarding of further response messages that still
pretend to belong to the same IXFR session by means of the query ID 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 and the echoed Question (if present), because the IXFR client does
not maintain corresponding IXFR query/session state any more. The not maintain corresponding IXFR query/session state any more. The
IXFR client MAY log the event and SHOULD regard the IXFR server as IXFR client MAY log the event and SHOULD regard the IXFR server as
broken; hence, it SHOULD refrain from using the same IXFR server broken; hence, it SHOULD refrain from using the same IXFR server
again -- at least for considerable time, or until the usage has been again -- at least for considerable time, or until the usage has been
reinstated by an implementation-dependent management interaction. reinstated by an implementation-dependent management interaction.
From the above decision tree for the client it also follows that, to 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 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 response comprised of two or more RRs, it MUST send at least the
first two RRs in the first response message. first two RRs in the first response message, as specified in
Section 3.2.3 above.
If the IXFR server discovers an error condition lately, after having 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 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 abort the IXFR session by sending another response message with empty
Answer section and a non-zero RCODE. This MUST be the last message 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 sent in response to the IXFR query, that is, this error message
aborts the ongoing IXFR session. aborts the ongoing IXFR session.
The above rules ensure that an IXFR client can unambiguously
determine the kind of IXFR response from the first response message
alone. This encludes the ability to immediately detect the end of
any legitimate single-message IXFR response. An IXFR session with a
multi-message IXFR response ends when either
o a late error message arrives, i.e., a response message with non-
zero RCODE -- such message has an empty Answer section so that
there's no ambiguity as to which answer RRs might be regarded as
somehow valid anyhow (see Section 7.1 for the possible treatment
of RRs received previously in such IXFR session); or
o in the case of an incremental response, the third instance of the
SOA RR for sn_n is found in the answer (see Section 4.1 for the
rationale); or
o in the case of a non-incremental response, the second instance of
the SOA RR for sn_n is found in the answer.
Recall that in the second and third case, the SOA RR for sn_n was the
first RR sent in the first response message. If in these two cases,
the received response message contains more, extraneous RRs past that
sentinel SOA RR, an IXFR client MAY regard the entire response (or
the not yet committed part of the response, according to Section 7.1)
as bogus (see above); if the client accepts an otherwise consistent
response under these circumstances, it MUST discard the extraneous
RRs, and it MAY log the error and take 'discard' actions as above.
4.1. Incremental Responses 4.1. Incremental Responses
In an incremental response, the leading sn_n SOA RR is followed by 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 one or more change information chunks and concluded by a final copy
of the sn_n SOA RR. of the sn_n SOA RR -- in total, from the details given below, it
turns out that this is always exactly the third instance of that SOA
RR in the IXFR response.
Each change information chunk describes the changes to be performed Each change information chunk describes the changes to be performed
on a given "origin" version of the zone to obtain a "target" version 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 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 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 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 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 single RR is represented by an RR deletion followed by an RR
addition.) These two sets are sent in this order, with each set addition.) These two sets are sent in this order, with each set
serialized as a sequence of the related SOA RR followed by other, serialized as a sequence of the related SOA RR followed by other,
skipping to change at page 19, line 41 skipping to change at page 21, line 46
information chunk, and once in the first part of the immediately information chunk, and once in the first part of the immediately
following change information chunk. following change information chunk.
Any IXFR response classified as a (non-empty) incremental response by Any IXFR response classified as a (non-empty) incremental response by
the decision tree presented above in Section 4 that violates any of 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 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 bogus; it MUST discard a response message in case its content allows
the client to detect such violation, with the caveats for "discard" the client to detect such violation, with the caveats for "discard"
given in Section 4. 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.
5. Transport 5. Transport
IXFR servers and IXFR clients MUST support transport over UDP and TCP IXFR servers and IXFR clients MUST support transport over UDP and TCP
(see RFC 5966 [RFC5966]). As with all DNS transactions, IXFR (see RFC 5966 [RFC5966]). As with all DNS transactions, IXFR
responses MUST be sent on the same transport association over which responses MUST be sent on the same transport association over which
the query arrives at the server. the query arrives at the server.
If an IXFR server cannot send a full IXFR response for an IXFR query 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 received over UDP within a single response message over UDP due to
message size limitations, it MUST return the special form of response message size limitations, it MUST return the special form of response
skipping to change at page 20, line 32 skipping to change at page 22, line 32
authoritiative servers, and often not authorized for use by servers authoritiative servers, and often not authorized for use by servers
outside the set of authorities for a zone, which are all under the outside the set of authorities for a zone, which are all under the
control of a single administrative domain or a small number of control of a single administrative domain or a small number of
cooperating administrative domains. In this environment, it might cooperating administrative domains. In this environment, it might
make sense for the sake of efficiency to maintain (and reuse) make sense for the sake of efficiency to maintain (and reuse)
persistent TCP connections between the configured IXFR peers. persistent TCP connections between the configured IXFR peers.
Therefore, implementations of IXFR should allow to configure Therefore, implementations of IXFR should allow to configure
relatively high TCP User Timeout values and support the TCP UTO relatively high TCP User Timeout values and support the TCP UTO
mechanism ([RFC5482]) that allows the peers to exchange their view of mechanism ([RFC5482]) that allows the peers to exchange their view of
the TCP User Timeout and adapt the behavior of their TCP accordingly. the TCP User Timeout and adapt the behavior of their TCP accordingly.
To minimize unnecessary delays, IXFR server implementations SHOULD
use available API functions to cause their TCP stacks to immediately
dispatch for sending the first and last packet of any IXFR response
and cause these to be delivered immediately to the recipient; for
instance, immediate sending and setting of the 'PSH' TCP header flag
in outgoing packets can often be achieved using the TCP_NODELAY
socket option.
6. Server Behavior 6. Server Behavior
6.1. General 6.1. General
General considerations on IXFR server behavior, in particular General considerations on IXFR server behavior, in particular
response message generation and packet processing, are spread all response message generation and packet processing, are spread all
over this document; in particular, see Sections 3.2 and 4. over this document; in particular, see Sections 3.2 and 4.
In addition to the current zone content, IXFR servers need to In addition to the current zone content, IXFR servers need to
skipping to change at page 21, line 21 skipping to change at page 23, line 24
Information about older versions should be purged as soon as the Information about older versions should be purged as soon as the
total length of an IXFR response would otherwise become larger than total length of an IXFR response would otherwise become larger than
that of an AXFR response. Given that the purpose of IXFR is to that of an AXFR response. Given that the purpose of IXFR is to
reduce AXFR overhead, this strategy is quite reasonable. The reduce AXFR overhead, this strategy is quite reasonable. The
strategy assures that the amount of storage required is at most twice strategy assures that the amount of storage required is at most twice
that of the current zone information. that of the current zone information.
Information older than the SOA expire period may also be purged. Information older than the SOA expire period may also be purged.
Once the current serial number of a zone advances so far that older
serial numbers can no more be recognized immediately as older
versions (under the rules of sequence space arithmetics), such
previous versions MUST NOT be held available any more for IXFR
purposes. In order to account for the propagation delay along the
IXFR distribution graph, use of a reasonable safety margin against
this hard limit has proven to be a good strategy for defensive
implementation practice -- for instance implementations could limit
the maximum serial number span made available for IXFR to a specific
fraction of the 32-bit serial number range, e.g., one fourth (2^30).
The Condensation techniques explored below in Section 6.3 might pose The Condensation techniques explored below in Section 6.3 might pose
an opportunity to get rid of more recent, yet less relevant history 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 information and as such might allow to cover a larger span of SOA
versions than otherwise possible within the same amount of storage. versions than otherwise possible within the same amount of storage.
6.3. Optional Condensation of Zone Changes 6.3. Optional Condensation of Zone Changes
An IXFR server MAY optionally condense a number of immediately An IXFR server MAY optionally condense a number of immediately
succeeding change information chunks into a single chunk, thus succeeding change information chunks into a single chunk, thus
dropping information on intermediate zone versions. dropping information on intermediate zone versions.
skipping to change at page 22, line 29 skipping to change at page 24, line 45
Condensation is completely optional. Clients cannot detect from the Condensation is completely optional. Clients cannot detect from the
response whether or not the server has condensed the reply. response whether or not the server has condensed the reply.
For interoperability, IXFR servers, including those without the For interoperability, IXFR servers, including those without the
condensation feature, SHOULD NOT send an error response in case they condensation feature, SHOULD NOT send an error response in case they
receive a client's IXFR request with an unknown version number and receive a client's IXFR request with an unknown version number and
SHOULD, instead, attempt to perform a full zone transfer. Of course, SHOULD, instead, attempt to perform a full zone transfer. Of course,
this in general does not apply if the client indicates its desire to this in general does not apply if the client indicates its desire to
try its luck in such case at another candidate IXFR server, by try its luck in such case at another candidate IXFR server, by
initiating the request with IXFR-ONLY (the exception to the general initiating the request with IXFR-ONLY (the single exception to this
case is the corner case discussed in Section 3.2). general case is the corner case discussed in Section 3.2).
6.4. Authorization 6.4. Authorization
The considerations for AXFR presented in Section 5 of RFC 5936 The considerations for AXFR presented in Section 5 of RFC 5936
[RFC5936] apply in a similar fashion for IXFR. [RFC5936] apply in a similar fashion for IXFR.
Given the basic desire for frequent use and the resulting processing Given the basic desire for frequent use and the resulting processing
load, operational considerations will, even more likely than for load, operational considerations will, even more likely than for
AXFR, dictate the need to closely restrict the usage of IXFR to the AXFR, dictate the need to closely restrict the usage of IXFR to the
set of authoritiative servers for a given zone, and to precisely set of authoritiative servers for a given zone, and to precisely
skipping to change at page 23, line 25 skipping to change at page 25, line 39
IXFR-ONLY allow to configure its usage per IXFR server, as part of IXFR-ONLY allow to configure its usage per IXFR server, as part of
the IXFR distribution graph configuration. the IXFR distribution graph configuration.
An IXFR client SHOULD set an appropriate guard timeout whenever the An IXFR client SHOULD set an appropriate guard timeout whenever the
content of a response message indicates that this is not the final content of a response message indicates that this is not the final
message of an IXFR response. In case this timeout period elapses message of an IXFR response. In case this timeout period elapses
without another response message arriving, it SHOULD regard the IXFR without another response message arriving, it SHOULD regard the IXFR
session as failed and apply the caveats for the "discard" case session as failed and apply the caveats for the "discard" case
presented in Section 4. presented in Section 4.
If it is known to the IXFR client that an IXFR server conforms to the
refined IXFR specification in this RFC, the guard timeout can be
chosen rather large because the kind of IXFR response is
unambiguously indicated in the first response message and the timing
of the subsequent packet flow should be left to the connection-
oriented transport in use, and the timeout only serves as a "last
defense" in case of fatal failures not detected by the transport.
7.1. Zone Integrity 7.1. Zone Integrity
The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936 The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936
[RFC5936] apply in a similar fashion for IXFR. [RFC5936] apply in a similar fashion for IXFR.
However, during the receipt of an incremental IXFR response, and upon However, during the receipt of an incremental IXFR response, and upon
successful processing of an SOA RR that serves as a sentinel for the successful processing of an SOA RR that serves as a sentinel for the
end of any change information chunk, an IXFR client MAY immediately end of any change information chunk, an IXFR client MAY immediately
apply and commit to stable storage the SOA serial number change apply and commit to stable storage the SOA serial number change
described by that chunk (and previous chunks, if not already done). described by that chunk (and previous chunks, if not already done).
skipping to change at page 24, line 18 skipping to change at page 26, line 42
8. Backwards Compatibility 8. Backwards Compatibility
Despite a few potentially misleading statements in the previous Despite a few potentially misleading statements in the previous
specification, only a single detail has been identified so far that specification, only a single detail has been identified so far that
could give rise to backward compatibility concerns. This is could give rise to backward compatibility concerns. This is
addressed by the compatibility rules in Section 4 that allow an IXFR addressed by the compatibility rules in Section 4 that allow an IXFR
client to process an "empty incremental response" consisting of only client to process an "empty incremental response" consisting of only
a pair of instances of the server's SOA RR. a pair of instances of the server's SOA RR.
The clarified and slightly tightened packetization requirements
contained in Section 3.2.3 might cause an IXFR client to reject a
poorly packetized multi-packet response previously sometimes regarded
as acceptable under RFC 1995. An IXFR client implementation MAY
provide a configuration option (globally, or per IXFR server) to
admit such inefficient behavior on the server side, in which case it
needs to wait for a second response message before it can distinguish
unambiguously all response kinds (including protocol violations). In
deployment scenarios with multiple candidate IXFR servers where
expeditious switching to an alternate IXFR server (if needed) is
intended, activation of such option would be detrimental.
The introduction of IXFR-ONLY creates further interoperability The introduction of IXFR-ONLY creates further interoperability
considerations. An IXFR server utilizing IXFR-ONLY may receive an considerations. An IXFR server utilizing IXFR-ONLY may receive an
error response different from CannotIXFR persistently. (The actual error response different from CannotIXFR persistently. (The actual
RCODE reveived may depend on whether or not the server is aware of 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 the allocation of the range of RR types set aside for Q-Types in
[RFC6195] (and its predecessors), from which the IXFR-ONLY code point [RFC6195] (and its predecessors), from which the IXFR-ONLY code point
has been assigned.) This event likely indicates that the IXFR server has been assigned.) This event likely indicates that the IXFR server
chosen does not support IXFR-ONLY. In such case, the client will 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 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 another potential IXFR server, or, if all candidates fail, retry the
skipping to change at page 25, line 49 skipping to change at page 28, line 35
CannotIXFR: CannotIXFR:
RCODE Name Description Reference RCODE Name Description Reference
Decimal Decimal
--------- ---------- ---------------------------------- --------- --------- ---------- ---------------------------------- ---------
{TBD2} CannotIXFR IXFR not possible, would fall back [RFCthis] {TBD2} CannotIXFR IXFR not possible, would fall back [RFCthis]
11. Acknowledgements 11. Acknowledgements
Masataka Ohta is acknowledged for his original work as the author of Masataka Ohta is acknowledged for his original work as the author of
RFC 1995 [RFC1995], and this extends to the contributors listed in RFC 1995 [RFC1995], as are the contributors listed in the
the Acknowledgements section of that RFC. Acknowledgements section of that RFC. Andreas Gustafsson has
initiated the first attempt to clarify RFC 1995 in November 1999 and
contributed text to the DNSIND WG for a proposed document revision.
Masataka Ohta's subsequent draft [OLD-IXFRbis] has not been pursued
until RFC publication; thanks to Andreas for eventually bringing this
earlier work to the attention of the authors of this memo.
The specification of IXFR-ONLY in this document is based on the The specification of IXFR-ONLY in this document is based on the
original proposal [I-D.kerr-ixfr-only], whose authors are original proposal [I-D.kerr-ixfr-only], in which the operational need
acknowledged for identifying the operational need for this behavior for this behavior has been identified and carried into the IETF.
and carrying it to the IETF.
The DNSEXT working group and its predecessor (DNSIND) are The DNSEXT working group and its predecessor (DNSIND) are
acknowledged for their discussion on the above documents. acknowledged for their discussion on the above documents.
Substantial text has been borrowed from there and from [RFC5936]. Substantial text has been borrowed from there and from [RFC5936].
Discussions of the draft on the dnsext list have directed the Discussions of the draft on the dnsext list have directed the
evolution of this document; in particular, we acknowledge (in evolution of this document; in particular, we acknowledge (in
alphabetical order) Mark Andrews, Brian Dickson, Shane Kerr, Edward alphabetical order) Mark Andrews, Ray Bellis, Brian Dickson, Andreas
Lewis, Josh Littlefield, Masataka Ohta, Paul Vixie, and Wouter Gustafsson, Shane Kerr, Warren Kumari, Edward Lewis, Josh
Littlefield, Masataka Ohta, Paul Vixie, Florian Weimer, and Wouter
Wijngaards for their comments and reviews. Wijngaards for their comments and reviews.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dnsext-rfc2671bis-edns0] [I-D.ietf-dnsext-rfc2671bis-edns0]
Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08 for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08
(work in progress), February 2012. (work in progress), February 2012.
skipping to change at page 27, line 8 skipping to change at page 29, line 43
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, June 2010. (AXFR)", RFC 5936, June 2010.
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6195, March 2011. Considerations", BCP 42, RFC 6195, March 2011.
12.2. Informative References 12.2. Informative References
[DNSVALS] IANA Registry, "Domain Name System (DNS) Parameters", [DNSVALS] IANA Registry, "Domain Name System (DNS) Parameters",
protocol parameter registry available at:, January 2012, protocol parameter registry available at:,
<http://www.iana.org/assignments/dns-parameters>. <http://www.iana.org/assignments/dns-parameters>.
[I-D.kerr-ixfr-only] [I-D.kerr-ixfr-only]
Sury, O. and S. Kerr, "IXFR-ONLY to Prevent IXFR Fallback Sury, O. and S. Kerr, "IXFR-ONLY to Prevent IXFR Fallback
to AXFR", draft-kerr-ixfr-only-01 (work in progress), to AXFR", draft-kerr-ixfr-only-01 (work in progress),
February 2010. February 2010.
[OLD-IXFRbis]
Ohta, M., "Incremental Zone Transfer in DNS",
draft-ietf-dnsext-ixfr-01 (work in progress), June 2000.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996. August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
skipping to change at page 28, line 45 skipping to change at page 31, line 40
By providing IXFR-ONLY support, the policy control over the zone By providing IXFR-ONLY support, the policy control over the zone
synchronization operation switches to the client side, which is synchronization operation switches to the client side, which is
preferable under various operational settings. preferable under various operational settings.
Appendix B. Substantial Changes Since RFC 1995 Appendix B. Substantial Changes Since RFC 1995
This is a summary of the substantial changes since RFC 1995 This is a summary of the substantial changes since RFC 1995
[RFC1995]. [RFC1995].
o Corrected a few technical flaws: incorrect comparison with AXFR; o Corrected a few technical flaws: incorrect comparison with AXFR;
improper impled requirement of performing SOA query over UDP; improper implied requirement of performing SOA query over UDP;
improper reference to transfer of partial RRs in a response improper reference to transfer of partial RRs in a response
message corrected (to be read as transfer of partial RRsets in a message corrected (to be read as transfer of partial RRsets in a
response message -- as it has always been understood by response message -- as it has always been understood by
implementers, since STD 13 requires only entire RRs to be present implementers, since STD 13 requires only entire RRs to be present
in DNS messages). in DNS messages).
o New specification based on the revised AXFR specification, o New specification based on the revised AXFR specification,
RFC 5936 [RFC5936]. RFC 5936 [RFC5936].
o Slightly tightened packetization requirements for multi-packet
responses to ensure more timely client-side processing (immediate
determination of kind of response based upon first response
packet, faster determination of protocol violations).
o Many clarifications and details supplied, text vastly reorganized o Many clarifications and details supplied, text vastly reorganized
and expanded, but no (intentional) technical deviation from the and expanded, but no other (intentional) technical deviation from
previous specification, as understood by implementers. the previous specification, as understood by implementers.
o Addition of new IXFR-ONLY protocol variant, based on operational o Addition of new IXFR-ONLY protocol variant, based on operational
experience and perceived need. experience and perceived need.
o Major additions to Security Considerations. o Major additions to Security Considerations.
o Historical example dropped (incompatible with IESG policy on o Historical example dropped (incompatible with IESG policy on
examples). Instead, abstract examples have been added to examples). Instead, abstract examples have been added to
Section 2. Section 2.
Appendix C. Evaluation of List Discussion, Draft Changes since Appendix C. Change Log of WG Draft
Individual Draft -02
[[ Temporary Section, to be deleted in next draft version. ]]
On Chair request, draft-ah-dnsext-rfc1995bis-ixfr-03 re-posted as
draft-ietf-dnsext-rfc1995bis-ixfr-00 without textual changes, but
Shane Kerr now listed as an Author. Recent list dicussion will be
reflected in -01 version due soon after IETF 83. The paragraphs
below describe the changes in indiviual draft -02 to -03 and have
been kept unchanged for this initial WG draft version.
The previous (-02) version of this draft has been extensively
discussed on the dnsext mailing list during the June through August
2011 timeframe. Due to temporary unavailability of the primary
author, the concensus-building based on that discussion is summed up
below, instead of flooding the mailing list with a bunch of (very
belated) response messages. Messages are quoted below as
"{msgNNNNN}", based on the message numbers (NNNNN -- a 5-digit
number) assigned in the list archive using URIs following the pattern
<http://www.ietf.org/mail-archive/web/dnsext/current/msgNNNNN.html>.
{msg11353}, item 1: It is claimed frequently that IETF documents are
too "microscopic" in their perspective and do not give the "glue"
context information allowing even a non-specialized reader to see how
the specified functionality relates to other parts of protocols,
deployment, and common usage. Therefore, like in the kindred AXFR
document, RFC 5936, context information for the invocation of IXFR is
given in the draft -- btw, in a style that resembles descriptions
given in the basic DNS Standards, RFCs 1034 and 1035.
If zones don't change, and no NOTIFYs are sent, IXFR isn't needed.
As RFC 1996 (NOTIFY) indicates, NOTIFY was intended as the primary
trigger for IXFR requests, and that's what this draft re-states from
the perspective of IXFR.
Minor editorial changes have been performed.
{msg11353}, item 2, {msg11359} and more messages down the thread:
As has been pointed out by Brian D. (et al.) in {msg11354},
{msg11363} (and follow-up discussion), the term "Fallback to AXFR"
describes IXFR server behavior specified in RFC 1995 and present in
all major DNS server implementations.
Overall, substantial discussion apparently has been caused by
confusion about the (admittedly a bit colloquial) term "Fallback to
AXFR". Another thread on this behavior was started by Mark A.
({msg11373} ff.).
To clarify and resolve this issue, a definition for this term has
been added to Section 1.4.
The justification for clarifications to the present IXFR
specification and the need for interoperably specified IXFR-ONLY has
been reinforced by several contributors, e.g. Brian D., Mark A., and
Masataka O. ({msg11354}, {msg11355}, {msg11356}, {msg11365}, ff.).
We have not found any indications in the draft text where the
detailed specification of (classical) IXFR would contradict RFC 1995,
and it has been indicated on the list that the draft also correctly
reflects the on-the-wire IXFR behavior of all major implementations
represented by active participants on the list.
{msg11353}, final item: IMO, RFC 1995 would have deserved at least 3
Technical Errata and roughly a dozen Editorial Errata, and it lacks a
lot of precidion, so we agree that a refresh of this original
specification should be welcome.
The suggested additional test by DNSSEC-aware IXFR clients of the
RRSIG(SOA) RRset now is mentioned in a newly added paragraph of
Section 7.1 (that section is referred to in the Security
Considerations).
{msg11373}, {msg11374} and follow-ups: The draft already represents
in detail the different possible responses on an IXFR query that have
been inherent in RFC 1995.
If (and only if) the IXFR server can respond with a single DNS
response packet, the IXFR transaction can be carried out successfully
over UDP, and hence is a "single response mechanism". Otherwise, the
IXFR client has to be redirected to TCP, as described in (RFC 1995
and) the draft. This is independent of whether the IXFR server then
has to fall back to full-zone transfer.
There might be a (very unlikely) corner case, where the IXFR server
wants to fall back to full-zone transfer *and* this transfer can be
performed in a single response packet. Admittedly, that's rather
unlikely, and in this case, IXFR-ONLY behavior would be causing
additional overhead and message exchanges. Therefore, clauses has
been added to Section 2 and Section 3.2 that in this corner case, the
response to IXFR-ONLY MAY be a full-zone transfer over UDP, for the
sake of overall performance.
Otherwise, no significant changes to the text have been performed in
this respect.
{msg11376} ff.: Aborting an IXFR session over TCP likely does not
waste so much resources on the IXFR client side (which initiates the
premature closing of the TCP connection), but it takes much more time
for the IXFR server to be notified of this closure, and up to then,
it will have wasted resources to generate and buffer response packets
that will either never be received or not even sent. Further, if a
persistent TCP connection is desired, e.g. for an IXFR client that
regularly has to update numerous zones from the same (candidate) IXFR
server, re-establishment and subsequent TCP slow-start of a new TCP
connection will be actually detrimental to the overall zone update
performance.
This is another reason why IXFR-ONLY promises substantial performance
improvements that cannot be achieved without protocol enhancements.
Since only modern DNS implementations are expected to implement
IXFR-ONLY (which are expected to support EDNS anyway), because
extended message sizes are very useful for IXFR in general (which
also requires EDNS), and to reduce the pressure on the narrow basic
RCODE namespace (only 5 codepoints still available for assignment),
the draft now assumes that an extended RCODE value for CannotIXFR
will suffice. The running text and IANA Considerations have been
adjusted accordingly. Consequentially, the draft now specifies that
an IXFR-ONLY query without an OPT RR will be rejected by the IXFR
server with FormErr.
Paul V. ({msg13379}) pointed out the detriments of message sizes [[ Entire section to be deleted before publication as an RFC. ]]
above 16k (loss of ability to perform message compression).
Added Note to Section 3 explaining this hint.
A few adjustments regarding use of RFC 2119 language have been The changes of the individual draft (draft-ah-dnsext-rfc1995bis-ixfr)
performed. up to adoption as a WG draft (draft-ietf-dnsext-rfc1995bis-ixfr-00)
are detailed in Appendix C of the latter, but not reproduced below
any more.
Appendix B, which sums up the important changes since RFC 1995, has C.1. Draft Version 00 -> 01
been added, as needed per IESG policy.
References have been updated. o Removed text pertaining to individual draft stage.
o Several text adoptions based on evaluation of previous work in
DNSIND & DNSEXT (in 1999 & 2000) made available by Andreas
Gustafsson.
o Added more text to s1.2 regarding motivation for this memo.
o Added to s1.4 hint to spelling conventions for DNS message parts
(borrowed from RFC 5936); clarified there that IXFR is a Q-Type
RR.
o s2: Clarified preconditions on SOA serial numbers with quotes from
STD 13; s6.2: IXFR server now MUST NOT hold available via IXFR
zone versions that cannot clearly be recognized as older than the
current version; with regard to propagation delays, text
recommends safety margin: limit SOA serial span covered to e.g.
1/4 of the serial number space (i.e. 2^30).
o s2, s3.2, s4: Draft now accommodates the (hopefully rare) case of
the IXFR server's zone being older than the version that the
client has.
o s2, s4: Draft now strictly follows RFC 5936 RR ordering
requirements for non-incremental responses (i.e. no more
recommendation for grouping RRs into RRsets). Example in s2 now
also clearly indicates possibility of having zero "other" RRs to
be deleted or to be added in a change information chunk.
o Clarified which kinds of responses are covered by last para in
s3.2.
Numerous editorial changes and enhancements have been applied. o s3.2, s3.2.1: Resolved text that has become inconsistent by the
Vertical spacing tweeked to avoid dangling orphan lines at page introduction (per the last individual draft version) of the
breaks. (optional) exceptional single-packet non-incremental IXFR-ONLY
response.
o s3.2.2: Clarified that subsequent packets of multi-packet IXFR
responses with empty Question section are demultiplexed into the
appropriate IXFR session by only the DNS message header ID.
o s3.2.3: Based on feedback emphasizing the importance of rules that
ensure efficient protocol operation and thereby making the
requirements at least as strong as for AXFR, the requirements on
packetization of multi-packet IXFR responses have been clearly
spelled out and clarified, making the requirements comparable of
what is specified for AXFR in RFC 5936; previously, the slightly
tightened requirements were arguably hidden in other parts of the
text.
o s3.2.5: Added explicit note regarding DNS transactional security.
o s4: Added classification of IXFR response kinds. Updated decision
tree to refer to these kinds. Added discussion of end-of-session
detection for multi-packet IXFR responses.
o s4.1: Dropped last para -- new packetization requirements now are
limited to what is made explicit in s3.2.3.
o s5: Added note on TCP_NODELY socket option / PSH flag for TCP.
o s7: Added discussion of precautionary receive timeout.
o s8: Added elaborations on backward compatibility regarding the
slightly strenghtened packetization requirements from s3.2.3.
o Updated Acknowledgements; added Informative Ref. to expired '2000
IXFR-bis draft.
o Addressed review comments from Lubos Slovak.
o Updated Appendix B with regard to above changes.
o Removed old Appendix C, added new Appendix C.
o Numerous editorial corrections and improvements.
Authors' Addresses Authors' Addresses
Alfred Hoenes Alfred Hoenes
TR-Sys TR-Sys
Gerlinger Str. 12 Gerlinger Str. 12
Ditzingen D-71254 Ditzingen D-71254
Germany Germany
EMail: ah@TR-Sys.de EMail: ah@TR-Sys.de
 End of changes. 76 change blocks. 
257 lines changed or deleted 370 lines changed or added

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