DNS Zone Transfer Attacks: How Exposed AXFR Leaks Your DNS Map

Introduction

A DNS zone transfer is not an attack by itself. It is a normal DNS replication mechanism used to copy zone data from one authoritative name server to another.

The problem starts when a public authoritative DNS server allows anyone on the internet to request a full zone transfer. That request can return hostnames, mail records, service records, subdomains, internal naming patterns, stale infrastructure, and records that were never meant to be easy to enumerate.

For attackers, an exposed zone transfer turns DNS into an asset inventory leak. Instead of guessing subdomains with wordlists or waiting for certificate logs, they can ask the name server for the zone and receive a structured list of records.

This deep-dive explains how DNS zone transfer attacks work, what exposed AXFR responses reveal, how to test your own domains safely, and how to fix the DNS configuration before it becomes an attack-chain starting point.

How DNS zone transfers work at the protocol level

A DNS zone is the set of records an authoritative DNS server serves for a domain or delegated subdomain. For example, example.com may have A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA, and other records.

A zone transfer is a DNS operation that copies zone data from one authoritative server to another. AXFR is a full transfer of the zone, while IXFR transfers changes between zone serial versions when both sides support incremental transfer.

In normal operation, AXFR is transferred over TCP because the response may contain many DNS records and must be delivered reliably.

In a healthy setup, zone transfers are allowed only between trusted authoritative servers. For example, a primary name server may allow a secondary name server to pull zone data so both can answer DNS queries for the same zone.

A DNS zone transfer attack happens when an unauthorized client can request that same transfer and receive the zone data.

How attackers exploit exposed AXFR step by step

A zone transfer attack usually begins with normal DNS reconnaissance. The attacker identifies the authoritative name servers for a domain, then asks each server whether it will return a full zone transfer.

The request is simple. AXFR is a DNS query type, and tools like dig can request it directly.

For an authorized test against a domain you own, the command looks like this:

```bash dig AXFR example.com @ns1.example.com ```

A secure server should refuse the transfer, time out, or return a failure response to unauthorized clients. A vulnerable server returns zone records.

The risk is not that AXFR exists. The risk is unauthorized AXFR from the internet.

What attackers can learn from exposed zone transfers

A zone transfer does not usually expose application data directly. It exposes the map.

That map can still be valuable. DNS records often reveal naming conventions, environments, third-party providers, forgotten systems, mail infrastructure, VPN names, admin surfaces, API hosts, staging systems, and old records that should have been removed.

A leaked zone can also speed up other attacks. It gives attackers a high-confidence subdomain list, which they can use for service probing, takeover checks, phishing infrastructure, login discovery, and attack-chain mapping.

Example vulnerable output may look like this:

```text example.com. 3600 IN SOA ns1.example.com. dns-admin.example.com. 2026051001 3600 600 1209600 300 example.com. 3600 IN NS ns1.example.com. example.com. 3600 IN NS ns2.example.com. example.com. 3600 IN MX 10 mail.example.com. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none" api.example.com. 3600 IN A 203.0.113.20 admin.example.com. 3600 IN A 203.0.113.30 staging-api.example.com. 3600 IN A 203.0.113.40 vpn.example.com. 3600 IN A 203.0.113.50 old-app.example.com. 3600 IN CNAME abandoned.vendor.example. jenkins.example.com. 3600 IN A 203.0.113.60 ```

The attacker now has a better target list than a brute-force wordlist would provide.

What the vulnerable DNS configuration looks like

Most modern managed DNS providers do not allow public AXFR by default. Zone transfer exposure is more common in self-hosted DNS, legacy DNS deployments, migration setups, split-horizon mistakes, and incorrectly configured secondary DNS relationships.

The root cause is usually simple: the authoritative server is configured to allow transfers too broadly.

A dangerous BIND-style pattern looks like this:

```conf zone "example.com" { type primary; file "/etc/bind/zones/db.example.com"; allow-transfer { any; }; }; ```

That tells the server to allow zone transfers from any client. A safer pattern restricts transfers to trusted secondary servers and, where possible, authenticates them with TSIG.

TSIG does not encrypt the zone data. It authenticates DNS messages so the server can distinguish approved transfer partners from unauthorized clients.

Another common failure is fixing one authoritative server but forgetting another. Attackers only need one name server in the delegation set to allow AXFR.

• allow-transfer set to any — The server allows full zone transfer requests from any client.
• No transfer ACL — The zone lacks an explicit allowlist for approved secondary servers.
• Secondary DNS migration — Temporary broad transfer rules are added during migration and never removed.
• Legacy BIND or self-hosted DNS — Old configurations can preserve permissive transfer behavior across upgrades.
• Multiple authoritative servers — One name server may be locked down while another still allows transfer.
• No TSIG for transfers — IP allowlisting alone may be weaker than authenticated transfer relationships.
• Split-horizon confusion — Internal-style records may be published or transferred through the wrong view or zone.

How to detect DNS zone transfer exposure in your environment

Only test domains you own or have explicit permission to assess.

Start by finding the authoritative name servers:

```bash dig NS example.com +short ```

Example output:

```text ns1.example.com. ns2.example.com. ```

Then test each authoritative server directly:

```bash dig AXFR example.com @ns1.example.com dig AXFR example.com @ns2.example.com ```

A refused transfer may look like this:

```text ; Transfer failed. ```

Or:

```text ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12345 ```

A vulnerable transfer returns zone records. If you see many records ending in the tested zone name, treat it as confirmed exposure and restrict access immediately.

Do not test arbitrary third-party domains. AXFR testing is a low-volume DNS query, but it is still an active request against someone else’s authoritative infrastructure.

Testing every authoritative server

A common mistake is testing only the first name server. DNS delegations usually list multiple authoritative servers, and any one of them can be misconfigured.

Use a loop for domains you own:

```bash for ns in $(dig NS example.com +short); do echo "\n== Testing $ns ==" dig AXFR example.com @$ns +time=5 +tries=1 done ```

For cleaner output, show only a summary:

```bash for ns in $(dig NS example.com +short); do count=$(dig AXFR example.com @$ns +time=5 +tries=1 2>/dev/null | grep -E "\sIN\s" | wc -l | tr -d ' ') echo "$ns,$count" done ```

A secure result usually returns zero transferred records or an error condition. A high record count is a signal to investigate.

Be careful with false interpretation. Some servers may return SOA-like failure responses, some may time out, and some may return errors through resolvers. Always query authoritative servers directly.

What a vulnerable result looks like

A successful unauthorized AXFR response is usually obvious because the server returns many records from the zone.

Example:

```bash dig AXFR example.com @ns1.example.com ```

Vulnerable output:

```text example.com. 3600 IN SOA ns1.example.com. dns-admin.example.com. 2026051001 3600 600 1209600 300 example.com. 3600 IN NS ns1.example.com. example.com. 3600 IN NS ns2.example.com. www.example.com. 3600 IN A 203.0.113.10 api.example.com. 3600 IN A 203.0.113.20 admin.example.com. 3600 IN A 203.0.113.30 staging.example.com. 3600 IN A 203.0.113.40 old-crm.example.com. 3600 IN CNAME old-crm.vendor.example. ```

The immediate finding is unauthorized zone transfer. The follow-up work is asset review. Every record returned should be checked for owner, purpose, exposure reason, and whether it still belongs in public DNS.

Do not paste full zone output into broad tickets or chat channels if it contains sensitive infrastructure naming. Share only the minimum evidence needed for the DNS owner to reproduce and fix.

What a secure result looks like

A locked-down authoritative server refuses unauthorized transfer attempts.

Example:

```bash dig AXFR example.com @ns1.example.com ```

Secure output may look like this:

```text ; Transfer failed. ```

Or:

```text ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 48211 ```

A timeout can also happen depending on firewall and server behavior:

```text ;; communications error to 203.0.113.53#53: timed out ```

Refused, denied, or timed-out AXFR from unauthorized locations is expected. Normal DNS record lookups such as A, MX, TXT, NS, and SOA should still work for public zones.

Remediation — exact DNS zone transfer fixes

The correct fix is to allow zone transfers only to trusted secondary name servers. If you do not use secondary DNS, disable zone transfers entirely.

Do not rely only on secrecy of hostnames. Treat the AXFR exposure as a DNS access-control issue first, then review the leaked records as asset inventory.

After you fix the config, test every authoritative server from an external network.

BIND configuration examples

BIND configurations vary by version and deployment style, but the core pattern is consistent: do not allow transfers from everyone.

Unsafe example:

```conf zone "example.com" { type primary; file "/etc/bind/zones/db.example.com"; allow-transfer { any; }; }; ```

Safer IP-restricted example:

```conf acl "trusted-secondary" { 198.51.100.10; 198.51.100.11; }; zone "example.com" { type primary; file "/etc/bind/zones/db.example.com"; allow-transfer { trusted-secondary; }; }; ```

Safer TSIG-authenticated example:

```conf key "xfr-secondary-key" { algorithm hmac-sha256; secret "BASE64_SHARED_SECRET_HERE"; }; server 198.51.100.10 { keys { "xfr-secondary-key"; }; }; zone "example.com" { type primary; file "/etc/bind/zones/db.example.com"; allow-transfer { key "xfr-secondary-key"; }; }; ```

Some older BIND configurations use type master instead of type primary. Apply the same transfer restriction pattern for whichever syntax your BIND version supports.

Generate and store TSIG secrets securely. Rotate them when DNS server ownership changes, when a secondary provider changes, or when you suspect exposure.

NSD, Knot DNS, and PowerDNS notes

The exact syntax changes by DNS server, but the security rule stays the same: define approved transfer targets and refuse everyone else.

For NSD, use access-control settings for the zone and restrict AXFR to trusted secondary addresses, preferably with TSIG.

For Knot DNS, configure ACL rules for transfer actions and apply them to the zone. Use key-based authentication where supported.

For PowerDNS Authoritative Server, restrict transfers using allow-axfr-ips, per-zone metadata, TSIG controls, or provider-specific mechanisms depending on your backend and deployment.

Do not copy examples blindly between DNS products. Use the official documentation for the server you run, then validate externally.

Why DNS zone transfer exposure matters beyond DNS

Zone transfer exposure is often treated as an information disclosure bug, but the downstream risk depends on what the zone reveals.

A leaked zone can turn into an attack-chain input. It can expose staging systems, admin panels, VPN names, remote access services, old CNAMEs, weak email authentication, and provider relationships.

The highest-risk records are usually not the obvious production website. They are records that nobody remembers owning.

After closing AXFR, review the returned zone data as an asset cleanup task.

How to prioritize DNS zone transfer findings

Unauthorized AXFR should be fixed quickly because the configuration error is usually easy to correct and the leaked data improves attacker reconnaissance.

Prioritize faster when the returned records include admin panels, VPNs, CI/CD systems, databases, staging services, cloud storage, old vendor CNAMEs, or weak email authentication clues.

Also prioritize faster when multiple authoritative servers allow transfer, when the zone contains many unknown assets, or when the domain is used for production customer workflows.

After the transfer is blocked, triage the leaked records like any external attack surface inventory.

How ExternalSight helps detect zone transfer exposure

ExternalSight includes a zone transfer scanner as part of its external attack surface monitoring workflow for internet-facing domains.

The scanner checks whether authoritative DNS servers expose zone transfer behavior and helps classify the result as a DNS security finding. ExternalSight also includes related DNS, subdomain, certificate transparency, subdomain takeover, email spoofing, exposed services, admin panel, ports, WHOIS, passive DNS, Shodan, OTX, and attack-chain evaluation scanners.

That matters because zone transfer exposure is rarely isolated. A successful AXFR result can feed subdomain discovery, takeover review, login-surface discovery, exposed-service checks, and attack-chain analysis.

Findings can be included in remediation planning, score and coverage reporting, historical comparison, alerts, and exports. Continuous monitoring is available for verified domains on supported plans.

Some external-source checks may report unavailable when API keys or upstream services are not configured. Review scan coverage before treating a clean scan as a clean surface.

ExternalSight does not replace DNS provider controls, DNS administrator review, penetration testing, SIEM, SOC, WAF, or cloud security controls. Its role here is to help teams detect externally visible zone transfer exposure and monitor verified domains for DNS drift.

Real-world incidents and advisories

DNS zone transfer exposure is tracked in public vulnerability and attack-pattern sources. NVD lists CVE-1999-0532 with the description “A DNS server allows zone transfers.”

MITRE CAPEC-291 describes zone transfer as an attack pattern where a DNS misconfiguration allows transfer of zone data and may return IP addresses and valid hostnames.

MYCERT advisory MA-469.042015 also warned that AXFR requests may disclose domain information and referenced CVE-1999-0532.

The practical lesson is that this is not only a theoretical misconfiguration. It is a long-known DNS exposure pattern that still appears because DNS is old, distributed, and often touched during migrations, secondary DNS setup, and legacy infrastructure changes.

Public DNS records are expected. Public full-zone replication is not. Authoritative servers should answer normal DNS queries while refusing unauthorized transfers.

Key takeaways

• {'text': 'A DNS zone transfer is a normal replication mechanism, but unauthorized AXFR from the internet is a security exposure.'}
• {'text': 'A successful zone transfer can leak subdomains, mail records, service records, stale CNAMEs, admin surfaces, staging systems, and infrastructure naming patterns.'}
• {'text': 'Test every authoritative name server because one misconfigured server is enough to expose the zone.'}
• {'text': 'Fix the root cause by allowing transfers only to trusted secondary servers and using TSIG authentication where supported.'}
• {'text': 'After blocking AXFR, review the leaked records as external asset inventory and clean up stale or sensitive records.'}
• {'text': 'Continuous DNS monitoring matters because zone transfer exposure can reappear during DNS migrations, provider changes, and secondary DNS setup.'}

Frequently asked questions

What is a DNS zone transfer attack?

A DNS zone transfer attack happens when an unauthorized client requests a full zone transfer, usually AXFR, from an authoritative name server and receives the zone’s DNS records. Zone transfer is normal between trusted DNS servers; the dangerous condition is allowing unauthorized clients on the internet to perform it.

How do I test if my domain allows zone transfer?

Find your authoritative name servers with dig NS example.com +short, then test each one directly with dig AXFR example.com @nameserver. Run this only for domains you own or have permission to assess.

What should a secure DNS server return for AXFR?

For unauthorized clients, a secure server should refuse, deny, fail, or time out the AXFR request. It should not return the full zone. Normal DNS lookups like A, MX, TXT, NS, and SOA should still work.

How do I fix exposed DNS zone transfers?

Disable zone transfers if you do not use secondary DNS. If you do use secondary DNS, restrict transfers to approved secondary servers and use TSIG authentication where supported. Then test every authoritative server from an external network.

How does ExternalSight help with DNS zone transfer exposure?

ExternalSight includes a zone transfer scanner as part of its external attack surface monitoring workflow. It can help detect exposed AXFR behavior, classify the finding, provide remediation context, compare scan history, alert on changes, export reports, and monitor verified domains on supported plans.

References and further reading

• RFC 5936 — DNS Zone Transfer Protocol — https://www.rfc-editor.org/rfc/rfc5936.html
• RFC 1995 — Incremental Zone Transfer in DNS — https://www.rfc-editor.org/rfc/rfc1995.html
• RFC 8945 — Secret Key Transaction Authentication for DNS — https://www.rfc-editor.org/rfc/rfc8945.html
• NVD — CVE-1999-0532 — https://nvd.nist.gov/vuln/detail/CVE-1999-0532
• MITRE CAPEC-291 — DNS Zone Transfers — https://capec.mitre.org/data/definitions/291.html
• MYCERT MA-469.042015 — DNS Zone Transfer Vulnerability — https://www.mycert.org.my/portal/advisory?id=MA-469.042015
• ISC BIND 9 Administrator Reference Manual — Access control — https://bind9.readthedocs.io/
• ISC Knowledgebase — Securing zone transfers — https://kb.isc.org/docs/aa-00726
• NSD documentation — https://nsd.docs.nlnetlabs.nl/
• Knot DNS documentation — https://www.knot-dns.cz/docs/latest/html/
• PowerDNS Authoritative Server documentation — https://doc.powerdns.com/authoritative/
• OWASP Web Security Testing Guide — Information gathering — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/
• MITRE ATT&CK — Gather victim network information — https://attack.mitre.org/techniques/T1590/

Find DNS exposure before attackers map it

ExternalSight helps teams scan internet-facing domains, identify DNS zone transfer exposure, classify external findings, generate remediation plans, compare scan history, receive alerts, export reports, and monitor verified domains on supported plans. Use it to monitor verified domains for DNS drift and catch exposed AXFR behavior before leaked records become long-lived reconnaissance data.