A DNS zone transfer, AXFR, copies every record in a zone from one name server to another. It is meant for your own secondary servers. If your server answers anyone who asks, outsiders get a full list of your hostnames. Restrict transfers to named servers, ideally authenticated, and test from outside.
What AXFR is for
Zones are usually served by more than one name server. A primary holds the master copy, and secondaries obtain it with a zone transfer. RFC 5936 defines the AXFR protocol, which sends the full contents of a zone over TCP in a series of response messages.
Good redundancy needs secondaries. RFC 2182 advises placing them in topologically and geographically separate locations, so one failure does not take all of them down. Zone transfers keep those secondaries current.
Why an open transfer is a problem
DNS answers one name at a time. Without a transfer, an outsider guesses hostnames and queries them. With an open AXFR they receive every record at once: staging servers, internal tools, VPN gateways, old test systems and the target of every CNAME. That is a ready made map for attackers and a list of dangling candidates.
RFC 5936 acknowledges the practice of restricting access. It says that a zone administrator has the option to restrict AXFR access, notes reasons such as keeping the bulk version of the zone concealed or avoiding the load, and says a DNS implementation should provide a way to restrict AXFR to specific clients.
An open transfer is not the same as a breach, since the records are public one by one. But it removes the guesswork, and it often reveals names you forgot you had.
Options for restricting transfers
| Control | What it does | Notes |
|---|---|---|
| Allow list by address | Listed secondaries may request a transfer, others are refused | Simple. Addresses can be spoofed in some contexts, so combine with others |
| Transaction signatures (TSIG) | Shared key authenticates the request and response | RFC 5936 recommends general purpose servers support TSIG |
| Private network path | Transfers run over a VPN or private link | Reduces exposure further |
| Managed DNS with no transfer | The provider replicates internally | Nothing to expose, but check the provider's settings |
How to test your own servers
- List your zone's name servers with an NS lookup.
- From a machine outside your network, request a zone transfer from each name server with a DNS query tool that supports AXFR.
- A refusal or a failure is the result you want. A full list of records means the transfer is open.
- Test every apex domain you own, including parked and brand domains. Old name servers are the usual culprits.
- Repeat after any change of DNS provider.
- Add the test to your routine, see domain and DNS hygiene.
Test servers you operate or have written permission to test, and no others.
If a transfer is open
- Restrict it at once to your secondaries.
- Review the zone for records that should not be public or are no longer needed.
- Check for dangling targets using the audit steps.
- Move sensitive internal names into a private zone, so they do not appear in public DNS at all.
- Review your DNSSEC setup too. Our post on what DNSSEC protects covers the basics.
Related delegation checks
If you delegate subdomains, the child servers also need controls. See delegation and the two server rule.
Safeguard works on the software supply chain and does not test DNS servers. Its free dependency scan is at gold.safeguard.sh/scan.
Quick check
Should secondary servers be able to request AXFR?
Yes, that is the purpose. Allow the secondaries you run, and nobody else, with authentication where you can.
Is hiding my zone contents a security control by itself?
No. It reduces easy reconnaissance, but real protection comes from removing stale records and securing the services behind them.
Sources
- RFC 5936, DNS Zone Transfer Protocol (AXFR)
- RFC 2182, Selection and Operation of Secondary DNS Servers
Last reviewed: 19 October 2026.
