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:

• AXFR (Authoritative Zone Transfer): A request for a full copy of the entire zone.
• IXFR (Incremental Zone Transfer): A request for only the changes made to a zone since the last update.

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.

WARNING: Operational and Legal Considerations

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

• Malicious Domains: If you are investigating a domain you suspect is malicious, directly interacting with its infrastructure (including its nameservers) can carry risks. Ensure you are using appropriate security measures (e.g., a sandboxed environment, a dedicated virtual machine).
• Attribution & Logging: Directly querying nameservers from your home or work network will generate DNS traffic that can be logged by various entities (your ISP, intermediate DNS servers, the target nameserver itself) and may associate your IP address with the lookup. If attribution is a concern, consider using a VPN (that tunnels all traffic, including DNS), a public Wi-Fi network, or a dedicated, non-attributable research machine.
• Legality: Depending on your jurisdiction and the specific circumstances, performing an unsolicited AXFR query against a nameserver might be viewed as unauthorized scanning or access, potentially violating computer security, abuse, or privacy laws. It is strongly recommended to consult with a lawyer or your organization's legal department to understand the legal implications in your region before proceeding with such tests, especially against targets you do not own or have explicit permission to test. This post should be considered for informational purposes only.

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:

• Name/Host: The specific hostname the record applies to (e.g., www, blog, or @ which usually represents the domain itself, example.com.). If blank, it often inherits the name from the previous record.
• TTL (Time-To-Live): How long (in seconds) resolvers should cache this record. Can be preceded by $TTL at the top of the file for a default.
• Class: Almost always IN which stands for Internet. This indicates the record data is for the Internet protocol suite.
• Type: The type of DNS record (e.g., SOA, NS, MX, A, AAAA, CNAME, TXT, SRV).
• Value/Data: The actual data for the record (e.g., an IP address for an A record, a hostname for an MX or CNAME record, text for a TXT record).

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!)

3. 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."

4. 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.

5. 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:

• All known hostnames (subdomains, internal server names if listed).
• IP addresses for these hosts.
• Mail server configurations (MX records).
• TXT records (which might contain SPF data, domain verification keys, etc.).
• CNAME records revealing aliases or service dependencies.
• SRV records pointing to specific services.

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

• This technique is "hit or miss." Properly configured nameservers should deny AXFR requests from unauthorized sources. Success often indicates a security misconfiguration.
• All OpSec warnings apply: your queries can be logged.
• Using third-party websites for AXFR attempts means the site operator can see your query and its target.
• Sometimes, even if a primary nameserver denies AXFR, a misconfigured secondary nameserver for the same zone might permit it. Test all listed authoritative nameservers.
• The North Korea .kp domain leak in 2016, where one of their top-level nameservers allowed AXFR, is a famous real-world example of the impact of such a misconfiguration. It revealed their entire (albeit small) national internet namespace at the time.