A DNS zone transfer copies authoritative records from a primary server to a secondary; AXFR sends the full zone, IXFR sends changes, and neither should be open to arbitrary clients.
Transfers make redundant authoritative DNS possible, but a permissive transfer policy can hand an outsider an inventory of internal names and service targets.
Table of contents
- What a zone transfer does
- Restrict and authenticate peers
- Test a transfer deliberately
- Diagnose stale secondary data
- Design for reliable authoritative DNS
- How this fits the rest of the stack
- FAQ
What a zone transfer does
The primary server owns the writable zone data and secondary servers request synchronized copies. AXFR transfers the complete zone and is simple but potentially large. IXFR uses the zone serial and journal history to transfer only changes when both sides support it, falling back to a full transfer when incremental history is unavailable.
NOTIFY messages let the primary tell secondaries that a serial changed, while refresh timers provide a backup polling path. The SOA serial must advance when zone data changes. A forgotten serial can leave a secondary serving old records even though every configuration file looks correct.
Restrict and authenticate peers
Allow transfers only to known secondary addresses and authenticate them with TSIG where supported. IP allowlists reduce exposure, while TSIG proves that the request and response share a secret and were not modified in transit. Store that secret like any deployment credential and rotate it with an overlapping plan.
Do not publish TSIG material in a zone file, repository, or command history. Network rules should permit TCP port 53 between authoritative peers because full transfers use TCP. UDP-based NOTIFY traffic may also be part of the design.
Test a transfer deliberately
dig AXFR example.com @ns1.example.net
dig SOA example.com @ns1.example.net
dig SOA example.com @ns2.example.netAn authorized AXFR should return the complete zone and finish with the SOA. An unauthorized request should fail. Compare SOA serials across all authoritative servers after a change. Test from the actual secondary network as well as an untrusted network so the allow and deny paths are both proven.
If the public test succeeds without authentication or an approved source address, treat it as an exposure. Disable open transfer, review the disclosed record inventory, and look for names that reveal private systems or obsolete endpoints.
Diagnose stale secondary data
- Confirm the primary zone loaded successfully
- Verify the SOA serial increased
- Check NOTIFY delivery and secondary logs
- Test TCP 53 in both network paths
- Validate TSIG name, algorithm, and secret
- Confirm journal history permits IXFR
- Trigger a controlled retransfer and compare answers
Do not edit the secondary copy by hand. It will be overwritten and hides the synchronization fault. Fix the primary data or transfer path, then let the secondary converge through the normal mechanism.
Design for reliable authoritative DNS
Place authoritative servers on independent failure domains and monitor each one from outside. Keep recursion disabled on authoritative-only servers, document the primary-of-record, and alert on serial divergence. Multi-provider DNS can add resilience, but only when record ownership and transfer direction are unambiguous.
Zone transfer is replication, not a backup strategy by itself. Keep versioned source data and tested recovery procedures. A secondary faithfully reproduces a mistaken deletion just as efficiently as a correct update.
Treat transfers as auditable privileged operations. Log successful and rejected transfer requests, alert when an unexpected peer asks for AXFR, and rate-limit repeated failures without blocking legitimate recovery. If a secondary has been offline longer than the SOA expire interval, it may stop serving the zone and require a fresh transfer; monitor that state before redundancy silently disappears. During provider migrations, compare complete record sets rather than a few popular names, including DNSSEC and delegation-related data that may live outside the transferred zone. Remove old peer permissions and secrets once cutover is complete.
How this fits the rest of the stack
DNS replication protects the route into a service, while capacity planning protects what runs behind it. The RunxBuild hosting calculator models the service and bandwidth, and the RunxBuild dashboard keeps domain and deployment visibility together.
Useful related references:
- DNS Resolution Error: 6 Causes and the Right Fix
- What Does Flushing DNS Do? Clearing the Local Cache of Stale Answers
- Is Google DNS (8.8.8.8) Down? How to Actually Tell Before You Panic
- Custom domains and certificates on RunxBuild
FAQ
What is the difference between AXFR and IXFR?
AXFR sends the full zone. IXFR sends changes since a known serial when journal history and both servers support it.
Should DNS zone transfer be public?
No. Limit it to approved secondary servers and authenticate peers with TSIG where possible.
Why does zone transfer use TCP?
A complete zone can exceed a single UDP response. AXFR uses TCP for reliable ordered transfer.
What does TSIG protect?
It authenticates DNS messages with a shared secret and verifies integrity. It does not encrypt the zone contents.
Why is a secondary serving stale records?
Common causes include an unchanged SOA serial, blocked TCP 53, failed NOTIFY, TSIG mismatch, or a zone-load error on the primary.