Quick Answer
Set allow-transfer { <secondary-IP>; }; in the Bind zone config, or on Windows DNS check the Name Servers tab and IP restrictions.
Why This Happens
Error 0X00002617 means DNS_INFO_COMPLETE — the zone transfer (AXFR) finished, but the secondary server got zero records. The culprit here is almost always an authorization mismatch. The primary DNS server says "sure, you can transfer" but then doesn't actually send the zone data. I've seen this on Bind 9.11+ and Windows Server 2012 through 2022.
Common triggers: you just set up a new secondary DNS server, or you migrated the primary and forgot to update the transfer allow list. The secondary can connect, but the primary's access control list (ACL) doesn't include the secondary's IP address. On Windows DNS, it's often the Name Servers tab not listing the secondary server.
Less common: TSIG key mismatch. The key name or secret on the primary doesn't match what the secondary is sending. That gives a different error usually, but I've seen it produce this exact message when the key is valid for transfer but not for the specific zone.
Fix Steps
- Check the primary DNS server's zone transfer settings.
For Bind, look at the zone stanza in/etc/bind/named.conf.localor your equivalent. Add or update:
Replacezone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.10; }; };192.168.1.10with the secondary server's IP. After editing, runrndc reload. - For Windows DNS Server:
Open DNS Manager, right-click the zone, go to Zone Transfers tab. Check Allow zone transfers → Only to servers listed on the Name Servers tab. Then go to the Name Servers tab and add the secondary server's hostname and IP. Or choose Only to the following servers and add the IP directly. - Verify TSIG keys if you use them.
On Bind:dnssec-keygen -a hmac-sha256 -b 256 -n HOST transfer-key. Then innamed.conf:
On the secondary, the same key must exist inkey "transfer-key" { algorithm hmac-sha256; secret "base64-encoded-key-here"; }; zone "example.com" { type master; allow-transfer { key "transfer-key"; }; };named.conf. For Windows DNS, TSIG keys are configured under Advanced in the zone transfer tab — not all admins realize you can add keys there. - Check firewall rules.
TCP port 53 must be open between secondary and primary. DNS zone transfers use TCP, not UDP. Try from the secondary:dig @primary-ip example.com AXFR. If it hangs or times out, firewall or network ACL is the problem. - Restart the DNS service.
On Bind:systemctl restart bind9orrndc stop && rndc start. On Windows:net stop DNS && net start DNS. I've seen Bind cache stale ACLs without a full restart.
Alternative Fixes
If the secondary is not sending the correct IP
Sometimes the secondary server's IP changes (DHCP, VPN). Hardcode the IP on the secondary's network interface or use a static DHCP reservation. Then update the primary's allow list.
If the zone has a space in its name (yes, it happens)
I've seen zones with spaces in the domain name (don't ask). Bind chokes on that during transfer. Rename the zone or escape it with backslashes in the config.
Check the zone file for syntax errors
A malformed zone file on the primary can cause a successful connection but zero records transferred. Run named-checkzone example.com /etc/bind/db.example.com. On Windows, use dnscmd /ZoneValidate.
Prevention Tips
- Always test zone transfers after any DNS config change. I use
dig AXFRfrom the secondary before calling it done. - Use static IPs for DNS servers. DHCP leases expire, and then your transfer breaks silently.
- Document your TSIG keys. Store them in a password manager or a vault. Losing the key means rebuilding the trust relationship.
- Set up monitoring. Nagios, PRTG, or even a simple cron job that runs
dig +shortfor a known record on the secondary and alerts if it's missing. I've caught transfer failures within minutes this way.
That's it. Most of the time it's the allow-list. Add the secondary's IP, reload, test. If it still fails, dig into TSIG and zone file health.