Skip to main content

1. Introduction

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

This document re-specifies the AXFR mechanism as it is deployed in the Internet at large, hopefully with the precision expected from modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.

1.1. Definition of Terms​

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

Use of "newer"/"new" and "older"/"old" DNS refers to implementations written after and prior to the publication of this document.

"General-purpose DNS implementation" refers to DNS software developed for widespread use. This includes resolvers and servers freely accessible as libraries and standalone processes. This also includes proprietary implementations used only in support of DNS service offerings.

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

The terms "AXFR session", "AXFR server", and "AXFR client" will be introduced in the first paragraph of Section 2, after some more context has been established.

1.2. Scope​

In general terms, authoritative name servers for a given zone can use various means to achieve coherency of the zone contents they serve. For example, there are DNS implementations that assemble answers from data stored in relational databases (as opposed to master files), relying on the database's non-DNS means to synchronize the database instances. Some of these non-DNS solutions interoperate in some fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-defined in-band mechanisms to provide coherence of a set of name servers, and they are the only mechanisms specified by the IETF.

This document does not cover incoherent DNS situations. There are applications of the DNS in which servers for a zone are not intended to be coherent.

1.3. Context​

An AXFR client issues a query to receive the contents of a zone from an AXFR server. Such transfers are a DNS query type and conform to the DNS protocol specifications, including query header and answer messages.

The zone contents are the authoritative DNS RRs owned by domain names within the zone. Typically, all authoritative RRs for a zone are transferred by an AXFR session, with one exception. When following a zone cut, glue records are not transferred.

A zone transfer is initiated by the DNS SOA refresh timer, a NOTIFY message, or operator intervention (though other means are not precluded). An AXFR is often limited to servers specifically configured as secondary to the primary servers for the zone, and queries from other clients are refused.

The original 1035 definition of AXFR specified it to run over TCP. This specification only supports AXFR over TCP. For completeness, however, this specification mentions AXFR-over-UDP in an informative appendix.

An AXFR session consists of an AXFR query message, one or more AXFR response messages, and, finally, termination of the TCP connection. An AXFR session is said to be "successful" if the following two conditions hold: (1) the AXFR client received a successful AXFR response sequence, and (2) the AXFR client closed the TCP connection or the client received confirmation that the AXFR server closed the TCP connection.

This document does not address zone transfer security. The relevant security considerations are discussed in Section 8.

1.4. Coverage and Relationship to Original AXFR Specification​

This document covers an authoritative, non-DNS UPDATE aware, primary to secondary AXFR session with no security employed, and the zone transferred is a "normal" DNS zone, for IPv4 transport. That is, the server is a master or primary for the zone and the client is a secondary, or slave, server. The definition has been written in a manner intended to permit an extension mechanism to indicate coverage of additional parameter values.

For reference, this document notes the following (but does not define any of these variants):

  • Zone transfers can be conducted between a slave and another slave (all are authoritative servers).

  • A zone transfer client may be a resolver or a zone validator collecting data (non-authoritative applications).

  • There is an optional protocol extension that permits "incremental transfers" -- Incremental Zone Transfer (IXFR) [RFC1995].

  • DNSSEC (via RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]) defines a security protocol for DNS.

  • DNS UPDATE (RFC 2136 [RFC2136]) provides a means by which a zone can be dynamically updated.

  • IPv6 transport may be used.

The goal in mentioning these is to make clear that while the mechanisms described in this document apply only to a specific scenario, there are related ones that look to this document to provide some context. The listed variants are not all equivalent, are certainly not independent of one another, and may or may not be within the scope of this document.

This document is intentionally narrow in scope, but is so written to indicate that it describes an extensible mechanism.

Last updated on