Fix DNS RCODE REFUSED (0x232D) – Step-by-Step

Quick answer

Point your client to a different DNS server, or on the server, enable recursion / fix the forwarder IP and confirm the zone exists. Then flush and retest.

What's actually happening here is your DNS client sent a query, and the server answered with RCODE 5 (REFUSED) instead of an answer. That's not a timeout and not NXDOMAIN — the server is deliberately saying “I won't answer that.” The reason step 3 works is often a policy problem, not a network problem.

REFUSED comes from Microsoft's DNS role, BIND, or any resolver when it thinks the query falls outside its authority and it isn't allowed to recurse or forward. It can also pop up when the zone exists but the server isn't authoritative for it (like after a failed zone transfer). You'll see this error in Windows Event Viewer as event ID 409 or 6001, or just as a red banner when you run nslookup from a domain-joined machine.

Why you're seeing 0x0000232D

Let's be specific. In Windows, 0x0000232D is the hex form of error 9005 (DNS_ERROR_RCODE_REFUSED). It maps to the DNS response code 5. The server got your query and decided it wouldn't process it. Common triggers:

You set a forwarder to an IP that doesn't answer recursion (like a root hint only server).
The DNS server is configured to only allow recursion on specific IPs, and your client isn't in the allow list.
A conditional forwarder points to a server that isn't authoritative for that zone.
The zone is present but not loaded (bad zone file, or secondary zone failed to transfer).
IPv6 is used but the server is bound only to IPv4 (or vice versa).

Fix steps (in order of likelihood)

Test with nslookup against a public DNS. Run nslookup example.com 8.8.8.8. If that works, your issue is with your internal DNS server. If it also refuses, your firewall is dropping or resetting DNS queries — check that UDP 53 isn't being filtered.
```
nslookup example.com 8.8.8.8
```
Check if the zone actually exists. On the DNS server, open dnsmgmt.msc. Look for your forward lookup zone. If it's missing, the server has no authority and will refuse queries for it. If it's there, right-click and check if it shows “Not loaded.” That happens when the zone file is corrupt or the zone was deleted and recreated.
Verify recursion settings. In DNS Manager, right-click the server → Properties → Forwarders. If you've set a forwarder, make sure it's reachable. Then go to the Advanced tab and check “Disable recursion (also disables forwarders).” If that box is checked, uncheck it. Windows Server 2016+ sometimes turns this on after a security baseline script runs.
```
dnscmd /ServerName /Config /DisableRecursion 0
```
Check your conditional forwarders. If the refused domain is one you defined in Conditional Forwarders, the target server must be authoritative for that zone. Test with nslookup thedomain.com <that server's IP>. If that returns REFUSED too, the problem is on the other side — fix that server, not yours.
Look at scoping. Windows DNS allows you to set recursion on a per-scope basis (DNS policies). If someone created a scope with a different recursion setting, your query might land on a scope that refuses. Run dnscmd /info /scope to list scopes, and check if the default scope is the one doing the refusing.

Alternative fixes when the above doesn't work

Restart the DNS service. Sounds basic, but after a zone transfer failure, the service can hold a stale state. Restart-Service DNS on the server.
Flush your client cache. Sometimes your machine caches the REFUSED response and keeps reusing it. ipconfig /flushdns then ipconfig /registerdns.
Disable IPv6 on the client (temporarily). If the client tries an AAAA query over IPv6 and the server refuses because it's not listening on IPv6, you'll get REFUSED. Uncheck IPv6 on the adapter, flush, and retest. If it works, fix your server's IPv6 binding instead of leaving this off.
Check the firewall on the DNS server itself. Windows Firewall has a rule for DNS, but if you're running a third-party firewall or a hardened GPO, it might allow UDP 53 but block TCP 53. Some clients fall back to TCP when they get a truncated response, and if TCP is blocked, the server sends REFUSED. Allow both UDP and TCP 53 inbound.

Prevention tip

The single most common cause I see in production is people setting a forwarder to their ISP's DNS without testing if that ISP allows recursion from your IP. Some ISPs block DNS queries from outside their network, so your server gets REFUSED and returns it to you. Always test the forwarder with nslookup example.com <forwarder IP> before saving it. If it refuses, use a public DNS like 8.8.8.8 or 1.1.1.1 instead.

Also, if you run DNS policies or scopes, document them. I've debugged hour-long outages that turned out to be a leftover conditional forwarder from a decommissioned domain controller. Clean those out.

Remember: REFUSED is a positive answer. The server heard you. It just won't play. That makes it easier to debug than a timeout — you know the packet arrived.