DNS_ERROR_DS_ZONE_ALREADY_EXISTS (0X000025F6) Fix

Most common cause: Stale AD object for a deleted zone

Here's what's happening. You've deleted a DNS zone from the DNS Manager console but Active Directory still holds a reference to it in the directory partition. When you try to re-create the zone — typically during a domain controller promotion or when adding a reverse lookup zone — you get 0X000025F6. The zone looks gone but AD disagrees.

The real trigger is almost always a demoted domain controller that didn't clean up properly, or someone removed a zone via DNS Manager without using dnscmd /ZoneDelete, which would've removed the AD object too. DNS Manager only removes the zone from the local server's cache — it doesn't always delete the AD directory partition entry.

The fix: ADSI Edit to remove the orphaned zone object

1. Open ADSI Edit (add it via Server Manager → Tools if you haven't).
2. Right-click ADSI Edit in the left pane and choose Connect to.
3. In the Connection Settings dialog, under Select a well-known Naming Context, pick Configuration. Click OK.
4. Navigate this path: CN=Configuration,DC=yourdomain,DC=com → CN=Services → CN=MicrosoftDNS → CN=YourZoneName
5. Right-click the zone object and choose Delete. Confirm.

That's it. Reopen DNS Manager, refresh (right-click the server, pick Refresh), and now you can safely re-create the zone. The error won't appear because the AD reference is gone.

Why step 3 works: The MicrosoftDNS container under Configuration holds all AD-integrated DNS zone objects. DNS Manager and the DNSCMD tool both use this path. If you delete a zone without also deleting this object, the zone becomes invisible to DNS Manager but still blocks creation.

Second cause: Replication latency after deleting the zone

If you deleted the zone on one domain controller but others haven't replicated the change yet, you'll see 0X000025F6 when trying to create the zone on a DC that still has the old reference. This happens most often in multi-site environments with slow or broken replication links.

The fix: Force replication or wait

1. Open Active Directory Sites and Services.
2. Expand your site, expand Servers, find the DC where you deleted the zone.
3. Expand NTDS Settings, right-click the connection to the DC that's throwing the error, and choose Replicate Now.
4. Alternatively, run this on the source DC that already has the fix: repadmin /syncall /AdeP

If you're in a hurry, don't wait — force replication. The default replication interval is 180 seconds, but in a broken site link it can take hours. The repadmin command triggers immediate replication across all NCs.

One thing I've seen trip people up: if you deleted the zone from DNS Manager but the zone was AD-integrated, replication might need the DomainDnsZones or ForestDnsZones partition to replicate, not just the Configuration partition. Check repadmin /showrepl for DomainDnsZones — if it shows errors, fix those first.

Third cause: Duplicate zone created accidentally in a different partition

This is rare but happens. Someone (or a script) creates the same zone in both DomainDnsZones and ForestDnsZones. When DNS Manager tries to load the zone, it sees two objects with the same name in different partitions and throws 0X000025F6. You won't see the zone in DNS Manager at all — it just errors out.

The fix: Identify and delete the duplicate partition entry

1. Open a command prompt as admin and run: dnscmd /EnumZones
2. Look for the zone listed twice. It'll show different partition values — DomainDnsZones and ForestDnsZones.
3. Delete the one you don't need. If it's a reverse zone for a forest root, keep the ForestDnsZones copy. If it's an internal domain zone, keep DomainDnsZones.
4. Use: dnscmd /ZoneDelete YourZoneName /DsDel

The /DsDel flag is critical — it tells dnscmd to remove the zone from AD, not just the local cache. Without it, you'll be back in the same situation as the first cause: the zone disappears from the console but lives in AD.

Why you'd get a duplicate: if someone ran dnscmd /ZoneAdd with the wrong partition flag — /DP for domain vs /FP for forest — and the zone already existed in the other partition. Scripts that automate DNS provisioning are the usual culprit here.

Quick-reference summary table

The first cause — orphaned AD object — accounts for maybe 80% of these errors. Start there. You won't break anything by checking ADSI Edit first. And if you're still stuck, check your replication health before assuming something more exotic.