DNS Zone Transfers (AXFR/IXFR) Explained

Learn how DNS zone transfers replicate records between primary and secondary servers using AXFR and IXFR protocols.

What Is a Zone Transfer?

A DNS zone transfer is the mechanism by which DNS servers replicate zone data from a primary (master) server to one or more secondary (slave) servers. This ensures that all authoritative servers for a domain have identical records, providing redundancy and load distribution.

Zone transfers use TCP port 53 (unlike regular DNS queries which primarily use UDP).

AXFR vs IXFR

AXFR (Full Zone Transfer)

AXFR transfers the entire zone from primary to secondary. The secondary requests all records, and the primary sends the complete zone file:

# Request a full zone transfer (if authorized)
dig axfr example.com @ns1.example.com

# Response includes every record in the zone
example.com.     86400  IN  SOA   ns1.example.com. admin.example.com. ...
example.com.     86400  IN  NS    ns1.example.com.
example.com.     86400  IN  NS    ns2.example.com.
example.com.     3600   IN  A     93.184.216.34
www.example.com. 3600   IN  CNAME example.com.
...

AXFR is simple but inefficient for large zones with frequent changes.

IXFR (Incremental Zone Transfer)

IXFR transfers only the changes since the secondary's last known version (identified by the SOA serial number):

Secondary: "I have serial 2026010100. What changed?"
Primary: "Delete old A record, add new A record. New serial: 2026010200."

IXFR is far more efficient for large zones where only a few records change at a time.

How Zone Transfers Are Triggered

  1. SOA refresh timer -- The secondary periodically checks the primary's SOA serial number. If it has increased, a transfer is initiated.
  2. NOTIFY messages -- The primary proactively sends a NOTIFY to all secondaries when the zone changes. The secondary then checks the SOA and initiates a transfer if needed.
# BIND configuration for NOTIFY
zone "example.com" {
    type master;
    notify yes;
    also-notify { 198.51.100.2; };
    allow-transfer { 198.51.100.2; };
};

Security Concerns

An unrestricted zone transfer exposes your entire DNS zone to anyone who requests it. This reveals:

  • All subdomains and hostnames (subdomain enumeration).
  • Internal server names and IP addresses.
  • Mail server configuration.
  • Service records (SRV) revealing internal infrastructure.

Securing Zone Transfers

  • Restrict by IP -- Only allow transfers from known secondary server IPs: allow-transfer { 198.51.100.2; 203.0.113.5; };
  • TSIG (Transaction Signature) -- Use shared-secret authentication for zone transfers: key "transfer-key" { algorithm hmac-sha256; secret "base64-encoded-secret"; };
  • Firewall rules -- Block TCP port 53 from unauthorized sources.

Testing Zone Transfer Security

# Test if a server allows unrestricted zone transfers
dig axfr example.com @ns1.example.com

# If you get records back, the server is misconfigured
# Expected (secure): "Transfer failed." or connection refused

Modern Alternatives

Many DNS providers have moved away from traditional zone transfers:

  • API-based sync -- Cloudflare, Route 53, and other providers sync records via API rather than AXFR/IXFR.
  • Database replication -- PowerDNS can use database replication instead of zone transfers.
  • DNS-over-TLS for transfers -- Emerging standard for encrypting zone transfer traffic.

See Also