DNS_ERROR_INVALID_ZONE_TYPE (0X0000258B) Fixes
This error pops up when Windows Server DNS can't create or load a zone because the zone type is wrong. Most common cause: using Primary zone type on a domain controller without AD integration.
1. Most common cause: Zone type mismatch on a domain controller
This is the one I see 9 times out of 10. You're on a domain controller running Windows Server 2016, 2019, or 2022. You try to create a new forward lookup zone—say, contoso.local—and bam, error 0X0000258B. The fix is almost always the same: your zone type doesn’t match your DNS server role.
Here’s the rule: if a DNS server is also a domain controller, you must use an Active Directory-integrated zone. A plain Primary zone won’t work. The DNS service sees the server is a DC, expects AD integration, and rejects any other type with this error code.
How to fix it
- Open DNS Manager. You can get there by running
dnsmgmt.mscfrom an admin command prompt. - Right-click the server name at the top left and choose “Properties.” Check that the server is listed as a domain controller. If it is, proceed.
- Right-click “Forward Lookup Zones” and pick “New Zone.”
- On the Zone Type page, pick “Primary zone.” Then check the box that says “Store the zone in Active Directory.” That’s the critical step people miss.
- After checking that box, the next page will ask about replication scope. Pick “To all DNS servers running on domain controllers in this domain” unless your environment has a specific reason not to. I always pick that one for standard setups.
- Complete the wizard. After you click Finish, you should see the new zone appear instantly, no error.
What if you already have a zone that’s showing error 0X0000258B? Delete it and recreate using the steps above. Don’t try converting an existing Primary zone to AD-integrated through the GUI—it’s flaky and often corrupts the zone data. I learned that the hard way. Just delete and start fresh.
2. Second most common cause: Orphaned zone files from a previous DNS server migration
This one usually happens after you migrate DNS from one server to another, or after a server upgrade. You see the error when the DNS server tries to load an existing zone at startup. The zone file on disk is still in plain-text Primary format, but the new server expects AD-integrated format.
The real trigger: you moved the .dns zone file from an old standalone DNS server to a new server that’s now a domain controller. The old file has no AD attributes, so the new server rejects it.
How to fix it
- Stop the DNS service. Run this command as admin:
net stop dns - Go to
C:\Windows\System32\dns. Find the zone file for the problem zone. It’ll be named something likecontoso.local.dns. - Rename that file. I add “_old” to the extension, like
contoso.local.dns_old. This keeps a backup in case you need it. - Start the DNS service again:
net start dns - Now create a brand new AD-integrated Primary zone using the steps in fix #1. Your DNS server will build a fresh zone file with the correct format.
- If you need the old records back, you can import them. Open the
.dns_oldfile in Notepad, copy the resource records (the lines that start with @ or hostnames), and manually add them to the new zone. It’s tedious but reliable. For large zones, script it with PowerShell.
3. Third most common cause: Replication issues with AD-integrated zones
This is rarer, but when it happens it’s a head-scratcher. You already have an AD-integrated zone that was working fine. Then after an AD replication failure or a domain controller restore from backup, you see error 0X0000258B for that zone. The zone is still in AD, but its object got corrupted or the zone type attribute flipped to something invalid.
You’ll notice the zone is listed in DNS Manager but shows a red X. Right-clicking it gives you “Properties” grayed out. That’s the tell.
How to fix it
- First, check AD replication health. Run this command on the affected domain controller:
If you see errors, fix replication first. That alone can clear the DNS error because the zone object will re-sync properly.repadmin /replsum - If replication is healthy, you need to delete the zone object from AD and recreate it. Open ADSI Edit (run
adsiedit.msc). Connect to the Default naming context. - Navigate to
CN=MicrosoftDNS,CN=System,DC=yourdomain,DC=local. Expand the “MicrosoftDNS” container, then “ZoneCache” or “Zones” (the path varies slightly by OS version). Find the problem zone. - Right-click the zone object and delete it. Confirm the dialog.
- Back in DNS Manager, right-click “Forward Lookup Zones” and create a new AD-integrated Primary zone with the same name. The records are gone, so you’ll need to repopulate them from a backup or manually.
A faster way if you have another healthy DNS server: force a replication of just that zone. On the healthy server, right-click the zone, go to Properties, and check the Zone Type tab. Make sure it’s AD-integrated (Primary). Then on the broken server, run dnscmd /ZoneResetType zonename /Primary /Ds. This resets the zone type attribute without deleting the zone. I’ve had mixed results with this command, so only try it if you can’t afford to delete the zone.
Quick reference summary table
| Cause | Symptoms | Fix |
|---|---|---|
| Zone type mismatch on a DC | Error when creating a new zone; AD integration checkbox wasn’t checked | Create zone with AD integration enabled; delete and recreate existing zones |
| Orphaned zone file from migration | Error at DNS service startup; zone file in \dns folder is old format | Rename old .dns file, create new AD-integrated zone, re-add records |
| Corrupted AD zone object after replication failure | Existing zone shows red X; properties grayed out | Fix AD replication, then delete and recreate zone via ADSI Edit or dnscmd |
Was this solution helpful?