DNS Zone Transfer Fails with NOTAUTH Error – Fix

When This Error Hits

You set up a secondary DNS server, you think everything's right, then you check the logs and see NOTAUTH. The secondary server can't pull the zone. This usually happens right after you add a new secondary server or change IPs. I've seen it most often on BIND 9.16+ and Windows Server 2019/2022 DNS when the secondary server's IP isn't explicitly listed in the allow-transfer list.

Root Cause in Plain English

DNS zone transfers aren't open to just anyone. The primary DNS server has a list of IPs it trusts to receive the zone data. If your secondary server's IP isn't on that list, the primary server replies with NOTAUTH. It's basically saying "I don't know you, I won't send you the zone."

Another common cause: the secondary server may have an older copy of the zone or wrong serial number, but the NOTAUTH error means authorization failed first. Serial mismatch gives a different error (like REFUSED or FORMERR). So focus on authorization.

The Fix – Step by Step

On BIND (named.conf)

1. Find your zone definition in /etc/bind/named.conf or named.conf.local.
2. Add or update the allow-transfer directive inside the zone block. You need to list the secondary server's IP. For example:
   

   zone "example.com" {
       type master;
       file "/etc/bind/db.example.com";
       allow-transfer { 192.168.1.100; };
   };

3. If you have multiple secondaries, list them all: allow-transfer { 192.168.1.100; 10.0.0.5; };
4. Check TSIG keys – if you're using transaction signatures, the key must be on both servers and referenced with allow-transfer { key "your-key-name"; };. I've tripped on that myself – the key name is case-sensitive.
5. Restart BIND: systemctl restart named (or rndc reload if you prefer a less disruptive reload).

On Windows DNS Server

1. Open DNS Manager (dnsmgmt.msc).
2. Right-click your zone (e.g., example.com) and select Properties.
3. Go to the Zone Transfers tab.
4. Check "Allow zone transfers" – you'll see three options. Pick "Only to servers listed on the Name Servers tab" if you've already added the secondary server there. Or pick "Only to the following servers" and add the secondary's IP manually. I prefer the Name Servers method – less duplication, one place to manage.
5. Also check the Name Servers tab – make sure the secondary server is listed with the correct IP. If it's not, add it.
6. Click OK and trigger a zone transfer from the secondary side to test.

Verify the Zone Transfer Works

On the secondary server, run a manual transfer to see the response:

# BIND secondary
rndc refresh example.com

# Windows secondary
nslookup -type=soa example.com secondary-dns-server

Check the event logs or /var/log/syslog for any NOTAUTH or REFUSED messages after the fix.

If It Still Fails

Three things I'd check next:

• Firewall – make sure TCP port 53 is open between primary and secondary (not just UDP!). Zone transfers use TCP. I once spent an hour debugging only to find a firewall rule blocking TCP/53.
• Forwarders – if the primary server has forwarders set, it might try to forward the transfer request instead of handling it. Disable forwarders for the zone or set forwarders { }; in BIND.
• Zone signed with DNSSEC – if the zone is DNSSEC-signed, the secondary must be configured to validate. On BIND, that means setting dnssec-validation auto; and having the trust anchor. On Windows, the zone must be signed with a key that the secondary trusts. This is less common but bites you if you missed it.

If none of that helps, grab the full error from the DNS logs. On BIND, run named -g to see real-time errors. On Windows, check the DNS Server log in Event Viewer under Applications and Services Logs > Microsoft > Windows > DNS-Server. The exact error message will tell you if it's still an authorization problem or something else.