A DNS zone transfer (AXFR) is a mechanism designed to replicate the complete contents of a DNS zone from a primary nameserver to a secondary nameserver. When this transfer is not restricted, an attacker can request the full zone file with a single query and receive every DNS record for the domain — every subdomain, every IP address, every mail server, every service record. It is the most efficient DNS reconnaissance technique available.
I consider an unrestricted zone transfer the DNS equivalent of leaving your network diagram on a public bulletin board. It removes all guesswork from reconnaissance and gives the attacker a complete inventory of your infrastructure.
How Zone Transfers Work
DNS zone transfers exist for a legitimate purpose: keeping secondary (replica) nameservers synchronized with the primary.
AXFR (Full Zone Transfer)
When a secondary nameserver starts up or detects that its copy of the zone is outdated, it requests an AXFR from the primary. The primary responds by sending every record in the zone:
# The secondary nameserver requests the zone
dig axfr example.com @ns1.example.com
The response includes:
example.com. 3600 IN SOA ns1.example.com. admin.example.com. ...
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.
example.com. 3600 IN A 93.184.216.34
example.com. 3600 IN MX 10 mail.example.com.
admin.example.com. 3600 IN A 10.0.1.5
api.example.com. 3600 IN A 10.0.2.10
staging.example.com. 3600 IN CNAME staging-12345.herokuapp.com.
vpn.example.com. 3600 IN A 10.0.3.1
jenkins.example.com. 3600 IN A 10.0.4.20
db-primary.example.com. 3600 IN A 10.0.5.100
...
example.com. 3600 IN SOA ns1.example.com. admin.example.com. ...
Every record. In one response. Including internal hostnames, private IP addresses, staging environments, and service infrastructure that the attacker could not have discovered through brute-force enumeration.
IXFR (Incremental Zone Transfer)
IXFR transfers only the changes since the last synchronization, which is more efficient. However, an attacker with an IXFR capability can still extract significant information, and many misconfigured servers allow both AXFR and IXFR.
What an Attacker Learns
A successful zone transfer reveals:
- All subdomains — including internal names like
vpn,staging,jenkins,gitlab,db-primary,admin,intranet - IP addresses — including private RFC 1918 addresses that reveal internal network structure
- Mail servers — MX records and their priorities, useful for email-targeted attacks
- CNAME targets — revealing which cloud services are in use (and potential subdomain takeover targets)
- TXT records — SPF configurations, domain verification tokens, and sometimes sensitive metadata
- SRV records — revealing specific services and their ports (LDAP, SIP, Kerberos)
- SOA details — administrator email addresses and zone serial numbers
This information dramatically accelerates further attacks. Instead of blind subdomain brute-forcing (which might discover www and mail), the attacker now knows about jenkins.example.com, db-primary.example.com, and every other subdomain.
How Attackers Discover This Weakness
Testing for zone transfer vulnerabilities is trivial:
# Step 1: Find the nameservers
dig NS example.com +short
# Returns: ns1.example.com, ns2.example.com
# Step 2: Attempt AXFR against each nameserver
dig axfr example.com @ns1.example.com
dig axfr example.com @ns2.example.com
If the server responds with records instead of a "Transfer failed" or "REFUSED" message, the zone is exposed. This test takes seconds and is one of the first things any security auditor or penetration tester checks.
Automated reconnaissance tools like dnsrecon, fierce, and dnsenum include zone transfer checks as a standard first step.
How to Test Your Own Domain
You should test every nameserver for your domain from an external IP address:
# Get all nameservers
dig NS yourdomain.com +short
# Test each one
dig axfr yourdomain.com @ns1.yourdomain.com
dig axfr yourdomain.com @ns2.yourdomain.com
Expected secure response:
; Transfer failed.
or
;; WARNING: AXFR query refused
Vulnerable response: Any output that includes zone records.
You can also use the DNS Inspector to examine your nameserver configuration and verify that your DNS records are what you expect.
Test All Nameservers
A common mistake is securing one nameserver but leaving another open. Test every NS record, including any hidden or legacy nameservers.
How to Defend Against It
Restrict Zone Transfers with ACLs
The primary defense is restricting zone transfers to only your authorized secondary nameservers:
BIND:
options {
allow-transfer { 198.51.100.10; 203.0.113.20; };
};
// Or per-zone:
zone "example.com" {
type master;
allow-transfer { 198.51.100.10; 203.0.113.20; };
};
PowerDNS:
allow-axfr-ips=198.51.100.10,203.0.113.20
NSD:
zone:
name: "example.com"
provide-xfr: 198.51.100.10 NOKEY
provide-xfr: 203.0.113.20 NOKEY
Use TSIG Authentication
Transaction Signatures (TSIG) add cryptographic authentication to zone transfer requests. Even if an attacker knows the secondary nameserver's IP, they cannot complete the transfer without the shared secret:
# BIND TSIG configuration
key "transfer-key" {
algorithm hmac-sha256;
secret "base64-encoded-secret";
};
server 198.51.100.10 {
keys { transfer-key; };
};
zone "example.com" {
type master;
allow-transfer { key transfer-key; };
};
TSIG is the recommended approach because it authenticates the request regardless of source IP, providing defense against IP spoofing.
Disable Zone Transfers Entirely
If you do not use secondary nameservers (for example, if your DNS provider handles replication internally), disable zone transfers completely:
# BIND
options {
allow-transfer { none; };
};
Audit Regularly
Schedule periodic tests from external IP addresses. Include zone transfer checks in your security audit checklist. Changes to nameserver configurations can inadvertently re-enable transfers.
Mitigation Checklist
- Zone transfers restricted to specific secondary nameserver IPs
- TSIG authentication configured for zone transfers
- Every nameserver for every zone tested from an external IP
- Zone transfer restrictions verified after any nameserver configuration change
- Hidden or legacy nameservers checked and secured
- Monitoring alerts if zone transfer restrictions are modified
- Zone contents reviewed — remove records that expose unnecessary internal information
Common Misconfigurations
- Default configuration left in place — many DNS server packages allow zone transfers from any source by default
- Securing the primary but not the secondary — all nameservers must restrict transfers, not just the primary
- IP-based ACLs without TSIG — IP addresses can be spoofed; TSIG provides cryptographic authentication
- Forgetting to test after changes — a configuration update or server migration re-enables unrestricted transfers
- Hidden nameservers — old or forgotten nameservers that still serve the zone but are not in the public NS records
Ethical Note
Zone transfer testing against domains you do not own is a common early step in penetration testing, but it should only be performed with authorization. While sending an AXFR query to a public server is technically just sending a DNS query, using the obtained information for unauthorized purposes is not legal. Only test your own domains or domains you have written authorization to assess.
This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Zone Walking, DNS Hijacking.