DNS Zone Transfer (AXFR): When a Misconfiguration Exposes Your DNS Records

Introduction

When we talk about DNS security, we often focus on things like DNS spoofing or cache poisoning. However, there is another issue that can expose a large amount of information about an organization's infrastructure: misconfigured DNS Zone Transfer.

A DNS Zone Transfer is a legitimate mechanism used to replicate DNS records between authoritative DNS servers. The problem occurs when a DNS server is incorrectly configured to allow unauthorized clients to request a complete copy of the DNS zone.

This can expose records such as:

Subdomains
Internal hostnames
IP addresses
Mail servers
Nameservers
Development or testing environments

The technique commonly associated with a full zone transfer is AXFR.

Important: The commands in this article are demonstrated against zonetransfer.me, a domain intentionally provided for DNS security testing.

What is DNS?

The Domain Name System (DNS) translates domain names into IP addresses.

For example:

example.com → 93.184.216.34

example.com → 93.184.216.34

DNS normally operates over port 53, using both UDP and TCP depending on the type of DNS traffic.

DNS also contains different types of records, such as:

A       → IPv4 address
AAAA    → IPv6 address
MX      → Mail server
NS      → Nameserver
CNAME   → Alias
TXT     → Text information
SOA     → Start of Authority

A       → IPv4 address
AAAA    → IPv6 address
MX      → Mail server
NS      → Nameserver
CNAME   → Alias
TXT     → Text information
SOA     → Start of Authority

What is a DNS Zone Transfer?

A DNS Zone Transfer is a process used to synchronize DNS information between authoritative DNS servers.

There are two common types:

AXFR — Full Zone Transfer
IXFR — Incremental Zone Transfer

AXFR attempts to transfer the entire DNS zone, while IXFR transfers only the changes made since a previous version of the zone.

In a correctly configured environment, zone transfers should normally be restricted to authorized secondary DNS servers.

The security problem appears when the server allows unauthorized clients to perform an AXFR request.

Conceptually:

Authorized DNS Server
        |
        | Zone Transfer
        ↓
Authoritative DNS Server

Authorized DNS Server
        |
        | Zone Transfer
        ↓
Authoritative DNS Server

A misconfigured server may instead allow:

Unauthorized Client
        |
        | AXFR request
        ↓
DNS Server
        |
        └── Entire DNS Zone

Unauthorized Client
        |
        | AXFR request
        ↓
DNS Server
        |
        └── Entire DNS Zone

Reconnaissance

Before attempting a zone transfer, we first identify the authoritative nameservers for the domain.

We can use:

host -t ns zonetransfer.me

host -t ns zonetransfer.me

This returns the domain's authoritative nameservers.

The important information here is the NS record, which tells us which DNS servers are authoritative for the domain.

Attempting an AXFR

Once we know the nameserver, we can test whether it allows a zone transfer.

Using host:

host -l zonetransfer.me nsztm2.digi.ninja

host -l zonetransfer.me nsztm2.digi.ninja

The -l option requests a zone transfer from the specified nameserver.

Another common tool is dig:

dig axfr zonetransfer.me @nsztm1.digi.ninja

dig axfr zonetransfer.me @nsztm1.digi.ninja

If the server is configured to allow the transfer, the response can contain multiple DNS records belonging to the zone.

This is the point where a misconfiguration can become an information disclosure issue.

Testing a Subdomain

DNS configurations can sometimes differ between zones.

For example:

dig axfr internal.zonetransfer.me @intns1.zonetransfer.me

dig axfr internal.zonetransfer.me @intns1.zonetransfer.me

This attempts an AXFR request against the internal.zonetransfer.me zone.

This demonstrates an important point:

Finding one DNS server does not necessarily mean that every zone has the same configuration.

Each zone should be reviewed according to its own configuration and access-control rules.

Using nslookup

Another way to inspect DNS information is nslookup.

Start it with:

nslookup

nslookup

Then specify that we want NS records:

This allows us to identify the authoritative nameservers for the domain.

Automating the Test

Manual testing is useful for understanding what is happening, but security tools can automate DNS reconnaissance and zone-transfer testing.

dnsrecon

dnsrecon -d zonetransfer.me -t axfr

dnsrecon -d zonetransfer.me -t axfr

Where:

-d → target domain
-t axfr → test for DNS zone transfer

-d → target domain
-t axfr → test for DNS zone transfer

If the DNS server permits the transfer, dnsrecon can display the records obtained from the zone.

dnsenum

Another useful reconnaissance tool is:

dnsenum zonetransfer.me

dnsenum zonetransfer.me

dnsenum can gather various DNS-related information and may also identify interesting records and nameservers.

Why is Zone Transfer Dangerous?

At first glance, DNS records may not seem sensitive.

However, a complete zone can reveal the structure of an organization's infrastructure.

For example, instead of discovering only:

www.example.com

www.example.com

an exposed zone might reveal:

www.example.com
mail.example.com
vpn.example.com
dev.example.com
staging.example.com
internal.example.com
git.example.com

www.example.com
mail.example.com
vpn.example.com
dev.example.com
staging.example.com
internal.example.com
git.example.com

This gives an attacker valuable information during the reconnaissance phase.

The issue is therefore not necessarily that the DNS server itself allows code execution.

The problem is information disclosure.

A successful zone transfer can make it much easier to map an organization's attack surface and identify systems that may require further security assessment.

Is DNS Zone Transfer a Vulnerability?

Technically, zone transfer itself is not a vulnerability.

It is a legitimate DNS feature used to synchronize DNS data between authoritative servers.

The vulnerability is the misconfiguration that allows unauthorized clients to perform the transfer.

A better way to describe the finding is:

Unauthorized DNS Zone Transfer due to improper access-control configuration.

It is primarily an information disclosure / security misconfiguration issue.

Conclusion

DNS Zone Transfer is a good example of how a legitimate feature can become a security issue when it is incorrectly configured.

The key idea is simple:

DNS Zone Transfer
        +
Improper Access Control
        ↓
Information Disclosure

DNS Zone Transfer
        +
Improper Access Control
        ↓
Information Disclosure

During a penetration test, checking whether unauthorized clients can perform an AXFR request can be an important part of DNS reconnaissance.

From a defensive perspective, DNS administrators should ensure that zone transfers are restricted to authorized secondary DNS servers and that DNS configurations are regularly reviewed.

Always perform these tests only against systems you own or have explicit permission to assess.

Contents