Skip to main content

7. Backwards Compatibility

Describing backwards compatibility is difficult because of the lack of specifics in the original definition. In this section, some hints at building in backwards compatibility are given, mostly repeated from the relevant earlier sections.

Backwards compatibility is not necessary, but the greater the extent of an implementation's compatibility, the greater its interoperability. For turnkey implementations, this is not usually a concern. For general-purpose implementations, this takes on varying levels of importance, depending on the implementer's desire to maintain interoperability.

It is unfortunate that a need to fall back to older behavior cannot be discovered, and thus has to be noted in a configuration file. An implementation SHOULD, in its documentation, encourage operators to periodically review AXFR clients and servers it has made notes about repeatedly, as old software gets updated from time to time.

7.1. Server​

An AXFR server has the luxury of being able to react to an AXFR client's abilities, with the exception of knowing whether the client can accept multiple resource records per AXFR response message. The knowledge that a client is so restricted cannot be discovered; hence, it has to be set by configuration.

An implementation of an AXFR server MAY permit configuring, on a per AXFR client basis, the necessity to revert to a single resource record per message; in that case, the default SHOULD be to use multiple records per message.

Legacy client considerations:

  1. Single RR per message: Some very old DNS implementations expect only a single resource record in the answer section of each AXFR response message. Modern AXFR servers SHOULD support multiple RRs per message for efficiency, but MAY provide a configuration option to revert to single-RR behavior for specific legacy clients.

  2. Message size: Older clients may have limitations on the maximum size of DNS messages they can process. AXFR servers MAY provide configuration options to limit the size of individual response messages when interacting with such clients.

  3. EDNS(0), TSIG, and SIG(0): Older clients may not support EDNS(0), TSIG, or SIG(0). An AXFR server SHOULD gracefully handle queries from clients that do not include these options and SHOULD NOT require their presence unless specifically configured to do so for security reasons.

Recommendations for server implementations:

  • Default to modern, efficient behavior (multiple RRs per message, support for EDNS(0)/TSIG/SIG(0)).
  • Provide configuration options to accommodate legacy clients on a per-client basis.
  • Document known compatibility issues and recommended configuration settings for interoperating with older software.

7.2. Client​

An AXFR client has the opportunity to try other features (i.e., those not defined by this document) when querying an AXFR server.

Attempting to issue multiple DNS queries over a TCP transport for an AXFR session SHOULD be aborted if it interrupts the original request, and SHOULD take into consideration whether the AXFR server intends to close the connection immediately upon completion of the original (connection-causing) zone transfer.

Legacy server considerations:

  1. Multiple RRs per message: Modern AXFR clients MUST be prepared to receive multiple resource records in a single AXFR response message. This is standard behavior and has been widely deployed for many years.

  2. Connection handling: Older servers may close the TCP connection immediately after sending the final SOA RR, while others may keep the connection open for a period of time. AXFR clients SHOULD be prepared for either behavior and SHOULD NOT rely on the connection remaining open after the zone transfer is complete.

  3. Error responses: Some older servers may return non-standard error responses or may not strictly conform to the DNS message format. AXFR clients SHOULD implement robust error handling to gracefully handle unexpected responses.

Recommendations for client implementations:

  • Support all standard features defined in this document.
  • Implement robust error handling to tolerate minor deviations from the specification.
  • Avoid relying on connection persistence or other non-standard behaviors.
  • Be prepared to fall back to simpler behavior (e.g., not using EDNS(0)) if a server appears not to support it.
Last updated on