DNS Zone Transfers and Why They Should Be Restricted
How AXFR requests can leak an entire DNS zone, and why locking them down is a basic hardening step.
Core Concept
A DNS zone transfer (AXFR) copies an entire zone's record set from a primary nameserver to a secondary one, a mechanism designed for legitimate server-to-server replication.
When left unrestricted, any client can request a full zone transfer, effectively downloading a domain's complete DNS configuration in one request.
What an Exposed Zone Reveals
A successful unauthorized zone transfer can expose significant internal detail.
- Every subdomain configured for the domain, including internal ones
- Internal hostnames not otherwise discoverable
- Mail server and infrastructure topology
Reconnaissance Goldmine
For an attacker doing reconnaissance, an open zone transfer is often more valuable than any other single piece of information they could gather.
Why Zone Transfers Get Left Open
Misconfiguration, not intentional design, is almost always the cause.
- Default nameserver settings not restricted to known secondaries
- Legacy configurations never revisited after initial setup
- Misunderstanding of which IPs should be permitted to request transfers
Restricting Zone Transfers Correctly
Properly securing AXFR access is a straightforward configuration change.
Restricting transfers to only the IP addresses of known, authorized secondary nameservers closes off the exposure entirely without affecting legitimate replication.
Allowlist Secondaries Only
Explicitly allowlisting secondary nameserver IPs for zone transfers is the standard, effective fix — there's rarely a legitimate reason for public AXFR access.
Testing for Exposure
Checking whether a domain's zone transfer is exposed is a quick diagnostic step.
- Attempting an AXFR query against the domain's nameservers
- Checking whether a full record set is returned to an unauthorized client
- Verifying configuration matches the intended secondary list
Real-World Implementation
Zone transfer restriction is a standard item on DNS hardening checklists.
- Security audits routinely testing for open AXFR
- DNS providers defaulting to restricted transfers
- Compliance frameworks flagging exposed zone transfers as a finding
Because the fix requires no application changes and carries no functional downside, restricting zone transfers is one of the easiest DNS security wins available.
Common Mistakes to Avoid
A few mistakes commonly leave zone transfers exposed longer than intended.
- Leaving zone transfer configuration at default nameserver settings without review.
- Assuming zone transfers are inherently private without explicit access restriction.
- Failing to test for exposure with an actual AXFR query against production nameservers.
- Not updating the secondary nameserver allowlist after infrastructure changes.
- Overlooking zone transfer exposure during routine security audits.
- Overlooking that some DNS providers enable AXFR by default without clear documentation.
- Failing to distinguish between full zone transfers (AXFR) and incremental ones (IXFR).
- Not verifying zone transfer security after switching DNS providers.
- Overlooking TSIG authentication as an additional layer of zone transfer security.
- Assuming IP-based allowlisting alone is sufficient without additional authentication.
- Failing to audit zone transfer logs periodically for unauthorized access attempts.
- Overlooking that some DNS hosting platforms don't expose zone transfer settings in their UI.
Best Practices Checklist
These practices keep zone transfers properly restricted over time.
- Explicitly allowlist only known secondary nameserver IPs for AXFR requests.
- Test for zone transfer exposure periodically, not just during initial setup.
- Update the secondary nameserver allowlist whenever infrastructure changes.
- Include zone transfer configuration in routine DNS security reviews.
- Treat any successful unauthorized AXFR as an immediate finding requiring urgent remediation.
- Review your specific DNS provider's default zone transfer settings explicitly.
- Understand the difference between AXFR and IXFR when configuring transfer restrictions.
- Re-verify zone transfer security whenever switching to a new DNS provider.
- Consider TSIG authentication as an additional layer beyond simple IP allowlisting.
- Combine IP restriction with cryptographic authentication for stronger zone transfer security.
- Periodically audit zone transfer logs for any unauthorized access attempts.
- Contact your DNS provider directly if zone transfer settings aren't visible in the standard interface.
Frequently Asked Questions
Frequently asked questions about DNS zone transfer security.
What exactly does an exposed zone transfer reveal?
It can reveal every record configured for the domain, including internal subdomains and infrastructure hostnames not otherwise discoverable.
Is there ever a legitimate reason to allow public zone transfers?
Rarely — legitimate replication only requires access for the domain's actual secondary nameservers, not the public at large.
How do I test whether my zone transfer is exposed?
Attempting an AXFR query against your own nameservers from an unauthorized source will show whether the full record set is returned.
Does restricting zone transfers break anything for legitimate use?
No — restricting to known secondary nameserver IPs preserves legitimate replication while closing the public exposure.
Why do zone transfers get left open in the first place?
Usually because default nameserver settings were never explicitly restricted, not because of a deliberate choice to allow public access.
Do DNS providers enable zone transfers by default?
This varies by provider, and some may enable AXFR without clearly surfacing it, making explicit review worthwhile.
What's the difference between AXFR and IXFR?
AXFR transfers the entire zone, while IXFR transfers only the incremental changes since the last synchronization, reducing data transfer overhead.
Should zone transfer settings be re-checked after a provider migration?
Yes — default configurations can differ significantly between providers, making re-verification an important post-migration step.
What is TSIG in the context of DNS zone transfers?
A cryptographic authentication mechanism that verifies the requesting server's identity, adding security beyond simple IP-based restriction.
Is IP allowlisting alone sufficient for zone transfer security?
It's a strong baseline, but combining it with TSIG authentication provides a more robust, layered defense.
What if my DNS provider doesn't show zone transfer settings?
Contacting support directly is worthwhile, since some platforms manage this configuration outside the standard self-service interface.
Check Zone Transfer Exposure
Run a DNS analysis to check for exposed zone transfer configuration on a domain.
Launch Tool →