What is a DNS zone transfer (AXFR), and why an open one leaks your whole zone
AXFR (Authoritative Transfer) is the DNS mechanism a secondary name server uses to copy an entire zone — every record, for every hostname — from a domain's primary server in one request, and it was designed to run only between a domain's own authorized servers; when a server answers an AXFR request from anyone on the internet instead, it hands that requester a complete map of the domain's internal hostnames, mail servers and infrastructure in a single query.
By AdminKit team, Netbase JSC · Updated October 24, 2026
What AXFR is designed to do
Every domain’s DNS setup relies on at least one primary (authoritative source of truth) and usually one or more secondary name servers that answer the same queries for redundancy. Keeping those servers in sync requires some way to copy the zone’s full record set from the primary to each secondary, and AXFR — Authoritative Transfer — is the mechanism DNS was originally designed to use for exactly that. RFC 1035 first defined AXFR as part of the core DNS specification, and RFC 5936 later replaced that original, underspecified definition with a precise, interoperable protocol description: a secondary sends an AXFR query, and the primary responds with every record in the zone in a single, ordered transfer, rather than the one-record-type-at-a-time answers an ordinary DNS lookup returns. In practice, a secondary first checks the zone’s SOA record serial number against its own copy, and only pulls a full transfer when the serial has actually changed.
Why an open AXFR is a real information leak
A normal DNS query — looking up a domain’s MX record, or its A record for a specific hostname — only ever returns the one record type and name asked for. AXFR is categorically different: it returns the zone’s entire contents in one response, which is precisely why it needs to be restricted to a domain’s own authorized secondary servers rather than answered for anyone who asks. RFC 8499’s terminology section defines a zone transfer the same way — a complete copy of a zone — and that completeness is the whole risk. A zone often contains internal or staging subdomains, hostnames for infrastructure that was never meant to be publicly advertised, and enough naming-convention detail to reveal what software or vendors a domain relies on, none of which would normally surface from ordinary, targeted lookups.
How to confirm whether your domain is affected
The check is a single command, run from any machine outside your own network so you’re testing what the outside world actually sees: dig axfr @<nameserver-address> yourdomain.com, repeated against each name server listed in your domain’s NS records. A correctly configured server refuses the request outright. A misconfigured one prints the entire zone file to your terminal, record by record — an unambiguous result either way. AdminKit’s DNS lookup tool will show you the NS records to test against, and Whois/RDAP confirms which registrar and hosting setup is actually authoritative for the domain if the NS records look unexpected.
Fixing it
Every common authoritative DNS server supports restricting AXFR to a named list of IP addresses — your own secondary servers, and nothing else. BIND uses an allow-transfer directive, PowerDNS uses allow-axfr-ips, and managed DNS providers almost universally disable open zone transfer by default, meaning most domains on managed DNS are never exposed to this in the first place; the check above is still worth running once, since a misconfiguration (an old self-hosted name server left in the NS set, for example) can reintroduce the problem even on an otherwise managed domain.
Related checks
Zone transfer exposure and delegation correctness are two different ways a domain’s DNS setup can be wrong without anyone noticing day to day — see our guide on glue records and lame delegation for the delegation side, and DNSSEC: what it actually protects for a related but distinct DNS-trust guarantee that an open AXFR does nothing to provide.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
What is AXFR for, when it's working as intended?
AXFR keeps a domain's secondary (backup) name servers synchronized with its primary. RFC 5936 defines the exact request/response mechanics: a secondary sends an AXFR query to the primary and receives the zone's complete record set back in one transfer, which is how most DNS providers replicate a zone across redundant servers without manually copying records. This is a routine, necessary operation between a domain's own name servers — the problem is only when a server performs it for a requester that isn't one of those authorized secondaries.
Why is an open AXFR considered a leak, specifically?
Because a zone file is far more than the handful of public records someone would normally look up one at a time. A full zone transfer typically includes every subdomain's A/AAAA records, internal or staging hostnames that were never meant to be advertised, MX and TXT records, and sometimes hostnames that reveal internal naming conventions or third-party vendors in use. A normal DNS lookup only returns the specific record type and name you ask for; AXFR returns everything at once, which is exactly why RFC 1035's original definition of the mechanism assumed it would only ever be used between trusted, authorized servers.
How do I check whether my own domain allows open zone transfers?
From a machine outside your own network, run `dig axfr @<nameserver> <yourdomain>` against each of your domain's authoritative name servers (found via an NS lookup). If the server is correctly configured, it refuses the request with a message such as 'Transfer failed' or a REFUSED response; if it's misconfigured, it returns the full zone contents right there in the terminal output. AdminKit's DNS lookup tool shows you which name servers to test against as a starting point.
How do I fix an open zone transfer?
Configure your authoritative name server software to restrict AXFR to an explicit allow-list of IP addresses — your own secondary servers only — rather than answering transfer requests from any source. Every major DNS server implementation (BIND's `allow-transfer`, PowerDNS's `allow-axfr-ips`, and the equivalent setting on managed DNS providers) supports this restriction; if you use a managed DNS provider, zone transfer is very often disabled by default and only needs to be confirmed, not configured from scratch.
Does disabling open AXFR break anything for normal visitors?
No. Ordinary DNS resolution — the lookups browsers, mail servers and every other DNS client perform — uses individual record queries, never AXFR. Restricting zone transfers to your own authorized secondary servers has no effect on how your domain resolves for the public; it only removes the ability for an arbitrary third party to request the entire zone in one request.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.