DNS Zone Transfer Vulnerability (AXFR): How Attackers Download Your Entire DNS

What is a DNS zone transfer?

A DNS zone transfer (AXFR) is a mechanism for replicating DNS data from a primary name server to secondary name servers. When a secondary server needs a copy of the DNS zone, it sends an AXFR request to the primary, which responds with every record in the zone -- every A record, CNAME, MX, TXT, and more.

This is a legitimate and essential part of DNS infrastructure. The problem occurs when zone transfers are allowed to anyone who asks, not just your authorised secondary name servers.

Why unrestricted zone transfers are dangerous

An unrestricted zone transfer hands an attacker your complete DNS inventory in a single query. Instead of guessing subdomains one at a time, they get everything:

• Every subdomain (including internal tools, staging servers, admin panels)
• Every IP address your subdomains point to
• Every mail server (MX records)
• All TXT records (SPF, DKIM, domain verification tokens)
• Internal naming conventions that reveal your infrastructure layout
• Records that reference internal IP ranges (RFC 1918 addresses)

This information dramatically accelerates the reconnaissance phase of an attack. What might take days of subdomain enumeration takes seconds with a zone transfer.

How to test if your DNS is vulnerable

Using dig

# Find your name servers
dig NS yourcompany.com +short

# Attempt a zone transfer against each name server
dig AXFR yourcompany.com @ns1.yourdns.com

# If it returns all your DNS records, you are vulnerable
# If it returns "Transfer failed" or times out, you are protected

Using host

host -t AXFR yourcompany.com ns1.yourdns.com

Using nmap

nmap --script dns-zone-transfer -p 53 ns1.yourdns.com

What a successful zone transfer looks like

If the transfer succeeds, you will see output like this:

yourcompany.com.        3600  IN  SOA   ns1.yourdns.com. admin.yourcompany.com. ...
yourcompany.com.        3600  IN  A     203.0.113.10
yourcompany.com.        3600  IN  MX    10 mx1.mail-provider.com.
admin.yourcompany.com.  3600  IN  A     203.0.113.20
staging.yourcompany.com. 3600 IN  A     203.0.113.30
vpn.yourcompany.com.    3600  IN  A     203.0.113.40
internal-api.yourcompany.com. 3600 IN A 10.0.1.50
_dmarc.yourcompany.com. 3600  IN  TXT   "v=DMARC1; p=reject; ..."
yourcompany.com.        3600  IN  TXT   "v=spf1 include:..."

Every record in your zone, laid out for the attacker.

How to prevent zone transfers

If you manage your own name servers (BIND)

Edit named.conf to restrict zone transfers to specific IPs:

options {
    // Disable zone transfers globally
    allow-transfer { none; };
};

zone "yourcompany.com" {
    type master;
    file "/etc/bind/zones/yourcompany.com.zone";

    // Only allow transfers to your secondary name servers
    allow-transfer {
        203.0.113.2;    // ns2.yourdns.com
        203.0.113.3;    // ns3.yourdns.com
    };

    // Optionally, also restrict notifications
    also-notify {
        203.0.113.2;
        203.0.113.3;
    };
};

Reload BIND:

sudo rndc reload

If you use PowerDNS

In pdns.conf:

allow-axfr-ips=203.0.113.2/32,203.0.113.3/32
disable-axfr=no

If you do not need zone transfers at all (e.g., you use a single authoritative server or API-based DNS management):

disable-axfr=yes

If you use NSD

In nsd.conf:

zone:
    name: "yourcompany.com"
    zonefile: "yourcompany.com.zone"
    provide-xfr: 203.0.113.2 NOKEY
    provide-xfr: 203.0.113.3 NOKEY

NSD denies transfers by default unless provide-xfr is configured, which is secure by default.

If you use a managed DNS provider

Most managed DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS) disable zone transfers entirely by default. They use proprietary replication mechanisms instead of AXFR.

If you use a managed provider and are still seeing zone transfer vulnerability, check whether you have a legacy name server alongside your managed DNS that still allows AXFR.

Using TSIG for authenticated transfers

If you need zone transfers between servers, use TSIG (Transaction Signature) to authenticate requests:

// Generate a TSIG key
dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST transfer-key

// In named.conf
key "transfer-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-key-here";
};

zone "yourcompany.com" {
    type master;
    file "/etc/bind/zones/yourcompany.com.zone";
    allow-transfer { key "transfer-key"; };
};

The secondary server must present the same key to receive the transfer.

Verify the fix

After restricting zone transfers, test again from an external machine:

# This should now fail
dig AXFR yourcompany.com @ns1.yourdns.com

# Expected output:
# ; Transfer failed.

Test from each of your name servers to be thorough:

for ns in $(dig NS yourcompany.com +short); do
  echo "Testing $ns..."
  dig AXFR yourcompany.com @$ns
  echo "---"
done

Zone transfers and your broader DNS security

Zone transfer exposure often co-exists with other DNS issues. If your name servers are misconfigured enough to allow AXFR, check for:

• Orphan DNS records pointing to resources you no longer control
• Subdomain takeover opportunities on CNAME records
• Stale TXT records leaking vendor information

A complete DNS audit covers all of these.

How SurfaceScan helps

SurfaceScan tests every authoritative name server for your domains against zone transfer vulnerabilities on each scan. An AXFR exposure is flagged as high severity because of the reconnaissance value it provides to attackers. The finding includes which name server is vulnerable and step-by-step remediation guidance for your specific DNS infrastructure.