DNS Zone Transfer Protocol (AXFR)
Extracted elements (26)
AXFR is TCP-only because reliability is essential for zone transfer accuracy. Although EDNS0 and small-zone scenarios (web hosting, ENUM) would make UDP seem attractive, aspects of AXFR sessions—such as multi-message responses—are not easily translated to UDP, so this document deliberately does not extend AXFR to UDP.
The AXFR response MUST transfer the cut-point NS RRset registered with the zone rather than substituting the authoritative child NS set, because (1) servers cannot always detect inconsistencies locally, (2) exposing inconsistencies enables operators to diagnose delegation errors, and (3) a stable (zone, serial) → RR-set mapping is required for correct IXFR operation.
The original RFC 1034/1035 AXFR specification implicitly assumed one TCP connection per AXFR session, evidenced by no requirement to copy the Question section or message ID. This was unintentional; the modern specification requires multiple concurrent AXFR sessions and other DNS queries to be supported over a single connection.
If an AXFR server does not support EDNS0, the client MUST retry without an OPT RR. There is no explicit EDNS0 non-support indicator; a FormErr(1) response may be inferred as evidence of lack of EDNS0 support. Only the EXTENDED-RCODE field of the OPT RR is meaningful in the AXFR context.
Some old AXFR clients expect each response message to contain only a single RR. A server MAY restrict response messages to a single RR for compatibility; however, since there is no standard way to automatically detect such clients, this typically requires manual configuration at the server.
A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients and SHOULD NOT have a default policy of open access. General-purpose implementations are RECOMMENDED to implement TSIG and/or SIG(0)-based access controls.
An AXFR client MUST ensure that only a successfully transferred copy of zone data can be used to serve the zone. If any error is detected, erroneous data MUST be deleted and the client MUST continue serving the previous version. The externally visible behavior MUST be equivalent to the two-stage model.
An AXFR response transferring zone contents MUST begin with the SOA resource record of the zone in the first message, and MUST conclude with the same SOA record in the last message. Intermediate messages MUST NOT contain the SOA resource record.
An AXFR server MUST be able to handle multiple AXFR sessions on a single TCP connection, as well as other query/response transactions over the same connection. Restricting a TCP connection to a single AXFR session is incorrect.
AXFR clients MUST ignore any duplicate RRs received. The protocol treats zone contents as an unordered set; clients MUST accept any ordering and grouping of non-SOA RRs. Each RR SHOULD be transmitted only once.
AXFR sessions MUST use TCP; UDP transport for AXFR is not defined. RFC 1034 requires TCP for AXFR because accuracy is essential and a reliable protocol is needed.
If an AXFR client sends a query on a TCP connection and the connection is closed, the client MUST consider the AXFR session terminated. Retry behavior SHOULD NOT be an endless cycle or increasingly frequent retry rate.
Name compression in AXFR messages SHOULD be performed in a case-preserving manner: 'a' is not equal to 'A' for compression matching purposes in AXFR, unlike in normal DNS responses. RDATA compression MUST abide by RFC 3597 Section 4.
Occluded names (subordinate names rendered inaccessible by dynamically added delegation points or DNAME records) MUST be included in AXFR responses, and AXFR clients MUST be able to identify and handle them.
The AXFR query header MUST have QR=0 (Query), OPCODE=0 (Standard Query), RCODE=0 (No error), QDCOUNT=1, ANCOUNT=0, NSCOUNT=0. The Z bit MUST be set to 0 by the client. The server MUST reply using the same message ID as the query.
The AXFR response MUST contain the appropriate glue records as registered with the zone. Even when there is an inconsistency between a glue record's address and the authoritative copy, the registered glue record must be included.
The AXFR response MUST contain the cut-point NS resource record set as registered with the zone, whether or not it agrees with the authoritative NS set at the child apex. This ensures a given (zone, serial) pair yields the same set of records regardless of which authoritative server is queried.
The AXFR response MUST have ID copied from the request, QR=1, OPCODE=0, TC=0, NSCOUNT=0. If RCODE is NoError(0), the AA bit MUST be 1. The server MUST set Z, AD, and CD bits to 0.
The Question section of the AXFR query MUST contain a single resource record with QNAME set to the zone name, QTYPE=252 (AXFR), and QCLASS set to the class of the zone requested.
The TC (truncation) bit MUST be 0 in AXFR responses and is never considered by an AXFR client. The DNS message size limit for UDP and EDNS0 extensions to that limit are not relevant for AXFR.
An AXFR session consists of an AXFR query message and the sequence of AXFR response messages returned for it. The AXFR client is the sender of the query; the AXFR server is the responder. The session is strictly TCP-based.
IANA has added a reference to RFC 5936 in the AXFR (QTYPE value 252) row of the 'Resource Record (RR) TYPEs' subregistry of the 'Domain Name System (DNS) Parameters' registry.
Ensuring an AXFR client does not accept a forged zone copy is critical. Protection mechanisms include dedicated links, VPNs among authoritative servers, and use of TSIG or SIG(0) for message authentication and integrity verification. RFC 3833 Section 4.3 separately delineates zone transfer security from DNSSEC-addressed threats.
Zone administrators may have legal or operational reasons to restrict AXFR access to prevent exposure of full zone contents. Implementations SHOULD support IP-range and TSIG/SIG(0)-based authorization, and SHOULD NOT default to open access. Closing a TCP connection in response to suspected abuse SHOULD be reserved for extreme cases.
Zone synchronization uses a two-stage model: triggered by SOA serial change or DNS NOTIFY, the AXFR session transfers and saves zone data; upon successful completion and sanity checks, the data is atomically loaded for serving; if any error is detected, the erroneous data is deleted and the previous zone version continues to be served.
AXFR uses the standard DNS message format with a 16-bit ID field, QR/OPCODE/flag bits (AA, TC, RD, RA, Z, AD, CD), a 4-bit RCODE, and four 16-bit section count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT). Over TCP, messages are prefixed with a 2-octet unsigned length field, giving a maximum message size of 65535 octets.