Zone transfer is the process of moving DNS zone records from one authoritative server to another, typically to keep a primary server synchronized with one or more secondary servers. In traditional DNS, AXFR performs a full zone transfer, while IXFR allows for incremental updates when both ends support the feature. NOTIFY can alert secondaries that a zone has changed, prompting them to request an update. The notification does not itself transfer the changed records; the secondary still has to request and receive them. These mechanisms ensure DNS service consistency and availability, but they do not facilitate domain registration transfers between registrars.
How it works
The secondary server queries the primary and uses the SOA serial and other parameters to determine whether its copy needs updating. AXFR returns all zone records according to the protocol; IXFR sends only available differences. The standard AXFR protocol uses TCP, and implementations must manage sessions, messages, and transfers per specifications. Some managed DNS providers maintain synchronization via APIs or proprietary systems, so customers may not directly observe an AXFR transfer.
Zone transfers must be authorized. A server that allows anyone to request AXFR can expose the full list of records, aiding subdomain reconnaissance, host discovery, services, and environments. Many servers restrict AXFR to authorized secondary IP addresses and may use TSIG for request authentication. Access controls should be tested externally with proper authorization, avoiding unauthorized scans. Such a test should check whether an unauthorized client can retrieve the zone, not merely whether the server accepts connections. TCP port 53 being reachable does not confirm that zone transfers are open.
Security and privacy
Public records can be queried individually through standard DNS queries, so blocking AXFR does not hide names already published and queryable. However, an open transfer provides a complete view in one operation and may expose non-obvious data or internal zones if misconfigured. Internal zones should not be published on public authoritative servers; views and infrastructure should be separated according to security models. Secondary access should be limited to specific hosts and keys.
When switching providers, zone transfers can replicate data, but integrity checks are required. Records, serials, delegations, DNSSEC, and mail services must be compared before delegating. TSIG keys and credentials must be distributed securely and rotated if compromised. The secondary server must serve the same version; otherwise, users may receive inconsistent responses depending on which node they reach.
Troubleshooting and maintenance
If authoritative nameservers return inconsistent responses, check SOA serials, NOTIFY logs, AXFR/IXFR permissions, TCP connectivity, and process status. An outdated secondary might return stale records even if reachable. Providers may use invisible synchronization via AXFR; in such cases, diagnostics rely on official service tools. Monitoring freshness and consistency from multiple points is useful, especially after critical changes.
In summary, zone transfer maintains consistent copies of DNS zones across authoritative servers. AXFR is full, IXFR incremental, and NOTIFY signals a change. Configuration must restrict transfers to authorized secondaries and protect authentication data. Properly configured zone transfers are essential for maintaining reliable DNS infrastructure and preventing unauthorized access or exposure of internal network details.
← Full glossary