DNS Zone Transfer Failure: Quick Fixes in 3 Steps

30-Second Fix: Check the Obvious Stuff

Before you dig into logs, check the basics. I've seen people waste 20 minutes on ACLs when the problem was a typo in the IP.

Ping the secondary server from the primary. If it doesn't respond, fix connectivity first. Use ping -n 4 [secondary IP] on Windows, ping -c 4 [secondary IP] on Linux.
Verify the zone transfer IP in your DNS config. On Windows DNS, open the zone properties, go to Zone Transfers tab. Make sure "Allow zone transfers" is checked. Then check "Only to servers listed on the Name Servers tab" or "Only to the following servers" and confirm the secondary's IP is correct. On BIND, check your named.conf zone block for allow-transfer directive.
Check firewall rules. DNS zone transfers use TCP port 53. Not UDP, TCP. Make sure firewall on both servers allows inbound TCP 53 from the other server. Quick test: from the secondary, try telnet [primary IP] 53. If it hangs or refuses, firewall's blocking you.

If none of these work, move on. The real fix is usually next.

5-Minute Fix: ACL and TSIG Key Misconfiguration

The culprit here is almost always a wrong ACL or a mismatched TSIG key. Let's check both.

Windows DNS Server

Open DNS Manager. Right-click the zone, go to Properties > Zone Transfers.
Under "Allow zone transfers", pick "Only to servers listed on the Name Servers tab". Then go to the Name Servers tab and add the secondary server with its correct IP. Don't skip this — I've seen admins add the server name without the IP, and zone transfer fails silently.
If you're using TSIG (transaction signature), check that both servers have the same key. Go to DNS Manager, right-click the server, Properties, Advanced tab. Under Secure secondaries, choose "Use the following key" and select the TSIG key. Then on the secondary, create the same key. If the names or base64 values don't match exactly, zone transfer fails.

BIND DNS Server

Edit /etc/named.conf or your zone file in /var/named. Look for the zone block like this:

zone "example.com" IN {
    type master;
    file "db.example.com";
    allow-transfer { 192.168.1.10; };
};

If you use TSIG, define the key first:

key "transfer-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-secret-here";
};

Then in the zone block:

allow-transfer { key "transfer-key"; };

Common mistake: putting the key in the wrong place or forgetting to restart named. Always run rndc reload or rndc reconfig after changes.

After fixing, test the transfer manually. On the secondary, run:

dig @[primary IP] example.com AXFR

If you get a full zone dump, it's fixed. If you see "transfer failed" or "REFUSED", keep going.

15+ Minute Fix: Logs, Versions, and Edge Cases

If the simple stuff didn't work, you've got a deeper issue. Let's look at logs and edge cases I've hit in production.

Check DNS Server Logs

Windows: Open Event Viewer > Applications and Services Logs > Microsoft > Windows > DNS-Server > Operational. Look for event ID 5400 (zone transfer started), 5401 (zone transfer completed), or 5402 (zone transfer failed). Event 5402 usually includes a reason code. Common ones:

Reason 0x0000232A — ACL denied. Double-check the IP or TSIG key.
Reason 0x0000231A — RCODE_REFUSED. Usually means the primary doesn't have the zone.
Reason 0x0000230C — Timeout. Network issue or firewall.

BIND: Check /var/log/messages or /var/log/named.log. Look for lines with transfer of 'example.com/IN' from [primary IP] failed. The error message after "failed:" tells you exactly what's wrong. Common ones:

not authoritative — Primary doesn't have the zone as master.
REFUSED — ACL or TSIG mismatch.
connection refused — Firewall or named not listening.

Version Compatibility Issues

I've seen zone transfers fail between BIND 9.11 and BIND 9.16 because of different default TSIG algorithms. BIND 9.11 defaults to HMAC-MD5, 9.16 uses HMAC-SHA256. If the key was created with one algorithm but the other server expects a different one, you get REFUSED. Solution: explicitly set the algorithm in the key definition on both sides.

Windows DNS 2016 and 2019 have different default behavior for zone transfers from AD-integrated zones. If you're using Active Directory, zone transfers might not work if the secondary isn't a domain controller. You need to enable "Allow zone transfers to secondary servers" under the zone's Advanced tab in DNS Manager. Hidden checkbox — I've missed it myself.

Edge Cases

Stale zone data on secondary. Delete the zone file on the secondary and try again. On Windows, right-click the zone and delete it, then recreate it as a secondary. On BIND, delete the file in /var/named for that zone.
Large zones with many records. Zone transfers can timeout if the zone has thousands of records and the network is slow. Increase the timeout value. On BIND, set transfer-format many-answers; in options block, or increase max-transfer-time-in in the zone block.
DNSSEC signed zones. If the zone is signed, the secondary must support DNSSEC and have the trust anchors. Without them, transfer might work but validation fails later. Check dnssec-validation auto; on BIND, or enable DNSSEC validation on Windows.

Final Test

After making changes, always test with a manual AXFR from the secondary:

dig @[primary IP] example.com AXFR

If that works, check the secondary's log to see if it actually picked up the zone. On Windows, look for event 5401. On BIND, look for transfer of 'example.com/IN' from [primary IP] succeeded.

If it still fails, you're looking at a network-level issue (VPN, routing, or a proxy that doesn't support TCP long connections). Zone transfers are TCP, and some firewalls drop idle TCP connections after 30 seconds. Check if your firewall has an idle timeout setting.

Pro tip: Don't bother with restarting DNS service as a first step. It rarely fixes zone transfer issues and just makes you wait longer. Focus on ACL, TSIG keys, and logs.

That's it. From basic checks to deep debugging, you should have your zone transfers working in the next 10 minutes. If not, you're dealing with something specific to your environment — check the event logs, the firewall logs, and the DNS server's network interface configuration.