Skip to main content

6. Zone Integrity

Ensuring the integrity of transferred zone data is critical for maintaining the security and reliability of the DNS infrastructure. This section discusses integrity considerations for AXFR and recommends best practices.

Integrity Threats​

Zone transfers are subject to several integrity threats:

  1. Man-in-the-middle attacks: An attacker positioned between the AXFR client and server could intercept and modify zone data in transit.

  2. Spoofing attacks: An attacker could impersonate an AXFR server and send falsified zone data to an AXFR client.

  3. Replay attacks: An attacker could capture a legitimate zone transfer and replay it later, potentially causing the client to revert to outdated zone data.

  4. Unauthorized modifications: Without proper authentication and integrity checks, an attacker could inject, delete, or modify resource records during a zone transfer.

Integrity Protection Mechanisms​

To protect against these threats, AXFR implementations SHOULD employ one or more of the following integrity protection mechanisms:

TSIG (Transaction Signature)​

TSIG [RFC2845] provides message-level authentication and integrity protection using shared secret keys and HMAC algorithms.

How TSIG works for AXFR:

  1. The AXFR client includes a TSIG RR in its query message, signed with a pre-shared key.

  2. The AXFR server validates the TSIG signature on the query. If validation fails, the server responds with RCODE NOTAUTH or REFUSED.

  3. If the query is valid, the AXFR server includes TSIG RRs in its response messages:

    • The first response message MUST include a TSIG RR.
    • Intermediate messages MAY omit TSIG (for efficiency), but the sequence is still protected by the TSIG on the first and last messages.
    • The last response message MUST include a TSIG RR.

  4. The AXFR client validates the TSIG signatures on the response messages. If any validation fails, the client MUST discard the entire zone transfer.

Benefits: TSIG provides strong integrity protection and mutual authentication. It is widely supported in DNS implementations.

Limitations: Requires pre-shared keys, which must be securely distributed and managed.

SIG(0) (Signature)​

SIG(0) [RFC2931] provides public key-based message authentication using DNSSEC-style signatures.

How SIG(0) works for AXFR:

  1. The AXFR client signs its query message with its private key and includes the resulting SIG(0) RR in the query.

  2. The AXFR server validates the signature using the client's public key (retrieved via DNS or from a local trust anchor).

  3. The AXFR server MAY sign its response messages with its own private key, allowing the client to verify the authenticity of the response.

Benefits: Eliminates the need for pre-shared secrets. Suitable for scenarios where key distribution is challenging.

Limitations: More complex to implement and configure than TSIG. Relies on public key infrastructure.

DNSSEC​

For zones that are DNSSEC-signed, the AXFR client can validate the integrity of the transferred zone data using DNSSEC signatures (RRSIG records).

How DNSSEC protects AXFR:

  1. The AXFR server transfers the zone, including all RRSIG, DNSKEY, and NSEC/NSEC3 records.

  2. The AXFR client validates the RRSIG signatures on the transferred RRsets using the DNSKEY records in the zone.

  3. If DNSSEC validation fails, the client SHOULD NOT serve the zone data.

Benefits: Provides end-to-end integrity protection for zone data, not just during the transfer but also when the data is served to resolvers.

Limitations: Requires the zone to be DNSSEC-signed. Does not protect the AXFR protocol itself (e.g., against unauthorized clients).

Network-Level Security​

In addition to application-level security mechanisms, AXFR transfers MAY be protected using network-level security:

  1. TLS/SSL: Encrypting the TCP connection using TLS or SSL provides confidentiality and integrity protection for the zone transfer. (Note: DNS-over-TLS for zone transfers is not standardized at the time of this writing.)

  2. IPsec: Zone transfers conducted over IPsec-protected connections benefit from the confidentiality, integrity, and authentication provided by IPsec.

  3. VPNs or private networks: Conducting zone transfers over a private network (such as a VPN) can provide an additional layer of security.

Recommendations​

  1. Use TSIG or SIG(0): AXFR servers and clients SHOULD support and use TSIG or SIG(0) to protect zone transfers. TSIG is the most commonly deployed solution and is RECOMMENDED for most deployments.

  2. Validate transferred data: AXFR clients SHOULD validate the integrity of received zone data before committing it to their local zone database. For DNSSEC-signed zones, this validation includes verifying DNSSEC signatures.

  3. Secure key management: For TSIG-based deployments, operators MUST ensure that shared keys are generated using cryptographically strong random number generators and are securely stored and distributed.

  4. Monitor for anomalies: Operators SHOULD monitor zone transfers for anomalies, such as unexpected changes in zone size, unusual transfer frequencies, or failed integrity checks.

  5. Use strong algorithms: When using TSIG, operators SHOULD use strong HMAC algorithms, such as HMAC-SHA256 or HMAC-SHA512, rather than weaker algorithms like HMAC-MD5. See [RFC4635] and [RFC5702] for guidance on algorithm selection.

Handling Integrity Failures​

If an AXFR client detects an integrity failure (e.g., TSIG validation failure, DNSSEC validation failure), it MUST:

  1. Discard all data received from the failed zone transfer.
  2. Log the failure for auditing and troubleshooting purposes.
  3. Optionally, retry the zone transfer after a suitable delay (with backoff).

An AXFR client MUST NOT commit partially received or integrity-failed zone data to its authoritative zone database, as doing so could result in serving incorrect or malicious data to DNS clients.

Last updated on