Quick answer: Delete the TSIG key from the DNS server and re-add it with the exact name, algorithm, and secret from the client side.
I know this error is infuriating—it shows up out of nowhere during zone transfers or dynamic updates, and the server just says "bad key" without telling you which part is wrong. This tripped me up the first time too, back when I ran a help desk and saw this on Windows Server 2008 R2. But once you understand what's happening, it's a quick fix.
The 0x00002339 error (RCODE_BADKEY) means the DNS server received a request signed with a TSIG key it doesn't recognize or can't validate. TSIG (Transaction Signature) is how DNS servers authenticate each other during zone transfers or updates. The key has three parts: a name, an algorithm (like HMAC-SHA256), and a shared secret (the actual password). If any one of those three doesn't match between the server and the client, you get this error. It's not a network hiccup—it's a credential mismatch, pure and simple.
Here's a real-world trigger: You set up a secondary DNS server on a new box, copied the zone transfer settings from an old config, but the old config had a typo in the key name or a different secret. Or someone rotated the key a month ago but only updated one server. That's when you'll see this.
Step-by-Step Fix
- Identify where the key is defined. On Windows Server, open DNS Manager, right-click the server, go to Properties → Security → TSIG. On BIND (Linux), look in
/etc/named.confor a separate key file. - Compare the key name exactly. TSIG keys are case-sensitive.
MyKeyis not the same asmykey. Write down the name from the client that's initiating the transfer (secondary server) and verify it matches the primary server's key list. - Check the algorithm. If the client uses HMAC-SHA256 but the server has HMAC-MD5, you'll get BADKEY (or BADSIG on some platforms). Make them match. On Windows, the algorithm is shown in the TSIG properties; on BIND, it's in the line like
algorithm hmac-sha256;. - Recreate the key with the correct secret. If name and algorithm match but it still fails, the secret is wrong. The easiest fix: generate a new key on one side, then copy it to the other. On Windows, right-click TSIG → New Key, paste the same secret into both servers. On BIND, use
tsig-keygenon the primary and copy the output to the secondary's config.
After you make changes, restart the DNS service. On Windows: net stop dns && net start dns. On BIND: rndc reload or systemctl restart named. Then try the zone transfer again.
If That Doesn't Work
Sometimes the key is fine, but the server's clock is off. TSIG has a timestamps component to prevent replay attacks. If the clocks differ by more than 5 minutes (default), you get BADTIME, but older implementations might report it as BADKEY. Check with w32tm /query /status on Windows or ntpq -p on Linux. Set up NTP if you haven't—it's not optional for DNS.
Another culprit: the IP address restriction on the key. On BIND, you can limit which IPs can use a key with the allow-transfer or allow-update match list. If the client's IP changed, the key won't be accepted. On Windows, check the key's associated IPs if you have any custom restrictions.
Still stuck? Delete the key completely from both sides. Re-create it from scratch with a fresh secret. Use a tool like tsig-keygen on Linux to generate a strong one. I've seen broken keys that were stored with extra spaces or line breaks—starting over eliminates that.
Prevention Tip
Put your TSIG keys in a central file or use a configuration management tool like Ansible or DSC. Don't hand-edit secrets across servers—that's how typos happen. Also, set up monitoring for DNS errors so you know when a key is about to expire (yes, keys can have expiration times). And document your key names and algorithms in your runbook. Future you will thank you.
This error isn't glamorous, but it's fixable in minutes once you know the drill. Check name, algorithm, secret—in that order. You'll be back to reliable zone transfers before your coffee gets cold.