DNS Zone Transfer: When Your Entire Network Map Leaks to Anyone
One misconfigured line in a DNS server config can hand attackers a complete map of your infrastructure β every host, every subdomain, every internal name. Here is how AXFR zone transfers leak, why it matters, and how to check your domain in seconds.
π Table of contents
Every public reconnaissance guide starts the same way: enumerate the target's DNS. Attackers want subdomains, internal hostnames, staging servers, mail infrastructure β anything that turns a known domain into a known network. Normally that takes hours of brute-force guessing and certificate-log mining. But when a DNS server has one line of configuration wrong, all of it is available in a single request. That is an open zone transfer, and it is still found on production domains every week.
What a zone transfer actually is
DNS replication between a primary (master) and secondary (slave) nameserver uses the AXFR protocol: the secondary asks "give me the entire zone," and the primary sends every record it holds. It is a full-fidelity copy β not a cache, not a summary, the complete zone file:
- π₯οΈ Every A/AAAA record β every named host, public and internal
- π¬ Every MX record β mail server topology
- π·οΈ Every TXT record β SPF, DKIM, verification strings, sometimes notes
- π Every CNAME β aliases that reveal service names and third parties
- π³οΈ Records not published anywhere else β staging, admin, dev, forgotten projects
Between legitimate secondaries, this is exactly how DNS is supposed to stay in sync. The vulnerability is not the protocol β it is who is allowed to ask.
The misconfiguration
A nameserver should answer AXFR only for its configured secondaries. When access control is missing or set to any, the server treats the entire public internet as a trusted replica:
# The dangerous line, in named.conf terms:
allow-transfer { any; };
Anyone can then run:
dig AXFR example.com @ns1.example.com
β¦and receive the whole zone in seconds. The CWE-668 class β resource exposure to the wrong sphere β has been documented for decades, which is precisely what makes finding it in the wild so valuable: it is a purely administrative mistake, invisible to the site's users, and often untouched for years on secondary infrastructure nobody watches.
Why the leak matters
A zone file is a reconnaissance shortcut. What an attacker does with it:
- πΊοΈ Complete infrastructure map β no guessing; every hostname is enumerated with one request
- π― High-value target discovery β
staging.,admin.,vpn.,mail.records that no public source would reveal - 𧩠Subdomain takeover chains β dangling CNAMEs inside the zone are the perfect input for takeover checks
- π£ Credible phishing material β internal naming conventions make targeted lures dramatically more convincing
- π‘ Attack surface enumeration β the zone defines the full external perimeter in one response
For defenders the calculus inverts: a domain with a closed zone transfer forces attackers back to slow, noisy, probabilistic enumeration β and makes your unseen infrastructure actually unseen.
How to test your domain
The manual test is one command per nameserver:
dig AXFR yourdomain.com @ns1.yourdomain.com
A refusal (REFUSED or NOTAUTH) is the passing result. A response containing XFR and a record stream is the finding β and note that transfer availability can differ per nameserver, so every authoritative server must be tested, including ones operated by a different team or provider.
Scanners operationalize exactly this. The 2MNY DNS Zone Transfer module tests AXFR against every authoritative nameserver for the domain, records precisely which server leaked and what records were exposed, and scores the finding by what the leaked zone actually revealed. It runs alongside DNS Analysis (record hygiene), DNSSEC validation, deep DNS probing, and subdomain enumeration β one free security scan covering the whole DNS layer.
Fixing it
- π Restrict
allow-transferto the IPs of your real secondaries β or better, require TSIG keys so authorization is cryptographic, not address-based - π’ Split DNS β internal names belong on an internal view that is never served to public resolvers
- 𧱠Firewall TCP/53 at the edge β AXFR runs over TCP; public resolvers only need UDP/53 plus your actual secondaries
- π Re-test after any DNS provider change β migrations and registrar moves are when the guard rails typically fall off
DNS misconfigurations are quiet by nature: nothing breaks, no user complains, the site stays up. That is what makes periodic scanning the only reliable detector β the continuous monitoring pattern catches the regression the day it appears, not the day an attacker mentions it.
Security research and engineering at 2MNY β the team behind 282 free website-security scanners and the open-source Website Vulnerability Scanner. We find exposed secrets, misconfigurations and real vulnerabilities, then explain how to fix them in plain language.
1 What is a DNS zone transfer?
A zone transfer (AXFR) is the mechanism a primary DNS server uses to replicate its full zone file β every record β to secondary servers. It is legitimate replication that becomes a data leak when a server answers AXFR queries from unauthorized clients.
2 How do I check if my domain allows zone transfers?
Run dig AXFR yourdomain.com against each nameserver, or use a free scanner: 2MNY's DNS Zone Transfer module tests AXFR against all authoritative nameservers and reports exactly what leaked, alongside its DNS Analysis and subdomain enumeration checks.
3 What information does an exposed zone transfer leak?
The complete zone: every A, AAAA, MX, TXT, and CNAME record, including internal hostnames, staging and admin endpoints, subdomains that no public crawler would find, and infrastructure hints like SPF records and service locations.
4 How do I fix an open zone transfer?
Restrict allow-transfer to your secondary nameservers' IP addresses or require TSIG keys, keep internal records on a split-DNS view that never serves externally, and verify port 53 TCP is not reachable from the public internet except for your real secondaries.
