Skip to main content

4. Transport

This section describes the transport protocol requirements for AXFR. The original DNS specification defined AXFR to operate over TCP, and this remains the only standardized transport for AXFR.

4.1. TCP​

AXFR MUST use TCP as its transport protocol. TCP provides reliable, ordered, and error-checked delivery of data, which is essential for the integrity of zone transfers.

4.1.1. AXFR Client TCP​

An AXFR client establishes a TCP connection to the AXFR server's DNS port (typically port 53, though other ports MAY be configured).

Connection establishment:

  1. The AXFR client initiates the TCP three-way handshake to establish a connection with the AXFR server.

  2. Once the TCP connection is established, the AXFR client sends the AXFR query message as specified in Section 2.1.

  3. The AXFR client then waits for the AXFR server to respond with one or more DNS response messages containing the zone data.

Connection persistence:

  1. The AXFR client SHOULD keep the TCP connection open until the complete zone transfer is received, as indicated by the receipt of the final SOA RR in the answer section of a response message.

  2. After receiving the complete zone transfer, the AXFR client MAY close the TCP connection or MAY keep it open to send additional queries (though this is not typical behavior for AXFR).

  3. The AXFR client MUST be prepared for the AXFR server to close the TCP connection at any time, including immediately after completing the zone transfer.

Timeouts:

  1. The AXFR client SHOULD implement read and write timeouts to detect unresponsive servers or network issues.

  2. Recommended timeout values vary depending on the size of the zone and network conditions, but a typical read timeout might be in the range of minutes (e.g., 5-10 minutes) to accommodate large zones.

  3. If a timeout occurs, the AXFR client SHOULD close the TCP connection and treat the zone transfer as failed.

Error handling:

  1. If the AXFR client receives a DNS response message with an RCODE other than NOERROR, it MUST treat the zone transfer as failed and close the TCP connection.

  2. If the AXFR client receives a malformed DNS message or a message that does not conform to the AXFR protocol, it SHOULD close the TCP connection and treat the zone transfer as failed.

  3. If the TCP connection is closed prematurely (before the final SOA RR is received), the AXFR client MUST treat the zone transfer as failed and discard any partial zone data received.

Multiple queries:

  1. An AXFR client MAY send multiple AXFR queries over the same TCP connection, a practice known as "pipelining" or "connection reuse". However, this behavior is not widely implemented or required.

  2. If an AXFR client sends multiple queries, it MUST wait for the complete response to the first query (including the final SOA RR) before sending the next query.

  3. An AXFR server is not required to support multiple queries per connection and MAY close the connection after responding to a single query.

4.1.2. AXFR Server TCP​

An AXFR server listens for incoming TCP connections on its DNS port (typically port 53).

Connection handling:

  1. Upon accepting a TCP connection, the AXFR server waits to receive a DNS query message from the AXFR client.

  2. The AXFR server parses the query message to determine if it is a valid AXFR query (as defined in Section 2.1).

  3. Based on the query and applicable policies (e.g., ACLs, TSIG authentication), the AXFR server either responds with the zone data or with an error message.

Response transmission:

  1. If the zone transfer is authorized, the AXFR server sends one or more DNS response messages containing the zone data, as specified in Section 2.2.

  2. Each response message is sent as a complete DNS message over the TCP connection. The AXFR server MUST ensure that message boundaries are preserved (i.e., each DNS message is preceded by a 2-byte length field, as specified in RFC 1035 Section 4.2.2).

  3. The AXFR server continues sending response messages until all zone data (including the final SOA RR) has been transmitted.

Connection termination:

  1. After transmitting the final response message (containing the trailing SOA RR), the AXFR server MAY close the TCP connection immediately or MAY keep it open to accept additional queries.

  2. The AXFR server SHOULD close idle connections after a reasonable timeout period to free up resources.

  3. The AXFR server MAY close the connection at any time if an error occurs (e.g., a write error, a timeout, or an internal error).

Concurrency:

  1. An AXFR server SHOULD be capable of handling multiple concurrent AXFR sessions (i.e., multiple TCP connections from different clients).

  2. The AXFR server MAY impose limits on the number of concurrent zone transfers to prevent resource exhaustion.

4.2. UDP​

AXFR over UDP is not standardized and MUST NOT be used in general-purpose DNS implementations. While early DNS specifications mentioned the possibility of AXFR over UDP for small zones, this approach has significant limitations:

  1. Reliability: UDP is an unreliable protocol and does not guarantee delivery or ordering of packets.

  2. Message size: DNS messages over UDP are limited in size (typically 512 bytes without EDNS(0), or up to 4096 bytes with EDNS(0)), making it impractical for most zone transfers.

  3. No standardization: There is no standardized format or behavior for AXFR over UDP in modern DNS specifications.

For these reasons, AXFR over UDP is considered obsolete and MUST NOT be implemented in new DNS software. Any references to AXFR over UDP in older DNS documents are historical and should be ignored.

Recommendation: AXFR clients and servers MUST use TCP. If UDP-based zone synchronization is needed for some reason, implementers should consider using IXFR [RFC1995] over UDP, though even IXFR is typically conducted over TCP.

Last updated on