You're not alone — this error is a head-scratcher
I know this error is infuriating because it appears right when you think you've cleaned up a stale DNS zone. 0X000025F4 — DNS_WARNING_DOMAIN_UNDELETED — means the DNS server detected that a domain you thought was gone is back. It's not a full failure; it's a warning that the deletion didn't take. I've seen this happen most often on Windows Server 2016 and 2019 domain controllers after a failed AD replication or a DNS scavenging mistake.
The fix: re-delete the zone properly
Skip the GUI retry for now. The registry or AD might be holding a ghost. Let's force it out.
Step 1: Identify the offending zone
Open Event Viewer (Eventvwr.msc), go to Applications and Services Logs > DNS Server. Look for event ID 414 with the error code 0X000025F4. The description will name the zone (e.g., ghostzone.example.com). Note it down.
Step 2: Delete the zone using DNS Manager
Open dnsmgmt.msc. Expand your server, go to Forward Lookup Zones. Right-click the problematic zone and choose Delete. Check “Delete zone from Active Directory” if it's an AD-integrated zone. Then hit OK. Wait 15 seconds, then refresh. If the zone reappears, you need the backup plan — the registry delete.
Step 3: Registry delete (when AD delete fails)
This tripped me up the first time too. If the zone keeps coming back, it's often because a stale registry entry or a lingering AD object resurrects it. Open regedit and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\ZonesUnder Zones, you'll see subkeys named after zone IDs (GUIDs). Look for one matching your zone name. Right-click and Export it as a backup, then delete the key. Close regedit. Then restart the DNS service:
net stop dns && net start dnsStep 4: Verify the zone is gone
Open DNS Manager again. Right-click the server, choose Clear Cache, then refresh zones. If the zone is gone, you're done. If it's still there, you might have a replication conflict. Head to the next section.
Why this works
The error 0X000025F4 specifically means the DNS server tried to delete a zone, but the delete was undone — usually because another domain controller had a stale copy that got replicated back. By killing the zone through both the AD database (via DNS Manager) and the local registry, you remove both the live and cached references. Restarting the DNS service forces the server to rebuild its zone list from AD and the registry, so the ghost zone can't come back.
On Windows Server 2012 R2 and earlier, I've also seen this error when the DNS server role is installed on a read-only domain controller (RODC). In that case, you need to delete the zone from the writable DC first, then force replication. The RODC won't let you delete it directly.
Less common variations of the same error
Scenario A: Stub zone won't delete
Stub zones sometimes resist deletion because the master server is unreachable. The fix: use PowerShell to remove it without trying to refresh the master:
Remove-DnsServerZone -Name "stubzone.example.com" -ComputerName "YourDNSServer" -ForceThe -Force flag bypasses the check against the master.
Scenario B: Secondary zone undeleted
If you're getting 0X000025F4 on a secondary zone, the master server may be sending a zone transfer that recreates the zone. Stop the zone transfer temporarily: in DNS Manager, go to the zone properties, Zone Transfers tab, uncheck Allow zone transfers. Then delete the zone. After deletion, re-enable transfers if needed.
Scenario C: AD-integrated zone with lingering domain controller
Sometimes a decommissioned DC still holds a copy of the zone in its NTDS database. Use Active Directory Sites and Services to force replication from all remaining DCs. Run repadmin /syncall on a healthy DC. Then delete the zone again. If the zombie DC is offline, you may need to remove its metadata manually:
ntdsutil -metadata cleanupPrevention tips
- Always delete AD-integrated zones from DNS Manager, not directly in ADSI Edit. The DNS Manager sends the proper tombstone and replication updates.
- Run
dcdiag /test:dnsmonthly to catch stale zones before they cause warnings. - Set DNS scavenging on your zones (right-click server > Properties > Advanced > Enable automatic scavenging). This auto-removes stale records that could trigger undeleted zone errors.
- When you decommission a DC, first transfer the DNS role to another server, then remove the zone from the old DC's DNS list using
dnscmd /ZoneDeletefrom an elevated command prompt.
If you've followed these steps and still see the error, check your event logs for event ID 408 or 409 — they'll point to a replication partner that's holding a copy of the zone. Fix that DC first, then come back to delete the zone. Trust me, it saves hours.