Fix DNS_ERROR_RCODE_BADSIG (0X00002338) – DNS signature failed

1. Stale DNSSEC trust anchor on the resolver

This is the most common reason for 0X00002338. Your recursive resolver holds an old trust anchor that doesn't match what the authoritative server is using. You'll see this after the root zone KSK rollover (which happens every few years) or after you manually updated a signed zone's keys.

On a Windows Server 2022/2019 DNS running as a resolver, run this PowerShell to clear and refresh the trust anchors:

Clear-DnsServerTrustAnchor -ZoneName "." -Force
Get-DnsServerZone | Where-Object {$_.ZoneType -eq 'Primary'} | Update-DnsServerZone
# After this, restart the DNS service
Restart-Service DNS

For BIND 9.18+ on Linux, check /etc/bind/named.conf.options for a trust-anchors section. If you see a hard-coded key, comment it out and let BIND auto-trust the root. Then run:

rndc reconfig
rndc flush
rndc validation newkey .

Don't bother with rndc validation status checking first — just run the reset. I've seen resolvers silently hold onto revoked keys for weeks.

2. Active DNSSEC key rollover mismatch on your authoritative zone

If you manage your own signed zones, the culprit here is almost always a KSK or ZSK rollover that wasn't fully published before switching to the new key. Standard procedure: publish new key, wait TTL of the old DNSKEY (usually 2–24 hours), then switch signing to the new key. If you skipped a step, resolvers see a signature from a key they don't have.

Verify your zone's keys with dig from an external machine:

dig +dnssec yourdomain.com DNSKEY
# Look for RRSIG records with different keytags than the DNSKEY records

If there's a mismatch, you need to regenerate the zone with the correct keys. On a Windows Server running DNSSEC via the GUI:

1. Open DNS Manager
2. Right-click your zone → DNSSEC → Properties
3. Go to the Key Signing Keys tab. Remove all keys except the current one. Then add a new KSK and ZSK.
4. Click OK. The zone will re-sign.

On BIND, the fastest fix is to delete the K*.private and K*.key files for old keys in /var/named/keys/ and run dnssec-signzone again. Example:

dnssec-signzone -A -3 $(head -c 16 /dev/random | sha256sum) -K /var/named/keys/ -o yourdomain.com /var/named/dynamic/yourdomain.com.db

I've seen admins forget to remove old key files from the zone directory — BIND picks them up and creates signatures that don't match the live DNSKEY set. Always clean up.

3. Clock skew between resolver and authoritative server

DNSSEC signatures have a validity window (usually 1–7 days). If your resolver's clock is off by more than a few hours, validation fails with BADSIG. This is surprisingly common on VMs with snapshots that paused the RTC. Check time sync first, not DNS.

On Windows Server:

w32tm /query /status | findstr "Stratum"
# If stratum > 3, run:
w32tm /resync /rediscover

On Linux:

timedatectl status
timedatectl set-ntp yes
systemctl restart systemd-timesyncd
# Or for old NTP setups:
ntpq -p
ntpdate -b -u 0.pool.ntp.org

Once time is corrected, flush the resolver cache and test again:

dig +dnssec yourdomain.com | grep -E "status:|SERVFAIL|BADSIG"
# Should return NOERROR, not SERVFAIL

Quick-reference summary

If none of these fix it, check if your firewall or proxy is stripping DNSSEC records. I've seen corporate Sophos and Fortinet appliances mangle EDNS0 options. Disable DNSSEC validation on the security device, not the DNS server.