Cybersecurity glossary
What is a Zone Transfer (AXFR/IXFR)?
Learn what DNS zone transfers are, how AXFR and IXFR replicate authoritative data to secondary servers, and why open zone transfers create serious information exposure.
Definition
A zone transfer is the replication of DNS zone data between authoritative servers, typically using AXFR for full copies or IXFR for incremental changes.
Zone transfer is how entire zones move
Authoritative DNS needs redundancy, and redundancy only helps if the servers agree on the data they serve. Zone transfer protocols exist to replicate a zone from one authoritative source to other authoritative servers so secondaries stay in sync.
This is ordinary, necessary DNS plumbing, but it has sharp edges. A well-configured transfer keeps authoritative answers consistent. An open or poorly controlled transfer can hand an attacker a neatly packaged inventory of names, systems, and sometimes security-relevant patterns inside your namespace.
The main ideas behind AXFR and IXFR
Zone replication is conceptually simple, but the protocol choices determine how much data moves, how fast changes converge, and how much accidental exposure is possible.
AXFR full copy
AXFR sends the entire zone, which is useful for initial synchronization or when incremental deltas are unavailable.
IXFR delta copy
IXFR sends only the changes between serial versions, making routine updates more efficient.
SOA serial trigger
The secondary compares serial numbers to decide whether it should request a transfer.
Transfer authorization
ACLs and TSIG help ensure only intended secondaries can request and receive zone contents.
What happens during a normal zone-transfer cycle
A secondary checks the SOA serial
At refresh time it asks the transfer source whether the zone version has changed.
The secondary detects that it is stale
A higher serial on the source tells the secondary that its local zone copy is outdated.
IXFR is attempted when supported
The secondary may ask for only the delta between the old and new serial versions.
AXFR is used when a full copy is needed
If incremental transfer is not possible, the source can send the complete zone contents.
The secondary loads the new data
After a successful transfer it begins answering authoritatively with the updated zone.
The process repeats according to SOA timers
Refresh and retry values determine how quickly later changes are noticed or retried.
When AXFR and IXFR each make sense
Both transfer types are useful. The right choice depends on whether the secondary is bootstrapping, catching up, or following a steady stream of smaller updates.
| Method | Best suited for | Tradeoff |
|---|---|---|
| AXFR during initial setup | A new secondary that needs the full authoritative dataset for the first time. | Transfers the most data and can expose the whole zone if access control is wrong. |
| IXFR for routine updates | Zones that change often and want efficient synchronization between versions. | Requires both sides to retain enough history to compute or serve deltas. |
| AXFR after major divergence | Recovery when the secondary missed too much history or cannot apply the delta safely. | More bandwidth and more time than a clean incremental update. |
| TSIG-protected transfers | Any environment that wants stronger assurance that the requester is an approved secondary. | Adds key lifecycle and operational management requirements. |
Zone-transfer safeguards to keep in place
Transfer security is mostly about limiting who can ask and proving that the permitted peer is who it claims to be.
- Restrict AXFR and IXFR to known secondary IPs or peers instead of allowing broad public access.
- Use TSIG or equivalent provider controls where supported to authenticate transfer partners.
- Review SOA serial handling and timers so secondaries converge predictably without unnecessary churn.
- Periodically test secondaries for successful refresh rather than discovering replication drift during an outage.
- Treat unexpected zone-transfer success from an unapproved host as a security finding that needs immediate remediation.
- Inventory hidden-primary or provider-managed transfer paths so changes in network segmentation do not silently break replication.
- Be mindful of what internal naming details public zones reveal even when transfers are locked down.
- Log transfer attempts and failures to spot abuse, misconfiguration, or stale secondary relationships.
Why open zone transfers are such a useful attacker clue
A successful unauthorized AXFR can reveal far more than a single DNS answer ever would. Attackers may learn internal naming conventions, staging hosts, legacy systems, mail and VPN infrastructure, and which third-party services the organization relies on, all from one misconfiguration.
Even when transfers are not open, weak change control around secondaries can create stale or inconsistent authoritative answers. Replication reliability is part of availability, while transfer access control is part of exposure management. Both deserve attention.
The practical takeaway
Zone transfers keep authoritative DNS servers synchronized by moving full zones with AXFR or deltas with IXFR. They are essential for redundancy, but only when tightly restricted to approved peers.
Treat transfer policy as sensitive infrastructure. If strangers can pull your zone, you have handed them a map of your namespace for free.
Related security terms
SOA Record
Secondaries use the SOA serial to determine whether a zone transfer is needed.
NS Record
Zone transfers occur between authoritative servers named for the zone.
DNS Zone
The full set of records inside a zone is what AXFR and IXFR replicate.
Authoritative DNS Server
Only authoritative servers participate as transfer sources or secondaries.
DNSSEC
DNSSEC can coexist with transfers, but transfer authorization still needs its own controls.
Frequently asked questions
What is the difference between AXFR and IXFR?
AXFR transfers the entire zone, while IXFR transfers only the changes since a previous serial version when both sides support that delta exchange.
Why do DNS servers use zone transfers?
They keep secondary authoritative servers synchronized with the current zone data so multiple name servers can answer consistently.
Are zone transfers supposed to be public?
No. They should normally be restricted to authorized secondary servers and protected with access controls or TSIG where possible.
Can an open zone transfer be a security issue?
Yes. It can expose the contents of the zone, including hostnames and records that help attackers map your infrastructure.
Does every managed DNS provider expose AXFR or IXFR directly?
No. Some providers abstract replication behind their own control plane and may not expose traditional transfer workflows to customers.
What role does the SOA serial play?
The secondary compares the SOA serial to decide whether its local copy is outdated and whether it should request IXFR or AXFR.
References
Explore authoritative guidance and frameworks related to zone transfer (axfr/ixfr).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.