How to test DNS zone transfer exposure with dig

DNS zone transfers copy every record in a zone from one authoritative server to another. Testing AXFR exposure with dig helps a DNS or security operator confirm that an authoritative server refuses transfer requests from ordinary clients and allows them only from approved transfer sources.

The test must target an authoritative nameserver for the zone, not a recursive resolver. A direct SOA query with recursion disabled confirms that the selected server is answering with authority before the transfer request is tested against the same server.

Run AXFR checks only for zones you own or are explicitly authorized to test. A denied transfer usually prints Transfer failed., a controlled transfer prints the zone records plus an XFR size line, and a timeout needs a separate TCP/53 check before it is treated as a transfer-policy result.

1. Choose the zone and authoritative server you are allowed to test.

   zone: example.net
   server: ns1.example.net
   expected transfer source: approved secondary DNS server only

   Do not run AXFR probes against third-party zones or random authoritative servers. A zone transfer request asks for the full zone contents.

2. Confirm that the selected server is authoritative for the zone.

   $ dig @ns1.example.net example.net SOA +norecurse +noall +comments +answer +stats
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
   ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
   
   ;; ANSWER SECTION:
   example.net.        300 IN SOA ns1.example.net. hostmaster.example.net. 2026062701 3600 900 604800 300
   
   ;; Query time: 1 msec
   ;; SERVER: 192.0.2.53#53(ns1.example.net) (UDP)
   ;; WHEN: Sat Jun 27 01:49:34 UTC 2026
   ;; MSG SIZE  rcvd: 153

   The aa flag shows an authoritative answer. If the flag is missing, find the authoritative nameserver before testing AXFR.
   Related: How to find authoritative nameservers with dig

3. Confirm TCP/53 reachability when the server path is being tested.

   $ dig @ns1.example.net +tcp example.net SOA +norecurse +noall +comments +answer +stats
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
   ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
   
   ;; ANSWER SECTION:
   example.net.        300 IN SOA ns1.example.net. hostmaster.example.net. 2026062701 3600 900 604800 300
   
   ;; Query time: 2 msec
   ;; SERVER: 192.0.2.53#53(ns1.example.net) (TCP)
   ;; WHEN: Sat Jun 27 01:49:34 UTC 2026
   ;; MSG SIZE  rcvd: 153

   dig always uses TCP for AXFR. If a normal SOA query works over TCP but AXFR fails, the failure is tied to transfer handling rather than basic TCP/53 reachability.
   Related: How to query DNS over TCP with dig

4. Attempt the zone transfer from the source being checked.

   $ dig @ns1.example.net example.net AXFR +tries=1 +time=3
   
   ; <<>> DiG 9.20.18 <<>> @ns1.example.net example.net AXFR +tries=1 +time=3
   ; (1 server found)
   ;; global options: +cmd
   ; Transfer failed.

   Transfer failed. is the expected result when the client source is not allowed to transfer the zone. Record the server, zone, source network, and time with the finding.

5. Run the same transfer from an approved secondary server when access should be allowed.

   $ dig @ns1.example.net example.net AXFR +tries=1 +time=3
   
   ; <<>> DiG 9.20.18 <<>> @ns1.example.net example.net AXFR +tries=1 +time=3
   ; (1 server found)
   ;; global options: +cmd
   example.net.        300 IN SOA ns1.example.net. hostmaster.example.net. 2026062701 3600 900 604800 300
   example.net.        300 IN NS  ns1.example.net.
   mail.example.net.   300 IN A   192.0.2.30
   ns1.example.net.    300 IN A   192.0.2.53
   www.example.net.    300 IN A   192.0.2.20
   example.net.        300 IN SOA ns1.example.net. hostmaster.example.net. 2026062701 3600 900 604800 300
   ;; Query time: 2 msec
   ;; SERVER: 192.0.2.53#53(ns1.example.net) (TCP)
   ;; WHEN: Sat Jun 27 01:49:34 UTC 2026
   ;; XFR size: 6 records (messages 1, bytes 230)

   If an ordinary workstation receives zone records and an XFR size line, the server is exposing the zone to that source. Restrict zone transfers to approved secondary addresses or a TSIG-protected transfer policy.