DNS_ERROR_RCODE_NOTAUTH 0x00002331 Fix — DNS not authoritative

1. Stale or Misconfigured Conditional Forwarder

This is the number one cause I've seen in the wild. A client had a DNS server that couldn't resolve app.corp.example.com. The query came back with DNS_ERROR_RCODE_NOTAUTH. The server was trying to forward the query to a DNS server that didn't own the zone—it was just a forwarder pointing to an old IP.

When a DNS server gets a request for a zone it's not authoritative for, and it has a conditional forwarder for that zone pointing to a server that also isn't authoritative (or is unreachable), the error pops up. The original server says, "I don't own this, but I'll ask my friend over there," and the friend responds with NOTAUTH.

How to check and fix it

1. Open DNS Manager
2. Right-click the server → Conditional Forwarders
3. Look for any zone that maps to the domain you're failing on
4. Check the IP addresses listed. Run nslookup -type=ns from a reliable source (like your ISP's DNS) to see what the actual authoritative servers are
5. If the forwarder points to a server that doesn't own the zone (e.g., it's an old DC or a random public DNS), delete it or update the IP

I had a client last month whose entire print queue died because of this—their print server's DNS forwarder for the parent domain pointed to a decommissioned DC. Took me 15 minutes to find, 30 seconds to fix.

2. Missing or Incorrect Zone Delegation

This one's common in split DNS setups or when you have a child zone like dev.company.com hosted on a different server than company.com. If the parent zone (company.com) doesn't have NS records pointing to the child's server, any query for server.dev.company.com will fail with NOTAUTH—because the parent's DNS doesn't know where to send the query.

Here's the tell: if you query server.dev.company.com from the parent DNS and get NOTAUTH, but you can query server.dev.company.com directly from the child's DNS and get a result, it's a delegation problem.

Fix it

1. On the parent DNS server (e.g., authoritative for company.com), open DNS Manager
2. Right-click the parent zone → New Delegation
3. Enter the child zone name (e.g., dev)
4. Add the NS records for the child's DNS server(s)
5. Wait for TTL to expire or force replication

Don't forget to check the child's zone to make sure it has SOA and NS records set correctly. I've seen cases where someone copied a zone but forgot to update the SOA—causing "not authoritative" errors even with proper delegation.

3. Stub Zone Conflicts with Forwarder

Stub zones are handy but they can bite you. If you've got a stub zone for a domain and a conditional forwarder for the same domain, the server gets confused. The stub zone says, "I'm authoritative for this domain" (sort of), but the forwarder says, "No, send it here." Result: NOTAUTH.

I ran into this at a law firm that had an old stub zone leftover from a merger. The stub zone pointed to a server that no longer existed. Any query to that domain threw NOTAUTH. The fix was simple: delete the stub zone.

Check and resolve

1. In DNS Manager, expand Forward Lookup Zones
2. Look for zones with type Stub that match the failing domain
3. If the stub zone's master servers are offline or wrong, delete it or update it
4. Also check Conditional Forwarders for the same domain—remove one of them

Quick-Reference Summary Table

Most of the time, it's the forwarder. Start there. If you still see the error after checking all three, run a packet capture with Wireshark or Microsoft Network Monitor to see exactly which server is sending the NOTAUTH response. That'll point you straight to the misconfigured box. Good luck.