Fix DNS_ERROR_INCONSISTENT_ROOT_HINTS 0x255D on Windows Server

What 0x255D actually means

DNS_ERROR_INCONSISTENT_ROOT_HINTS (0x0000255D) shows up when your DNS server has multiple network adapters and the root hints it pulls from each one don't match. In plain English: the server is hearing two different answers about where the internet's root DNS servers live, and it refuses to guess. You'll usually see this as Event ID 4013 in the DNS Server log, or the service flat-out fails to start with a 0x255D in the event description.

I had a client last month — a dental office running a Server 2019 box as their DC and DNS. They added a second NIC for a dedicated backup VLAN and DNS died on reboot. Same error. The server was pulling root hints from both NICs, and the secondary adapter was hitting a stale cached root hints file left over from a previous vendor migration. Took ten minutes once I knew where to look.

Three things cause this in the wild: a stale or corrupted Cache.dns file, a genuine mismatch between root hints configured on the server vs. what the adapters see, or a multihomed box where one adapter can't actually reach the roots. Fix them in that order.

Cause 1: Corrupted or stale Cache.dns file (start here)

This is the one you'll fix nine times out of ten. Windows keeps a cached copy of the root hints in %SystemRoot%\System32\DNS\Cache.dns. If that file got mangled — bad shutdown, failed update, half-finished migration — the DNS service reads inconsistent data and throws 0x255D on startup. It's boring, but it's almost always the culprit.

Here's the fix:

1. Open an elevated Command Prompt or PowerShell on the DNS server.
2. Stop the DNS service: net stop dns
3. Navigate to C:\Windows\System32\DNS
4. Rename the existing file: ren Cache.dns Cache.dns.old
5. Copy a fresh one from a known-good server in the same AD site, or pull it from %SystemRoot%\System32\DNS\Backup\ if you've got backups enabled.
6. Restart DNS: net start dns

If you don't have a clean copy handy, you can rebuild it. Open DNS Manager, right-click the server, Properties, Root Hints tab, and click "Copy from Server" pointing at a working DNS box (8.8.8.8 works in a pinch — it'll return the standard IANA root list). Then right-click the server again and pick "Update Server Data Files." That rewrites Cache.dns on disk.

One gotcha: if you've disabled recursion or you're running a root-only DNS server, don't do this. It'll whack your config. Check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters for the NoRecursion value before you touch anything.

Cause 2: Root hints genuinely mismatched across adapters

If you've got a multihomed server — two NICs, or one NIC plus a VPN tunnel adapter — each interface can present a different view of the network. The DNS service tries to reconcile root hints across all bound adapters and bails with 0x255D when they disagree. This bites people who add a second NIC for a management VLAN and forget that DNS binds to it by default.

Fix it by telling DNS to only listen on the interfaces you actually want it on:

1. Open DNS Manager.
2. Right-click your server, Properties, Interface tab.
3. Select "Only the following IP addresses" and check just the adapter(s) that should serve DNS. Typically the LAN NIC, not the backup/management/VPN one.
4. Click OK, then restart the DNS service.

While you're in there, verify the root hints themselves. Properties, Root Hints tab — you should see 13 entries (a through m.root-servers.net). If you see duplicates, stale IPs, or anything pointing at an internal server, that's your mismatch. Click "Copy from Server" and point it at a public resolver to refresh.

You can also check this from the command line:

dnscmd /zoneinfo .
dnscmd /enumrecords . @ /type=NS

If the NS records for the root zone don't match what's in the Root Hints tab, you've confirmed the mismatch. Rebuild the hints and restart the service.

Cause 3: Adapter can't reach the root servers (firewall or routing)

Less common but nastier. If one of your adapters has no route to the internet — say it's on an isolated VLAN — the DNS service can't verify root hints from that interface and reports inconsistency. The error looks identical to a corrupted file, but replacing Cache.dns won't help because the underlying problem is network reachability.

Test it from the box:

nslookup . 198.41.0.4
ping 198.41.0.4

198.41.0.4 is a.root-servers.net. If that times out from one adapter but works from the other, you've found it. The fix is either to remove that adapter from DNS's listen list (see Cause 2, step 3) or to properly route it out to the internet with the correct default gateway.

Firewalls trip this too. I've seen SonicWall and FortiGate setups block UDP 53 outbound to the root servers while permitting it to configured forwarders. The DNS server sees inconsistency because it can't reach the roots directly. If you're using forwarders anyway, consider dropping root hints entirely — Properties, Root Hints tab, and remove them. Windows will still resolve via forwarders. Cleaner config, fewer moving parts.

Quick sanity check before you dig deeper: run ipconfig /all and confirm each adapter has the DNS settings you expect. I've fixed this error twice where the "problem" was a stale IPv6 DNS entry on a disabled adapter that Windows hadn't cleaned up.

Quick-reference summary

Nine times out of ten, stop the DNS service, nuke Cache.dns, restart, done. If that doesn't clear 0x255D, you've got a multihomed problem — check what interfaces DNS is bound to and trim the list. And if you're running forwarders, just delete the root hints. They're redundant and they're what's causing the headache.