DNS Zone Transfer (AXFR) Test

Test whether your nameservers allow unauthorized AXFR zone transfer requests — a critical DNS misconfiguration that exposes your entire DNS zone to attackers.

Our DNS Zone Transfer Test attempts an AXFR request against each of your authoritative nameservers to check whether they will hand a complete copy of your DNS zone to any anonymous client. An open zone transfer is a serious information disclosure — this test tells you in seconds whether yours is exposed.

What is a DNS Zone Transfer?

A zone transfer (AXFR) is the mechanism by which a secondary nameserver obtains a complete copy of a DNS zone from the primary. It is a legitimate and necessary part of running redundant DNS.

The problem is that the protocol has no authentication built in. Unless the nameserver is explicitly configured to restrict who may request a transfer, it will hand the entire zone to anyone who asks — every hostname, every internal server name, every development and staging environment, every mail server and every IP address in a single response.

Normal DNS only answers questions you already know to ask. An open zone transfer removes that barrier completely and gives an attacker the full map at once.

AXFR copies an entire DNS zone in one request
Designed for primary to secondary replication
The protocol has no authentication of its own
Must be restricted by IP allowlist or TSIG key
An open transfer discloses your complete internal naming inventory

Why Open Zone Transfers Are Dangerous

Reconnaissance is the slowest phase of most attacks. An attacker normally has to guess subdomain names, scrape certificate transparency logs and brute-force wordlists to build a picture of your infrastructure. An open AXFR hands that entire picture over instantly and silently.

What it reveals is often worse than the hostname list itself: internal naming conventions, staging and development environments that were never meant to be public, VPN and admin endpoints, backup servers, and the IP ranges where each of them lives. Every one of those is a candidate target that would otherwise have stayed hidden.

Reveals every hostname in the zone, including internal and staging systems
Exposes naming conventions that make further guessing trivial
Discloses IP ranges and infrastructure layout in one request
Surfaces admin panels, VPN endpoints and backup hosts
Flagged as a finding in essentially every professional security audit

How This Zone Transfer Test Works

The tool finds the authoritative nameservers for the domain and attempts an AXFR request against each one.

Validates the domain input against format and SSRF safety checks
Queries DNS for the NS records of the domain
Attempts an AXFR zone transfer request against each nameserver found
Reports which servers accepted the request and which correctly refused
Summarises how many records would have been exposed by a successful transfer

How to Use the Zone Transfer Test

Enter a domain you own or are authorised to test
Run the test to attempt AXFR against every authoritative nameserver
Review the result for each nameserver individually
Any server that accepted the transfer must be reconfigured immediately
Re-run the test after making changes to confirm the fix

Understanding Your Zone Transfer Results

Each nameserver is tested separately. Here is what each outcome means:

Field / Value	Meaning
`Transfer refused`	The correct and expected result. The nameserver rejected the anonymous AXFR request, meaning transfers are properly restricted to authorised secondaries.
`Transfer allowed`	A serious misconfiguration. This nameserver handed over the complete zone to an unauthenticated client. Restrict it immediately.
`Partial exposure`	Some nameservers refused while others allowed the transfer. The zone is fully exposed regardless — an attacker only needs one permissive server.
`Connection timeout`	The nameserver did not respond on TCP port 53. Zone transfers use TCP, and a firewall blocking it is an effective, if indirect, mitigation.
`Record count`	How many records a successful transfer returned. A large number indicates extensive infrastructure disclosure, though even a small zone reveals your naming scheme.

Common Problems & How to Fix Them

Your complete DNS zone is downloadable by any anonymous client. Restrict it now.

For BIND, add an allow-transfer clause naming only your secondary servers, or use a TSIG key:
allow-transfer { 203.0.113.10; 203.0.113.11; };

For PowerDNS, set allow-axfr-ips. For Windows DNS Server, open the zone properties, go to the Zone Transfers tab, and either disable transfers or limit them to the specific servers listed. Managed DNS providers block AXFR by default.

A single permissive server exposes the entire zone — an attacker simply asks that one. Mixed results are not partial protection.

Apply the same allow-transfer restriction consistently to every authoritative nameserver. This commonly happens when a new secondary is added without copying the security configuration from the existing ones.

The restriction is too tight and is now blocking your own legitimate secondaries.

Add the secondary server IP addresses to the allow-transfer list, or better, configure a TSIG key shared between primary and secondary. TSIG authenticates by cryptographic key rather than source address, which survives IP changes and cannot be spoofed.

Even with AXFR properly restricted, individual records remain queryable by anyone who guesses the name. Internal systems should not be in public DNS at all.

Use split-horizon DNS: publish only public-facing records in your external zone, and keep internal names on an internal resolver that is not reachable from the internet.

Best Practices

Restrict AXFR to your secondary nameservers by IP address, or disable it entirely
Use TSIG keys rather than IP allowlists so transfers are cryptographically authenticated
Apply the same restriction consistently across every authoritative nameserver
Keep internal hostnames out of public zones using split-horizon DNS
Test AXFR exposure after every nameserver change or provider migration
Include zone transfer testing in your regular security review cycle
Prefer managed DNS providers, which block anonymous transfers by default

Security Recommendations

Treat an open zone transfer as a high-severity finding and remediate it the same day
Assume that if AXFR was ever open, your zone has already been copied — review what was exposed rather than only closing the hole
Audit the zone for internal, staging and administrative hostnames that should never have been public
Use TSIG authentication rather than IP allowlists, since source addresses can be spoofed on some paths
Only test domains you own or are explicitly authorised to test — unauthorised AXFR attempts against third parties may be unlawful
Combine AXFR lockdown with DNSSEC, though be aware NSEC can itself permit zone walking — prefer NSEC3 where available

Frequently Asked Questions

A zone transfer, or AXFR, copies an entire DNS zone from a primary nameserver to a secondary. It is a legitimate replication mechanism, but the protocol has no built-in authentication, so servers must be explicitly configured to restrict who may request one.

It hands an attacker your complete infrastructure map in a single request — every hostname, internal server, staging environment and IP address. Work that would otherwise take extensive brute-force reconnaissance becomes instant and leaves almost no trace.

In BIND, use an allow-transfer clause listing only your secondaries. In PowerDNS, set allow-axfr-ips. In Windows DNS Server, use the Zone Transfers tab in the zone properties. Managed DNS providers block anonymous AXFR by default.

AXFR transfers the complete zone every time. IXFR transfers only the changes since the secondary last synchronised, which is far more efficient for large zones. Both must be restricted to authorised servers.

TSIG is a shared secret key used to sign DNS messages, defined in RFC 8945. It authenticates the requester cryptographically rather than by source address, so it cannot be defeated by spoofing and it keeps working when a secondary IP changes.

Only test domains you own or have explicit written authorisation to test. An AXFR request is a normal DNS query, but attempting it against third-party infrastructure without permission may constitute unauthorised access in many jurisdictions.

For bulk disclosure, yes. But individual records remain queryable by anyone who knows or guesses the name, and certificate transparency logs reveal many subdomains independently. Keep genuinely internal names out of public DNS entirely.