AXFR (zone transfer) status and security considerations

1. What is AXFR?

AXFR (Authoritative Transfer) is the classic DNS mechanism for full zone transfers. A secondary nameserver connects to the primary and requests a copy of the entire zone file.

Why AXFR exists

Before modern APIs and DNS providers, AXFR was the standard way to replicate DNS data. It is still widely used today between trusted servers, especially in self-hosted DNS setups.

How an AXFR looks in practice

If an AXFR is accepted, the client receives the full list of records contained in the zone: A, AAAA, MX, TXT, SRV, internal subdomains, and more. From an attacker’s point of view, this is a goldmine of reconnaissance data.

2. How DNSprobe tests AXFR

DNSprobe performs a lightweight AXFR test from its public IP address to see how your authoritative nameservers behave.

• It first discovers the authoritative NS records for your domain.
• Then it attempts a full zone transfer (AXFR) from each nameserver over TCP.
• For each server, DNSprobe records whether the request is refused, partially answered or fully successful, and lists the nameservers tested in the report.

The test does not store or display your full zone contents. It only needs to know whether the transfer is allowed or refused.

3. Security risks of an open AXFR

Leaving AXFR open to the world turns your DNS zone into a freely downloadable inventory of your infrastructure.

• Attackers can enumerate all hostnames in a single request instead of guessing them with slow brute-force scans.
• Internal or low-profile systems (admin portals, staging environments, backup MX, VPN gateways, printers, etc.) are revealed by name, even if you never link to them publicly.
• Email, VoIP, directory or authentication records (MX, SRV, TXT, _sip, _ldap, etc.) may give hints about the software and platforms you use.
• Combined with other sources, a full zone dump greatly accelerates reconnaissance and makes targeted attacks easier.

For public zones in production, the safe default is clear: AXFR should be disabled for arbitrary clients and restricted only to trusted secondary servers.

4. When is AXFR actually useful?

Despite its risks, AXFR remains a valid tool when used in a controlled environment.

• Synchronising records between a primary DNS server and one or more secondary servers.
• Migrating a zone from one DNS platform to another in a private or administrative context.
• Troubleshooting replication issues in self-hosted DNS, when you explicitly control both ends of the transfer.

In all of these cases, AXFR should be limited to known IP addresses and ideally protected with TSIG keys.

5. How to secure AXFR on your nameservers

If you need AXFR, the goal is not to disable it entirely but to ensure that only your authorised secondary servers can use it.

Restrict AXFR with IP-based ACLs

Most DNS software (BIND, Knot, PowerDNS, NSD, etc.) lets you define an ACL listing the IP addresses that are allowed to perform zone transfers. Any AXFR from outside this list should be refused.

Protect transfers with TSIG

TSIG (Transaction SIGnature) uses a shared secret key to authenticate AXFR and IXFR requests. Combining TSIG with IP ACLs prevents unauthorised servers from impersonating a secondary.

Recommended configuration guidelines

• Disable AXFR by default for public clients; only enable it on specific zones that require transfers.
• Limit AXFR to a small set of trusted IP addresses (your own secondaries) and keep this list up to date.
• Use TSIG where possible so that a stolen IP alone is not enough to obtain a copy of your zone.

6. Understanding DNSprobe’s AXFR results

The table below summarises how to interpret the most common AXFR results you may see in DNSprobe.

Remember that DNSprobe tests AXFR from the perspective of an external client. A refused AXFR does not mean your internal replication is broken—it simply means that zone transfers are not exposed to the public internet, which is usually desirable.

7. Example of a non-blocked AXFR response

Below is a simplified example of what a full AXFR zone transfer might look like when a nameserver improperly allows AXFR from the public internet for example.com.

                $ dig AXFR example.com @ns1.example.com

                ; <<>> DiG 9.18.0 <<>> AXFR example.com @ns1.example.com
                ;; global options: +cmd
                example.com.          3600 IN SOA ns1.example.com. hostmaster.example.com. 2025010101 7200 3600 1209600 3600
                example.com.          3600 IN NS  ns1.example.com.
                example.com.          3600 IN NS  ns2.example.com.

                ; --- Public web & mail records ---
                example.com.          3600 IN MX 10 mail.example.com.
                www.example.com.      3600 IN A   192.0.2.10
                mail.example.com.     3600 IN A   192.0.2.20
                cdn.example.com.      3600 IN CNAME cdn.provider.example.net.

                ; --- TXT / SPF / DMARC / DKIM ---
                example.com.          3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.mailprovider.com ~all"
                _dmarc.example.com.   3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
                dkim._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

                ; --- Internal / sensitive hosts accidentally exposed ---
                intranet.example.com.                   3600 IN A   10.0.0.15
                vpn-gateway.example.com.                3600 IN A 10.0.0.20
                backup-nas.example.com.                 3600 IN A 10.0.0.30
                dev-app01.example.com.                  3600 IN A 192.0.2.50
                my-super-secret-service.example.com.    3600 IN A 192.0.2.100

                ; --- Service discovery (SRV) records ---
                _ldap._tcp.example.com.   3600 IN SRV 0 0 389 dc01.example.com.
                _sip._tcp.example.com.    3600 IN SRV 0 0 5060 sip01.example.com.

                ; ...
                example.com.          3600 IN SOA ns1.example.com. hostmaster.example.com. 2025010101 7200 3600 1209600 3600
                ;; Query time: 45 msec
                ;; X records transferred in Y seconds
        

Real zones are usually much longer and may contain sensitive internal hostnames (VPN gateways, intranet portals, test environments, etc.).
If you ever see a similar dump for your own domain, treat it as a high-risk exposure and immediately restrict AXFR to trusted secondary servers only.

8. Test AXFR manually from your own terminal

To be fully transparent, DNSprobe only runs the same kind of AXFR checks that you can perform yourself. Here are some simple examples to reproduce the test from your own machine.

Linux: using dig (BIND utilities)

On most Linux distributions, the dig command is provided by the BIND utilities package (often named bind-utils, dnsutils or similar). The following command attempts a full zone transfer from ns1.example.com for example.com:

                dig @ns1.example.com example.com AXFR
                dig @ns1.example.com example.com AXFR +nocmd +noall +answer
        

macOS: using dig from the built-in tools

macOS ships with dig as part of the standard command-line tools. Open Terminal and run the same AXFR command as on Linux. If AXFR is refused, you will see a REFUSED or NOTAUTH response instead of the full list of records.

                dig @ns1.example.com example.com AXFR
        

Windows: using the interactive nslookup client

On Windows, the legacy nslookup tool can still perform AXFR. Start nslookup from a Command Prompt, switch the server to your authoritative nameserver, set the query type to AXFR, then request the zone name as shown below.

                nslookup
        

                > server ns1.example.com
                > set type=AXFR
                > example.com
        

Important: only run AXFR tests against domains and servers that you are authorised to audit. Some operators treat repeated AXFR attempts as suspicious activity.