Authoritative DNS must remain available even when one server is offline. A common design uses one primary server where administrators update the zone and one or more secondary servers that answer queries from synchronized copies. DNS zone transfers are the mechanism that keeps those copies current.
Two transfer types do most of the work: AXFR sends a complete zone, while IXFR sends incremental changes when both servers support it and suitable history is available. Used correctly, they improve resilience and reduce administrative duplication. Configured carelessly, however, they may expose a domain’s namespace or allow unauthorized systems to request sensitive zone data.
What is a DNS zone transfer?
A DNS zone is the administrative portion of the namespace served by a particular authority. It contains resource records and an SOA record with operational values, including a serial number. The primary server holds the editable source, while secondary servers maintain read-only copies received through zone transfer.
The distinction is covered in more detail in this guide to a Master DNS zone. The terminology “primary” and “secondary” describes where zone data is edited and replicated; it does not mean that clients must always prefer one authoritative server over another. Properly delegated authoritative servers can all answer public queries for the zone.
The role of the SOA serial number
The SOA serial number indicates which version of the zone a server holds. A secondary periodically checks the primary’s SOA record according to the refresh timer. If the primary has a newer serial, the secondary requests an update. Operators must increase the serial whenever zone content changes, otherwise a secondary may have no reason to retrieve the new version.
DNS NOTIFY speeds up synchronization
Waiting for the next refresh interval can delay propagation to secondary servers. DNS NOTIFY lets the primary signal that the zone has changed. The secondary then checks the SOA serial and initiates a transfer if necessary. NOTIFY accelerates the normal process; it does not replace serial comparison or authenticate the transfer by itself.
For a concise overview of zone files, primary and secondary zones, and both transfer modes, see the ClouDNS guide to DNS zone transfers.
AXFR: a complete zone transfer
AXFR transfers the full contents of a zone over a TCP connection. The response begins and ends with the zone’s SOA record, with the remaining records sent between them. A new secondary commonly uses AXFR for its initial copy because it does not yet have a local version from which to calculate changes.
A complete transfer is also useful when an incremental update cannot be produced, when the secondary’s copy is too old, or when administrators need to restore a known-good full version. The trade-off is efficiency: large zones consume more bandwidth and processing time when every record is sent after a small change.
IXFR: an incremental zone transfer
IXFR aims to send only the differences between serial versions. For a zone that changes frequently but has many stable records, that can substantially reduce transfer size. The primary needs access to the required change history, usually through a journal or equivalent mechanism, and the secondary must identify the version it currently holds.
IXFR is not guaranteed for every request. If the primary cannot build an incremental response from the requested serial, it may fall back to AXFR. Administrators should therefore permit and plan for full transfers even when IXFR is the routine path. Monitoring should measure both successful incremental updates and unexpected full-transfer frequency.
Why unrestricted transfers are risky
A public DNS server must answer ordinary queries, but it usually should not give an arbitrary requester a complete inventory of the zone. An unrestricted AXFR can reveal hostnames and records that make reconnaissance easier. Public records are not automatically secret, yet a convenient bulk listing may expose naming patterns, forgotten systems, infrastructure roles, or records that were published unintentionally.
The greater operational risk is accepting transfers or updates from an unauthorized peer. A secure design identifies exactly which servers may exchange data and verifies that the messages came from a trusted party. Network restrictions help, but cryptographic authentication is stronger than relying only on a source IP address.
How to secure DNS zone transfers
Allow only approved secondary servers
Configure the primary with an explicit allow-list for the IP addresses of authorized secondary servers. Do not use a broad network range unless every host in that range is trusted for zone access. On the secondary, specify the intended primary addresses rather than accepting data from arbitrary systems.
Authenticate transfers with TSIG
Transaction Signatures, or TSIG, use a shared secret and a keyed message authentication code to authenticate DNS messages. When both peers are configured with the same protected key, TSIG helps verify message origin and integrity. Use a modern supported algorithm, unique keys where practical, strict file permissions, secure key distribution, and a documented rotation process.
Protect the transport path when confidentiality matters
TSIG authenticates messages but does not encrypt the zone contents. If the network path is not trusted and confidentiality is required, place the transfer inside an appropriately secured private network, VPN, or other protected channel supported by the architecture. Firewall rules should restrict DNS transfer connections as an additional layer, not as the only control.
Separate public and private namespaces
Do not publish internal-only records in a public zone merely because transfers are restricted. Split-horizon designs and separate internal zones can limit exposure, but they require careful operational ownership. Confirm that every authoritative server serves the intended view and that transfer policies match each view.
Reliable primary and secondary operation
Secondary DNS provides more than a backup file. Multiple authoritative servers can improve availability, distribute query traffic, and reduce dependence on a single network or location. This overview of Secondary DNS explains the broader role of replicated authoritative service.
Operational resilience depends on timers as well as transfers. The SOA refresh value controls how often secondaries check for changes, retry determines when to try again after failure, and expire specifies how long a secondary may continue serving the zone without contacting its source. Values should fit the change rate and recovery objectives rather than being copied blindly from another domain.
Monitoring and troubleshooting checklist
- Compare SOA serials. Query each authoritative server directly and confirm that the serials converge after a change.
- Review transfer logs. Look for refused requests, authentication failures, unexpected AXFR fallbacks, timeouts, and transfers from unapproved addresses.
- Test from the secondary. Confirm network reachability to the primary over TCP and verify that firewalls, access lists, and TSIG names match.
- Check NOTIFY handling. Make sure notifications reach the intended servers and trigger a serial check rather than being silently discarded.
- Alert on stale data. Detect secondaries that lag behind the expected serial before the SOA expire timer becomes critical.
- Audit access regularly. Remove retired secondary addresses and unused keys, then test that unauthorized AXFR requests are refused.
External checks should also verify that every delegated nameserver answers consistently. The existing guide to DNS monitoring outlines useful availability and consistency signals beyond the transfer logs themselves.
The protocol behavior and interoperability requirements for full transfers are specified in RFC 5936: DNS Zone Transfer Protocol (AXFR).
Conclusion
AXFR and IXFR keep authoritative DNS servers synchronized: AXFR supplies a complete copy, while IXFR can deliver smaller incremental changes. A dependable deployment combines correct SOA serial management, NOTIFY, explicit peer restrictions, TSIG authentication, protected key handling, and monitoring for stale or unexpected transfers. These controls preserve the availability benefit of secondary DNS without offering the full zone to unauthorized systems.
