Introduction

When you register a domain (let's say example.com), your DNS provider or registrar creates a zone for your domain on their authoritative nameservers. This zone acts as the definitive source of truth for your domain's DNS information. Think of this zone as a text file (a "zone file") containing all the DNS records for your domain (e.g., A, MX, TXT records).

In a way, these records are "private" in the sense that the entire list isn't broadcast to the world. DNS servers will only respond with a specific record if queried for it directly (e.g., "What is the A record for www.example.com?"). To discover all records within a zone, an unauthorized party would typically have to guess an infinite number of potential hostnames, be the legitimate owner with access, or find a way to get a copy of the entire zone file. This post explores one method for attempting that last option: a DNS Zone Transfer.

How It Works

For redundancy and resilience, DNS best practices (and often, requirements) dictate that every domain should have at least two authoritative nameservers. Instead of manually creating and synchronizing records on multiple server systems and risking them falling out of sync, DNS server software implements zone transfer capabilities. These allow records to be automatically copied from a primary (or "master") nameserver to secondary (or "slave") nameservers.

There are two main types of zone transfers:

Here’s a typical scenario: When you register example.com, your DNS provider might set up ns1.example-provider.com as the primary nameserver. This server then notifies ns2.example-provider.com (a secondary server) that it needs to fetch the zone for example.com. Later, if you add a new record, like an A record for blog.example.com pointing to 127.0.0.253, ns1 (the primary) receives this update. It would then typically notify ns2, which might perform an IXFR to get just that new blog record. If, for some reason, ns2 became significantly out of sync, a system administrator could manually trigger an AXFR from ns1 to ns2 to ensure ns2 has a complete and accurate copy of the zone. The command, run from the command line of ns2 (or any authorized client), might look something like this using the dig utility: dig axfr example.com @ns1.example-provider.com

The Security Aspect (Theory vs. Practice): Theoretically, these nameservers (especially the primary) should be configured to only allow zone transfers (AXFR/IXFR) to explicitly authorized IP addresses of their legitimate secondary nameservers. This is often controlled via firewall rules, Access Control Lists (ACLs) on the nameserver itself, or specific configuration directives within the nameserver software (like BIND's allow-transfer option). Theoretically, the default setting in modern nameserver software is to deny zone transfers to unauthorized requesters. Theoretically, all authoritative nameservers for a zone are configured with consistent security settings.

But, as we know, theory and practice can diverge due to misconfigurations, legacy setups, oversight, or a misunderstanding of security implications. If an authoritative nameserver for a domain is improperly configured to allow AXFR requests from any client (or a broader range than intended), then anyone can attempt to request a full copy of that domain's zone file.

Be aware of the following before you attempt an AXFR query:

Understanding a Zone File

DNS zone files have been around for a long time and are fundamentally text files with a specific (though sometimes seemingly archaic) syntax. Here’s a simplified example of what a zone file for example.com might look like:

$TTL 86400      ; Default Time-To-Live for records in this zone (1 day)
@   IN  SOA ns1.example-provider.com. hostmaster.example.com. (
            2025060401  ; Serial number (e.g., YYYYMMDDNN)
            86400       ; Refresh interval for secondary servers
            7200        ; Retry interval if refresh fails
            2592000     ; Expire interval if secondary cannot contact primary
            345600      ; Negative caching TTL (how long to cache NXDOMAIN)
            )
; Name Server records
@   IN  NS  ns1.example-provider.com.
@   IN  NS  ns2.example-provider.com.

; Mail Exchange records
@   IN  MX  10 mail.example.com.

; Host records (A for IPv4, AAAA for IPv6)
@               IN  A   192.0.2.1
www             IN  A   192.0.2.1
blog            IN  A   192.0.2.2
ftp             IN  CNAME   www.example.com.

; Text records
@   IN  TXT "v=spf1 mx -all"

The general format (left to right) is typically:

For more real-world examples of zone files (some obtained via successful AXFRs from misconfigured servers), you can explore projects like the TLDR-2 "Transferable Zones" project on GitHub. This project attempts AXFRs against TLD nameservers and can provide insight into zone file structures.

Steps to Attempt an AXFR

  1. Identify Authoritative Nameservers: You need to find the current authoritative nameservers for the target domain. It's good practice to use multiple methods for completeness:

    • Check WHOIS/RDAP: Use a lookup tool (e.g., command-line whois, centralops.net, whoxy.com, or client.rdap.org) to perform a WHOIS or RDAP lookup on the domain. Note the nameservers listed.
    • Query DNS for NS Records: Use a DNS lookup tool (e.g., dig, digwebinterface.com, or Google Admin Toolbox - Dig) to query for the NS records of the domain.

  2. Attempt the AXFR Query: Once you have a list of potential old nameservers, you can query them directly.

    • Option A: Command-Line / Terminal (replace example.com with your target domain and ns1.example-registrar.com with an identified old nameserver):

      • Linux / macOS / Windows with BIND Tools: The dig command is standard. (For Windows, you might need to install BIND tools from ISC's website - BIND9.16.50.x64.zip is one of the last compiles for Windows). A simple query: 
        dig AXFR example.com @ns1.example-registrar.com
        For cleaner output, you can add flags (useful for scripting): 
        dig AXFR example.com @ns1.example-registrar.com +short
        Or for more controlled, minimal output (as in your original example): 
        dig AXFR example.com @ns1.example-registrar.com +noadditional +noquestion +nocomments +nocmd +nostats

    • Option B: Use digwebinterface.com

      1. Enter the target domain (e.g., example.com) in the "Hostnames or IP addresses" textbox.
      2. Select AXFR from the "Type" dropdown.
      3. Optional: Check "Show command" to see the equivalent dig command.
      4. Under the "Nameservers" option, choose "Specify myself" and enter one or more of the old nameservers you found (one per line).
      5. Click "Dig".
      6. Review the results. (And if you find the tool useful, consider making a donation to support its operation!)
digwebinterface-example

  1. Review the results. A successful AXFR will list many DNS records. A failed/denied attempt will usually result in an error message like "Transfer failed," "REFUSED," or "not authorized."

  2. Check Historic Nameservers (Optional, Advanced): As detailed in the article "Checking Old Nameservers for Forgotten DNS Records", you can research previously authoritative nameservers. While less likely to be configured for the current zone, an old, forgotten, but still online nameserver might theoretically be misconfigured and respond to an AXFR for a zone it thinks it still serves, or for other zones it hosts. This is generally a long shot for AXFR but can be part of exhaustive reconnaissance.

  3. Analyze Your Findings: If successful, the AXFR will return the entire zone file content. Save this output to a file for careful review and analysis.

What to Do with the Results

If an AXFR attempt is successful, you essentially have a blueprint of the domain's DNS configuration. This can include:

This information can be invaluable for understanding an organization's network perimeter, identifying potential targets for further legitimate security testing (with permission), or simply mapping out infrastructure. I'm deliberately not going into exhaustive detail on exploitation here, as the focus is on the technique of enumeration. The key is: you now have a comprehensive list of DNS records. Go forth and (responsibly) investigate the new hosts, services, and potential information you've uncovered.

Notes & Pointers