DNS Zone Transfer Hardening: AXFR and IXFR

A zone transfer is the mechanism that keeps secondary name servers in sync with the primary, and it is also one of the oldest reconnaissance techniques on the internet: a single dig AXFR against a misconfigured server returns the complete list of hosts in a domain. The two transfer types — full AXFR and incremental IXFR — are defined in RFC 5936 and RFC 1995. This article explains how they differ, when each is used, and exactly which controls stop an unauthorised server from pulling your zone, with configuration for BIND and PowerDNS.

AXFR vs IXFR

AXFR — full zone copy
  requested by a secondary with no local copy, or when SOA serial jumps
  transfers every record; expensive but always correct
IXFR — incremental transfer
  secondary presents its current SOA serial; primary sends only the delta
  falls back to AXFR if the delta is no longer available

Both run over TCP port 53 (a full zone copy would fragment hopelessly over UDP). That single fact already gives you one useful control: blocking TCP/53 from outside is legitimate for a purely authoritative server with no external secondaries.

How a secondary decides to transfer

1. secondary polls the primary's SOA every refresh interval
2. if serial is higher (or serial arithmetic wraps), start transfer
3. AXFR: replace the zone entirely after a successful transfer
4. IXFR: apply delta; if it fails, escalate to AXFR
5. notify (RFC 1996) can trigger the check immediately instead of waiting

SOA timers matter operationally: a refresh of 3600 with a retry of 600 is a reasonable default; a notify-enabled primary makes the refresh interval almost irrelevant for convergence because secondaries are told immediately.

The information-leak risk

dig AXFR example.com @ns1.example.com
# an uncontrolled server answers with the internal zone:
# vpn.example.com, jenkins.example.com, db-admin.example.com, ...

Even in 2026, a meaningful share of domains still answer AXFR from anywhere. The leak is not just hostnames — internal naming conventions often reveal architecture, and paired with a VPN endpoint it is a direct attack shortcut.

Hardening: BIND

options {
  allow-transfer { none; };          ! global default: refuse
  also-notify { 198.51.100.53; };
};

zone "example.com" {
  type primary;
  file "/var/lib/bind/db.example.com";
  allow-transfer { 198.51.100.53; 198.51.100.54; };
  notify yes;
};

# TSIG-based authorisation (preferred over IP allow lists)
key "xfr-key" {
  algorithm hmac-sha256;
  secret "base64secret==";
};

zone "example.com" {
  allow-transfer { key "xfr-key"; };
};

Verify from a non-listed host:

dig +tcp AXFR example.com @ns1.example.com
# expected: "; Transfer failed."

With TSIG, the secondary must be configured with the same key and must present it in the transfer request; IP allow-lists become a second layer rather than the only layer. The full primary/secondary build is in BIND9 authoritative zone configuration.

Hardening: PowerDNS

# pdns.conf
allow-axfr-ips=198.51.100.53/32,198.51.100.54/32
disable-axfr=no
# TSIG: use the primary's allow-dnsupdate / allow-axfr-ips plus
# a transfer key managed through the API or the database backend

PowerDNS documentation is explicit that allow-axfr-ips defaults to permitting transfers from anywhere when set to 0.0.0.0/0 — a common copy-paste mistake. Details and the load-balancing layer are in PowerDNS and dnsdist.

Detecting abuse

# BIND query log
querylog yes;  # or rndc querylog
tail -f /var/log/named/query.log | grep -i axfr

# PowerDNS
grep -i "AXFR" /var/log/pdns.log

Signal                              Meaning
Repeated AXFR from one external IP  zone-walking attempt
AXFR at consistent intervals        a misconfigured secondary you forgot about
IXFR/AXFR mix on the same source    legitimate secondary catching up after a gap

FAQ

Q: Should I disable TCP/53 entirely? No — TCP is required for large responses, DNSSEC and EDNS. Block only what you do not need, and rate-limit rather than block if you serve public clients.
Q: Is AXFR over TLS worth it? XoT (RFC 9103) encrypts transfers between primaries and secondaries, which matters for hidden primaries and multi-provider setups.
Q: Does DNSSEC prevent AXFR leaks? No. DNSSEC proves authenticity, not authorisation; AXFR control is still required. If you are debugging a transfer that will not start, start with dig and nslookup troubleshooting.

原文链接：https://www.rfc-editor.org/rfc/rfc5936.html