2. AXFR Messages

An AXFR session consists of a single TCP connection and is initiated by a DNS query message. That query message determines the zone to be transferred and certain characteristics of the session. Following the query is the transfer of the zone contents, assuming a successful query, and then a connection termination.

The following definitions are used in this document. The "AXFR client" is the host that initiates the TCP connection and sends the DNS AXFR query. The "AXFR server" is the host that receives the AXFR query and sends the AXFR response(s). An "AXFR session" consists of one AXFR query and the sequence of AXFR responses corresponding to that query.

An AXFR is one of several query types (QTYPE) defined for the DNS; however, unlike most query types, AXFR can require several DNS messages to fully respond to a query. The format of the initial query and the response messages are standard DNS messages, defined in RFC 1035 and subsequent documents. Some fields in the DNS message are further restricted when the query type is an AXFR.

Throughout this document, AXFR queries and responses will be divided into sections following the structure of the DNS message. The five sections are: (1) Header, (2) Question, (3) Answer, (4) Authority, and (5) Additional.

This section documents the query and response messages, including restrictions on the queries and requirements on the servers. This also addresses the TCP connection usage.

2.1. AXFR Query

This subsection describes the format and semantics of the query message that initiates an AXFR session. The term "normal DNS" will be used to describe behavior governed by the standard DNS specification (RFC 1034, RFC 1035, and updates).

An AXFR query is like a normal DNS query message with QTYPE AXFR; however, there are additional restrictions imposed on a "well-formed AXFR query". An AXFR client sending an AXFR query SHOULD conform to the rules for a well-formed query. An AXFR server MUST respond to an AXFR query that does not conform to these rules in the same manner it would respond to any improperly formatted query. (This is typically a FORMERR response.)

A well-formed AXFR query has the following characteristics:

1. The DNS header's OPCODE MUST be zero (a standard query).

2. The DNS header's question section (QDCOUNT) MUST be 1.

3. The DNS header's answer section count (ANCOUNT), authority section count (NSCOUNT), and additional section count (ARCOUNT) MUST all be 0.

4. The question section MUST contain a single question with:

   • QTYPE equal to AXFR [RFC5395] (252 decimal);
   • QCLASS equal to the zone class or ANY;
   • QNAME equal to the name of the zone to be transferred.

5. AXFR responses MAY be of a greater DNS protocol version than the query.

2.1.1. Header Values

QR: MUST be 0 (Query)

OPCODE: MUST be 0 (Standard Query)

AA: Not examined (irrelevant to a query)

TC: MUST be 0 (Not Truncated) - An AXFR query with TC set to 1 is improperly formatted.

RD: MAY be 0 or 1 - The Recursion Desired bit is ignored by the AXFR server; it neither affects the behavior of an AXFR query nor plays a role in authoritative transfers. The setting of the RD bit in an AXFR query message is not a reliable indicator that the query is a recursive query.

RA: Not examined (only used in responses)

Z: MUST be 0 (reserved for future use) - Per the DNS specification's requirement, the reserved bits MUST be zero in a query and MUST be ignored in a response. Hence, an AXFR client MUST set the Z bits to zero, and an AXFR server MUST ignore their value. An AXFR query with any of the reserved (Z) bits set to a non-zero value is improperly formatted.

AD: MUST be 0 - The Authentic Data bit is only defined for responses [RFC4035].

CD: MAY be 0 or 1 - The Checking Disabled bit is relevant to responses only, so it has no defined meaning for a zone transfer query. An AXFR client MAY set this bit; an AXFR server MUST ignore its value.

RCODE: MUST be 0 (No Error) - The response code field is only defined for responses.

QDCOUNT: MUST be 1

ANCOUNT: MUST be 0

NSCOUNT: MUST be 0

ARCOUNT: MUST be 0 or MAY be greater than zero if the query includes EDNS(0) [RFC2671], TSIG [RFC2845], or SIG(0) [RFC2931] options.

For EDNS(0), TSIG, and SIG(0) considerations, see Section 2.2.5.

2.1.2. Question Section

The question section MUST conform to that specified in RFC 1035, containing a single question with the following characteristics:

QNAME: The name of the zone to be transferred, which MUST be a valid DNS domain name.

QTYPE: The value is 252 (for AXFR) per [RFC5395].

QCLASS: The class of the zone to be transferred. Because AXFR queries can be a major security risk, an AXFR server will likely restrict zone transfer access through some policy (via Access Control Lists, TSIG authentication, etc.), and a zone transfer should not be served to just any querier. The special QCLASS value * (ANY, 255 decimal) MAY be used for backwards compatibility purposes. When QCLASS is ANY, an AXFR server is not to return zone data for all available classes of data, but may choose one class and transfer that zone or may refuse the query. (The latter is RECOMMENDED for a general-purpose DNS implementation.) Carefully written AXFR clients request zone transfers via specific classes.

2.1.3. Answer Section

The answer section MUST be empty (ANCOUNT must be 0) in an AXFR query.

2.1.4. Authority Section

The authority section MUST be empty (NSCOUNT must be 0) in an AXFR query.

2.1.5. Additional Section

The additional section of an AXFR query message may contain EDNS(0) resource records (RRs) [RFC2671] to indicate EDNS support and parameters. It may also contain TSIG [RFC2845] or SIG(0) [RFC2931] RRs for authentication purposes. The presence of TSIG or SIG(0) options allows for authentication of the AXFR query, potentially enabling more permissive authorization policies on the AXFR server.

When EDNS(0) is used, the OPT pseudo-RR is placed in the additional section, and the ARCOUNT is incremented appropriately. The version number advertised by EDNS(0) indicates a willingness to accept packets formatted for that version. An AXFR client that is not EDNS aware will set ARCOUNT to 0 and not include an OPT RR. An AXFR server that is not EDNS aware will ignore the OPT RR and may choose to treat the query as malformed if ARCOUNT is greater than 0 and additional processing (examining those additional RRs) is enabled.

An AXFR query with a SIG(0) will have ARCOUNT equal to 1 plus the number of OPT RRs in the additional section. A TSIG RR is not counted in ARCOUNT, as TSIG is an alternative message authentication technique in DNS. See [RFC2845] for TSIG considerations.

TSIG and EDNS(0) MAY be used simultaneously.

2.2. AXFR Response

This subsection describes the format and semantics of responses to AXFR queries. Responses are sent after a TCP connection is established and an AXFR query is parsed.

An AXFR server MUST be able to handle a query with unexpected, undefined, or unsupported flags or attributes by responding with a standard DNS error response. The conditions that cause various errors are elaborated in the following subsections.

There are four categories of AXFR server responses to an AXFR query:

1. A malformed response: This results if the AXFR query received via TCP is not a legal DNS query message or if the DNS message does not conform to the requirements of a well-formed AXFR query as specified in Section 2.1. The response to a malformed query SHOULD be a single DNS response message with an appropriate RCODE (FORMERR, NOTIMP, REFUSED, etc.).

2. A refused response: If a received DNS message is a legal AXFR query, but policy considerations dictate that this particular AXFR client is not permitted to perform zone transfers (for the zone in question or in general), the response SHOULD be a single DNS response message with RCODE REFUSED.

3. An empty response: If the zone being transferred is empty (all authoritative data at the zone apex is outside the zone), the AXFR server SHOULD return a single response message with only a SOA RR in the answer section. This SOA RR will be the sole RR in the zone. The conditions for an empty zone are highly unusual and are a result of out-of-band operations (zone edits, dynamic updates, or other means) that have removed all but the mandatory SOA from the zone.

4. A successful response: Assuming no policy or malformation issues, the AXFR server responds with one or more DNS response messages that collectively contain all of the authoritative data from the transferred zone, subject to some specific inclusions and exclusions described in Section 3.

The first three types of response are delivered via a single DNS message. The last type, the successful response, can consist of one or more DNS response messages sent sequentially over the TCP connection.

An AXFR server that implements EDNS(0), TSIG, or SIG(0) MUST be prepared to receive AXFR query messages that do not contain the corresponding options. Conversely, an AXFR server MAY choose to ignore the presence of EDNS(0), TSIG, or SIG(0) options in the query message (e.g., if it does not support or require them). However, if an AXFR server implements EDNS(0), TSIG, or SIG(0) and chooses to make use of information from those options in the request, it MUST include the appropriate option information in its AXFR response messages.

An AXFR client MUST be prepared to receive AXFR responses in which the TC (truncation) bit is not used or meaningful. Because AXFR operates over TCP and is permitted to use multiple DNS messages in a response sequence, truncation is not necessary. (The use of the TC bit is explicitly covered in Section 2.2.1.)

2.2.1. Header Values

QR: MUST be 1 (Response)

OPCODE: MUST be 0 (Standard Query)

AA: The AA (Authoritative Answer) bit SHOULD be set to 1 in all response messages. While the AXFR server is likely to be authoritative for the zone being transferred, there is no strict requirement for that to be the case.

TC: MUST be 0 (Not Truncated) - Because AXFR operates over TCP and can use multiple response messages, there is no need to set the TC bit.

RD: The RD bit in the response copies the RD bit from the query (per DNS specification). The RD bit has no significance for AXFR; its value does not affect AXFR behavior.

RA: The RA (Recursion Available) bit MAY be set or cleared in the response according to the AXFR server's general policies. In the case of a zone transfer, recursion is not applicable, so the value of RA is not meaningful in this context.

Z: MUST be 0 (Reserved) - The reserved bits MUST be set to zero by an AXFR server and MUST be ignored by an AXFR client.

AD: MAY be 0 or 1 - For DNSSEC-aware AXFR servers serving DNSSEC-signed zones, the AD (Authentic Data) bit MAY be set in AXFR responses according to DNSSEC requirements [RFC4035]. For zones that are not DNSSEC-signed, the AD bit SHOULD be 0. An AXFR client that is not DNSSEC-aware ignores the AD bit.

CD: SHOULD be 0 - The CD (Checking Disabled) bit is relevant only to resolvers, not to authoritative servers. For AXFR responses, the CD bit SHOULD be 0 and has no defined meaning.

RCODE: The response code indicates the result of the AXFR query. Common values include:

• NOERROR (0): Successful transfer (all answer messages in a successful AXFR response sequence have RCODE set to NOERROR).
• FORMERR (1): Format error in the query.
• SERVFAIL (2): Server failure while processing the request.
• NOTIMP (4): Query type not implemented.
• REFUSED (5): Zone transfer refused by policy.
• NOTAUTH (9): Server is not authoritative for the zone requested (defined in [RFC2136]).

For a successful AXFR response, all DNS response messages in the AXFR session MUST have RCODE set to NOERROR. If a DNS response message in an AXFR session has RCODE set to anything other than NOERROR, the AXFR client MUST consider the zone transfer to have failed.

QDCOUNT: MUST be 1 - The question section is repeated in each response message, copying the question from the query.

ANCOUNT: Indicates the number of RRs in the answer section. The value varies depending on how many RRs fit in each response message.

NSCOUNT: MUST be 0 - No authority section is included in AXFR response messages.

ARCOUNT: MUST be 0 or greater if EDNS(0), TSIG, or SIG(0) is used. Typically, ARCOUNT is 0 for AXFR responses.

2.2.2. Question Section

The question section in the response MUST be identical to the question section in the corresponding AXFR query. This means QDCOUNT MUST be 1, and the single question MUST match the question from the query.

2.2.3. Answer Section

The answer section contains the zone data being transferred. The requirements for the contents of the answer section are:

1. SOA RRs: The first RR in the first answer message of an AXFR response MUST be the SOA RR for the zone. The last RR in the last answer message of an AXFR response MUST also be the SOA RR for the zone (i.e., the same SOA RR appears at the beginning and end of the transfer).

2. Intermediate RRs: Between the two SOA RRs (the first and the last), the answer section of the response message(s) contains all other authoritative RRs for the zone (subject to the restrictions in Section 3).

3. Order: The order of RRs in the answer section (other than the first and last SOA RRs) is undefined. However, all RRs of the same RRset (same owner name, class, and type) SHOULD be grouped together for efficiency.

4. Multiple messages: If the zone data does not fit in a single DNS response message, the AXFR server sends multiple response messages. Each response message after the first continues with additional zone data, and the last message ends with the trailing SOA RR.

2.2.4. Authority Section

The authority section MUST be empty (NSCOUNT = 0) in AXFR response messages. Including NS records or other authority data in the authority section of an AXFR response is explicitly prohibited.

2.2.5. Additional Section

The additional section of AXFR response messages is generally empty, but it MAY contain EDNS(0), TSIG, or SIG(0) RRs if those options were negotiated or are in use.

EDNS(0): If the AXFR query contained an EDNS(0) OPT RR, the AXFR server MAY include OPT RRs in the additional sections of its response messages. EDNS(0) in AXFR responses is used primarily for signaling extended capabilities and buffer sizes.

TSIG: If TSIG is used for authentication, TSIG RRs are included in the additional section of AXFR response messages. TSIG signing is applied differently in multi-message AXFR responses:

• The first response message in a successful AXFR sequence MUST include a TSIG RR.
• Intermediate messages MAY omit the TSIG RR (unsigned intermediates are allowed).
• The last response message MUST include a TSIG RR.

See [RFC2845] for detailed TSIG considerations.

SIG(0): If SIG(0) is used, each response message containing a SIG(0) will have ARCOUNT incremented accordingly.

2.3. TCP Connection Aborts

An AXFR client or AXFR server MAY abort an in-progress AXFR session by closing the TCP connection. Reasons for aborting a connection include:

• Malformed or unexpected DNS messages.
• Timeouts (either read or write timeouts).
• Authorization failures (e.g., failed TSIG validation).
• Internal server errors.
• Resource exhaustion.

An aborted connection MUST be interpreted by the AXFR client as a failed zone transfer. The AXFR client SHOULD NOT commit any partial zone data received prior to the connection closure.

An AXFR server MAY use TCP connection closure as an indication to the AXFR client that the zone transfer has failed.