Fix DNS_ERROR_UNKNOWN_RECORD_TYPE (0X000025E8)
The server doesn't recognize a DNS record type you're trying to add or query. Simple fix: update DNS server or client software, or check the record type for typos.
You hit this error. Let's get you past it.
You're trying to add or query a DNS record, and the server spits back 0X000025E8. That's the server telling you, plainly, "I don't know what this record type is." It's not a network problem or a permissions issue. It's a type mismatch. Here's how to make it go away.
The fix
There are two common paths. Pick the one that matches your situation.
1. Update your DNS server software
If your DNS server is older than the record type you're trying to use, this is the most likely cause. For example, a Windows Server 2008 R2 server doesn't support newer record types like TLSA or CAA. These were introduced in later versions of the DNS protocol and in Windows Server 2012 R2+.
What to do: Upgrade the DNS server to a version that supports the record type. On Windows, that means at least Server 2012 R2 for TLSA records, or Server 2016 for CAA. On BIND, you'd need version 9.9+ for TLSA, 9.10+ for CAA.
The real-world trigger: You're trying to set up DANE/TLSA for email security on an old Domain Controller running Server 2008 R2. That server just doesn't know TLSA. The fix is to install a newer server or use a different DNS hosting service.
2. Update your DNS client / management tool
Sometimes the error comes from the tool you're using to make the query or add the record. Older versions of nslookup, dig, or the DNS Manager MMC snap-in might not recognize newer record types.
What to do: Use a current version of the client tool. On Windows, run dnsmgmt.msc from a Server 2016 or newer machine—don't try to manage a 2016 server from a Windows 7 RSAT. On Linux, update bind-utils (for dig) or ldns.
Check for typos in the record type
Obvious but worth saying: make sure you're not misspelling the record type. Case doesn't matter in DNS (record types are case-insensitive), but a typo like 'TLS' instead of 'TLSA' will produce exactly this error. Check the exact string you're using.
Why this works
What's actually happening here is the DNS server or client has a fixed list of recognized record types. When you present a type that's not in that list, the response is RCODE 3 (NXDOMAIN? No, actually RCODE 4—NOTIMP) for unknown record types, but in Windows DNS, it manifests as this specific error code. The server is not being difficult; it's being honest. It literally doesn't have a handler for that record type in its code.
Updating the software adds new handlers. The reason step 1 (updating the server) works is that newer DNS software includes support for newer IANA-registered record types. Every time the IANA adds a record type (TLSA in 2012, CAA in 2013, etc.), DNS server vendors patch their code to interpret them. This isn't a bug fix—it's a feature addition you're missing.
The reason step 2 (updating the client) works is that the client tool might not even send the right wire format for the type. Old dig might send a generic "TYPE1234" request, which the server might not translate correctly. Newer clients send the proper type number and expected query format.
Less common variations
Private or custom record types
Some third-party DNS systems let you define custom types (e.g., type 65432 for proprietary data). If you try to add that to a Microsoft DNS server that doesn't know about it, you'll get 0X000025E8. The workaround: use a different DNS server that supports the custom type, or use a TXT record with custom parsing instead.
Zone transfer issues
If you're doing a zone transfer and the secondary server doesn't support a record type the primary serves, the secondary might throw this error during AXFR or IXFR. The fix: make sure both servers are on compatible software versions. Or, filter out unsupported record types from the zone.
Overflow in signed zones
Rare, but if you're using DNSSEC and a record type is defined in the signed zone but not understood by the validating resolver, you can see similar errors. This usually points to a resolver needing an update rather than the authoritative server.
Prevention
Keep your DNS infrastructure updated. This is one of those cases where running ancient software is a direct cause of problems. Set a policy: DNS servers and management tools should be no more than one major version behind current.
Document the record types you use. If you need TLSA, CAA, SSHFP, or SVCB, make sure every DNS server in your chain supports them before deploying.
Test additions in a lab environment. Spin up a VM with the target server version, create a test zone, and try adding the record. If it fails there, you know the server needs an upgrade before production.
That's it. Update the software, check the spelling, and move on.
Was this solution helpful?