0X0000232C

Fix DNS_ERROR_RCODE_NOT_IMPLEMENTED (0x0000232C)

Network & Connectivity Intermediate 👁 1 views 📅 May 30, 2026

Your DNS server doesn't support the query type you're sending. Usually a DNSSEC or EDNS0 mismatch. Quick fix: disable EDNS0 or check server capabilities.

Quick Answer

Disable EDNS0 in your DNS client, switch to a compatible query type (like A instead of AAAA), or update your DNS server software.

Why This Happens

You're hitting a classic protocol mismatch. The error DNS_ERROR_RCODE_NOT_IMPLEMENTED (0x0000232C) means your DNS client sent a query the name server doesn't understand. I see this most often with older BIND 9 servers (pre-9.8) that don't handle EDNS0 properly, or with DNSSEC-enabled resolvers talking to servers that don't support it. Another common trigger: a router's built-in DNS proxy that chokes on NSID queries or DNSSEC DO bits.

The culprit here is almost always the EDNS0 extension. When your Windows machine or Linux resolver sends an EDNS0 OPT pseudo-record, some DNS servers—especially embedded ones in consumer routers—just can't parse it. They respond with NOTIMP (code 5) instead of gracefully ignoring the option like they should.

Fix Steps (In Order)

1. Test with dig to Confirm the Issue

dig @8.8.8.8 example.com +noedns

If that works but dig @8.8.8.8 example.com (with EDNS0) fails, you know it's EDNS0. Run this against your problematic DNS server.

2. Disable EDNS0 on Windows

Windows doesn't give you a GUI toggle. You'll need the registry:

reg add HKLM\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters /v EnableEDNS0 /t REG_DWORD /d 0 /f

Restart the DNS Client service: net stop dnscache && net start dnscache. This forces Windows to not send the EDNS0 option.

3. Disable EDNS0 on Linux/macOS

For resolv.conf-based systems, add this line to /etc/resolv.conf if using systemd-resolved, it's trickier. Best approach: edit /etc/systemd/resolved.conf and set:

[Resolve]
DNS=8.8.8.8
DNSSEC=no
LLMNR=no

Then systemctl restart systemd-resolved. For unbound users, disable EDNS0 by adding edns-tcp-keepalive: no and edns-client-subnet: no to unbound.conf.

4. Use a Different Query Type

Some servers don't implement AAAA (IPv6) or MX records. Try:

nslookup -type=A example.com 192.168.1.1

If that works, the server simply lacks support for that record type. Switch your application to query only what's available.

5. Update the DNS Server Software

If you control the server—like a BIND or Windows DNS server—update it. For BIND 9, versions before 9.8.0 had incomplete EDNS0 support. Run named -v to check. Windows DNS Server 2012 R2 and earlier had similar problems with DNSSEC queries. Patch or upgrade.

Alternative Fixes

  • Switch DNS providers – If you're hitting your ISP's DNS and it's broken, just use 8.8.8.8 or 1.1.1.1. Skip the middleman.
  • Flush DNS cache – Rarely fixes this, but won't hurt: ipconfig /flushdns on Windows, sudo systemd-resolve --flush-caches on Linux.
  • Check for DNSSEC validation issues – Some resolvers (like Unbound) may send EDNS0 with DO bit set. Disable validation temporarily with val-override-ttl: 0 in Unbound config, but that's a last resort.
  • Run a packet capture – Wireshark filter dns.flags.not_implemented == 1 to see which query type triggered the error. It's often an obscure type like NSID (0x29) or TKEY (0x249).

Prevention Tips

Don't assume all DNS servers support modern extensions. For internal networks with legacy servers, keep EDNS0 disabled globally via group policy (Windows) or resolv.conf options. Test new DNS features on a staging server before rolling them out. And if you're running a public DNS server, make sure your software is current—don't be the guy running BIND 9.7 in 2025.

Been there, done that. The NOTIMP error is almost always a server-side limitation, not a client bug. Fix the server or bypass it.

Was this solution helpful?