DNS Zone Transfer

Description

A DNS zone transfer (AXFR) is a replication mechanism designed to synchronize DNS data between a primary and secondary nameserver. When a DNS server is misconfigured to allow zone transfers from arbitrary clients, any attacker can request a full dump of every DNS record in the zone—hostnames, IP addresses, mail servers, and internal subdomains alike.

This misconfiguration falls under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) because the DNS zone file is effectively a roadmap of an organization's infrastructure. Records such as vpn.internal.example.com, dev-db.example.com, or staging-api.example.com give attackers precise targets for follow-on reconnaissance and exploitation, collapsing what would otherwise take hours of brute-force subdomain enumeration into a single query.

Zone transfer vulnerabilities are most common on legacy BIND installations, self-managed Windows DNS servers, and environments where split-horizon DNS was never properly enforced. Despite being a well-known misconfiguration for over two decades, it continues to appear in penetration testing engagements across financial services, healthcare, and government sectors.

How It Works

An attacker identifies the authoritative nameservers for a target domain using standard DNS queries, then issues an AXFR request directly to each one.

# Step 1 — identify authoritative nameservers
dig NS example.com

# Step 2 — attempt zone transfer against each nameserver
dig AXFR example.com @ns1.example.com

# Alternative using dnsenum (automates multi-NS attempts)
dnsenum --dnsserver ns1.example.com --enum example.com

A successful transfer returns every record in the zone:

example.com.          3600  IN  SOA   ns1.example.com. hostmaster.example.com. ...
vpn.example.com.      300   IN  A     10.0.1.5
dev-db.example.com.   300   IN  A     10.0.2.12
jenkins.example.com.  300   IN  A     203.0.113.44
mail.example.com.     3600  IN  MX    10 mailhost.example.com.

Tools like fierce, dnsrecon, and Amass also automate AXFR attempts as part of broader DNS reconnaissance workflows.

Impact

• Infrastructure mapping — Complete enumeration of all subdomains, IP addresses, and service endpoints without any brute-force noise.
• Targeted attack planning — Exposed records like jenkins.example.com or kibana.example.com identify high-value, often internet-facing internal tools.
• Phishing enablement — Mail server records (MX, SPF, DMARC) help attackers craft convincing spoofed emails.
• Internal network exposure — Private RFC 1918 IP addresses in A records map the internal network topology.
• Competitive intelligence — Zone contents reveal acquisitions, internal project names, and infrastructure providers before public disclosure.

Detection

1. Query each authoritative nameserver for the target domain using dig AXFR <domain> @<nameserver> and record whether a full record set is returned.
2. Use dnsrecon -d example.com -t axfr to automate testing across all NS records simultaneously.
3. Check for IXFR (incremental zone transfer) support as a secondary vector: dig IXFR=0 example.com @ns1.example.com.
4. Test from multiple source IP addresses to determine whether ACLs restrict transfers to specific ranges (partial mitigation) or allow all sources.
5. Review the BIND named.conf or Windows DNS server configuration for allow-transfer { any; }; directives.
6. Include internal/split-horizon nameservers in scope—internal DNS may be more permissive than public-facing servers.

Remediation

Restrict zone transfers with ACLs. Configure nameservers to allow AXFR only from known secondary server IP addresses. In BIND:

zone "example.com" {
    type primary;
    allow-transfer { 192.0.2.10; 192.0.2.11; };
};

Use TSIG authentication. Transaction signatures cryptographically authenticate zone transfer requests between primary and secondary servers, preventing spoofed ACL bypass.

Audit all nameservers. Ensure both primary and any legacy secondary nameservers enforce the same transfer restrictions—misconfigurations often persist on forgotten secondaries.

Implement DNSSEC. While it does not prevent zone transfers directly, DNSSEC with NSEC3 hashing reduces the value of enumerated data.