Skip to main content

5. Authorization

Zone transfers can expose sensitive information about a zone's structure and contents, potentially aiding attackers in reconnaissance activities. For this reason, AXFR servers typically employ authorization mechanisms to restrict zone transfers to trusted clients only.

This section describes common authorization techniques used in AXFR implementations. Note that this document does not mandate any specific authorization method; implementers and operators are free to choose the approach that best fits their security requirements.

Common Authorization Techniques​

  1. Access Control Lists (ACLs): An AXFR server MAY use IP address-based ACLs to restrict which clients are permitted to request zone transfers. The server checks the source IP address of the incoming TCP connection against a configured list of allowed addresses or networks.

    • Advantages: Simple to implement and configure.
    • Limitations: Vulnerable to IP address spoofing (though TCP's three-way handshake provides some protection). Not suitable for clients with dynamic IP addresses.

  2. TSIG (Transaction Signature): TSIG [RFC2845] provides cryptographic authentication of DNS messages using shared secret keys. An AXFR server MAY require TSIG authentication for zone transfer requests.

    • Advantages: Provides strong authentication and message integrity. Not dependent on IP addresses.
    • Limitations: Requires pre-shared keys to be configured on both client and server. Key management can be challenging in large deployments.

  3. SIG(0) (Signature): SIG(0) [RFC2931] provides public key-based authentication of DNS messages. An AXFR server MAY use SIG(0) to authenticate AXFR queries.

    • Advantages: Uses public key cryptography, avoiding the need for pre-shared secrets. Suitable for scenarios where TSIG key management is impractical.
    • Limitations: More complex to implement and configure than TSIG. Requires public key infrastructure.

  4. TLS/SSL: While not specified in this document, an AXFR server MAY use TLS or SSL to encrypt and authenticate TCP connections used for zone transfers. This approach is not standardized for DNS zone transfers but may be used in private or controlled environments.

  5. VPN or Private Networks: In some deployments, zone transfers are conducted over private networks (e.g., VPNs [RFC2764]) that are not accessible to the public Internet. This approach relies on network-level security rather than application-level authentication.

Authorization Policy​

An AXFR server SHOULD implement a configurable authorization policy that determines which clients are permitted to request zone transfers. The policy SHOULD support at least one of the authorization techniques listed above.

An AXFR server MUST respond to unauthorized AXFR queries with a DNS response message containing RCODE REFUSED (5). This informs the client that the zone transfer was denied due to policy restrictions.

Default Behavior​

The default behavior of an AXFR server regarding authorization is not specified by this document. Implementers SHOULD choose a secure default behavior, such as:

  • Denying all zone transfer requests by default, requiring explicit configuration to permit specific clients, or
  • Permitting zone transfers only from specific IP addresses configured as secondary servers.

An AXFR server MUST NOT permit unrestricted zone transfers to arbitrary clients by default, as this poses a significant security risk.

Multiple Authorization Methods​

An AXFR server MAY support multiple authorization methods simultaneously. For example, a server might require both IP address-based ACL matching and TSIG authentication for a zone transfer to be permitted. The specifics of combining multiple authorization methods are implementation-dependent.

Authorization Failures​

If an AXFR query fails authorization checks, the AXFR server SHOULD respond with RCODE REFUSED. The server MAY log the failed authorization attempt for auditing purposes.

An AXFR server MUST NOT reveal details about why authorization failed (e.g., by returning different error codes for different failure reasons), as this could provide useful information to potential attackers.

Last updated on