DNS Zone Transfer Attacks: AXFR Exploitation and Defense in 2026

DNS zone transfer vulnerabilities should not exist in 2026. The misconfiguration is thirty years old, the fix is one directive in the name-server configuration, and every security framework from PCI DSS to CIS Benchmarks explicitly calls out unrestricted AXFR as a finding. And yet every external reconnaissance phase of every pentest still routinely discovers them — on corporate domains, government infrastructure, legacy hosting providers, and surprisingly often on authoritative servers for high-traffic SaaS products. This document explains the attack, the detection workflow, the exploitation value, and the defensive controls that actually hold.

What a Zone Transfer Is, and Why It Exists

DNS zone transfer (AXFR) is a legitimate protocol feature. The AXFR query, defined in RFC 5936, requests the full contents of a DNS zone from an authoritative server. The intended use is replication between primary and secondary name servers — the secondary pulls the zone from the primary to stay in sync with authoritative data. The IXFR variant (RFC 1995) supports incremental transfers but behaves similarly from an authorisation standpoint. Both are DNS-over-TCP operations because zone data typically exceeds UDP response size limits.

The protocol as specified does not require authentication. The expectation is that name server operators restrict AXFR to specific IP addresses — the known secondaries. When this restriction is missing or misconfigured, any client that can reach the server over TCP/53 can request the entire zone. The server returns every record: A, AAAA, MX, TXT, CNAME, SRV, NS, SOA. For an attacker performing reconnaissance, this is a complete internal network map handed over in a single query.

The Information Value of a Successful Transfer

A successful zone transfer leaks more than subdomain names. The zone contains the complete authoritative DNS record set, which typically reveals internal hostname conventions (mail.corp.example.com, vpn-us-east.example.com, jenkins.internal.example.com), service inventories (SRV records indicating Kerberos realms, LDAP endpoints, SIP infrastructure), email infrastructure (MX records plus SPF/DKIM/DMARC TXT records), and often legacy hosts that have no active DNS lookups but still appear in the zone file.

The attacker uses this inventory in three ways. First, as the subdomain-enumeration shortcut — one AXFR query replaces hours of brute-forced subdomain discovery. Second, as the internal-infrastructure map — hostname conventions reveal naming patterns, environment segmentation, and often security tooling (sumo.example.com, splunk.example.com, elastic.example.com indicate the logging stack). Third, as the authentication target list — once the attacker sees the exact VPN, mail, and SSO endpoints, phishing campaigns and credential stuffing attacks become targeted rather than speculative.

Zone transfers also frequently reveal infrastructure the organisation forgot existed. Development environments pointed to old IP ranges. Decommissioned services whose DNS was never cleaned up. Hosts belonging to acquired companies that were merged into the parent domain. Each of these is a candidate for subdomain takeover, legacy-system exploitation, or supply-chain pivot.

Detection: dig, nslookup, and host

The classical detection sequence uses dig. First, enumerate authoritative name servers:

dig +short NS example.com

Then attempt an AXFR against each name server:

dig axfr example.com @ns1.example.com
dig axfr example.com @ns2.example.com

A successful transfer returns the full zone contents starting with the SOA record. A refused transfer returns the message "Transfer failed" or a response code of REFUSED. In either case the response arrives quickly — zone transfers are either allowed or they are not, with no middle ground.

The nslookup equivalent is less commonly used but still works. Enter interactive mode, set the type to any, specify the server, and issue the ls command:

nslookup
> server ns1.example.com
> set type=any
> ls -d example.com

The host command offers the simplest syntax:

host -l example.com ns1.example.com

For automated enumeration across multiple domains, tools like dnsrecon, fierce, and dnsenum wrap these primitives with better output formatting and support for discovered-secondary enumeration. The zonetransfer.me test domain is maintained specifically as a safe target for testing zone transfer tooling — a vulnerable zone with intentional misconfigurations against which security practitioners can validate their workflow without touching production targets.

Why the Misconfiguration Persists

The attack has been documented for thirty years and the fix is trivial. Three dynamics explain why it still appears in the wild. First, legacy name server deployments where the configuration was correct for the original secondary set but was never updated when the infrastructure moved to cloud-hosted DNS. The zone transfer directive still allows the original IPs — which are now reused by someone else, or no longer exist, but the broader allow-all configuration from the original setup never got tightened.

Second, misunderstanding of hosted DNS defaults. Teams that moved to Route 53, Cloudflare, or similar managed DNS assume zone transfer is handled by the provider. In most managed DNS setups it is — but when organisations run self-hosted BIND or PowerDNS for internal zones while using managed DNS for external zones, the internal servers often retain default-permissive configurations.

Third, acquired-infrastructure drift. The parent organisation's security team may have strong DNS controls, but an acquired company's legacy name servers remain in operation with the original misconfigurations until an infrastructure consolidation project catches them. Pentest findings on acquired domains routinely surface zone transfer issues that are months or years old relative to the acquisition date.

The Compliance Framing

PCI DSS Requirement 11.2 (vulnerability scanning) and Requirement 11.4 (penetration testing) both routinely flag unrestricted AXFR as a finding. QSAs treat zone transfer leakage as a confirmed vulnerability during assessments and expect remediation evidence before certification. SOC 2 auditors reference the same finding under the CC6 series common criteria when it appears in testing evidence.

CIS Benchmarks for DNS server hardening explicitly require restricting zone transfers to known secondaries. The relevant benchmark controls are DNS 2.1 through 2.3 depending on server platform. ISO 27001 Annex A.13.1 (network security management) is the broader control that zone-transfer restriction maps to, though the mapping is less explicit than the CIS reference.

For GDPR purposes, unrestricted zone transfer that leaks internal hostname inventories can be argued as a confidentiality failure of the integrity-and-availability processing-system requirement under Article 32. The argument is weaker than for direct personal-data exposure, but regulators have cited DNS misconfiguration in enforcement actions when combined with other security hygiene failures.

Defensive Configuration

For BIND, zone transfer restriction uses the allow-transfer directive. The configuration should list only the known secondary name server IPs (or TSIG keys, preferred):

zone "example.com" {
    type master;
    file "example.com.zone";
    allow-transfer { 203.0.113.5; 198.51.100.7; };
};

For TSIG-authenticated transfers (preferred for defence in depth), the configuration references a shared key:

key "transfer-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-secret";
};

zone "example.com" {
    type master;
    allow-transfer { key "transfer-key"; };
};

PowerDNS uses the allow-axfr-ips configuration directive with similar semantics. NSD uses the provide-xfr directive. For managed DNS providers (Route 53, Cloudflare, NS1), zone transfer is typically disabled by default and must be explicitly enabled per zone — verify the configuration on migration rather than assuming the default holds.

Network-level controls add defence in depth. Firewalls should block inbound TCP/53 from external networks except from known secondary IPs. This control catches the misconfigured name server before the DNS layer gets a chance to decline — valuable because configuration drift happens and defence in depth should assume the application-layer control fails.

Monitoring and Detection in Production

Successful zone transfer attempts should produce log evidence. BIND logs AXFR requests in the transfers log channel; PowerDNS logs them to the main server log. The log line includes the requesting client IP and the zone name. Operations teams should alert on any AXFR request from an unexpected source — the volume is low enough that each alert is actionable rather than noise.

External monitoring complements internal logging. Periodic scans from an external vantage point validate that the server rejects AXFR requests from unauthorised sources. Many commercial external attack surface management tools include this check; the free alternative is a scheduled dig axfr query from a monitoring host that alerts if the response changes from refused to allowed.

Related Attacks and Modern Variations

DNS zone transfer sits at the start of a broader DNS attack surface. Related attacks include DNS cache poisoning (injecting malicious records into resolvers), DNS tunnelling (exfiltrating data through DNS queries), and subdomain takeover (claiming orphaned DNS records that point to decommissioned cloud resources). Each is a separate control concern but all share the DNS infrastructure as the attack surface.

The modern reconnaissance variant of zone-transfer-equivalent data collection uses certificate transparency logs instead. CT logs are public records of every TLS certificate issued, which effectively reveals every hostname an organisation has ever requested a certificate for. Tools like crt.sh query CT logs for a domain and return the complete hostname inventory. For attackers, this has largely replaced zone transfer attempts as the primary subdomain enumeration technique — but zone transfer remains valuable because it reveals internal hostnames that never got TLS certificates and legacy infrastructure that CT logs would not have captured.

The practical reconnaissance workflow in 2026 combines both — CT log enumeration via crt.sh and similar tools, plus zone transfer attempts against discovered authoritative name servers. The two sources together produce a more complete inventory than either alone. Defenders should assume both are being used against every production domain.

What Pentest Reports Should Say

A pentest finding on DNS zone transfer should include four elements: the specific name servers that allowed the transfer, a redacted sample of the zone contents to demonstrate the information leakage, the specific IPs or networks from which the transfer succeeded, and the remediation configuration appropriate to the DNS platform. Reports that call out zone transfer as a finding without the exploitation evidence often fail to drive remediation urgency; reports that include the sample zone data consistently drive faster fix cycles.

For continuous testing programmes, zone transfer should be re-tested after any DNS infrastructure change — migration between providers, addition of new authoritative servers, acquisition of new domains — because the configuration pattern that produces the vulnerability recurs at each change event. Programmes that only test zone transfer at the initial engagement miss the vulnerability when it is reintroduced by subsequent changes.