Fix DNS_ERROR_RECORD_ONLY_AT_ZONE_ROOT (0X000025EE)

You're trying to add a DNS record in Windows Server and you get slapped with DNS_ERROR_RECORD_ONLY_AT_ZONE_ROOT (0X000025EE). I've seen this more times than I care to count. It almost always happens when someone tries to create an A or CNAME record that conflicts with the zone's root name. Let me walk you through the fix, from the 30-second check to the deeper cleanup.

What the error actually means

This error means the record you're trying to create already exists at the zone's root, but not in a form that lets you have other records alongside it. The zone root (e.g., contoso.com) has a special set of records — SOA, NS, sometimes an A record if you're doing DNS for the domain itself. You can't just slap a CNAME at the root because the zone already has authoritative records there. The error is your server saying, "That name is taken by the zone itself."

Fix 1: The 30-second check — rename or delete the conflicting record

First, open DNS Manager (or use ADSI Edit if you're feeling masochistic) and look at the zone root. Right-click your zone, choose Properties, and look at the records listed there. You'll see the SOA, NS, and possibly an A record that matches the name you're trying to use.

If you're trying to create an A record for www.contoso.com and you already have an A record at the root pointing to an old server, that's not the conflict. The conflict is when you're trying to create a CNAME at the root or an A record that exactly matches the zone apex. Here's the quick test:

• Are you trying to create a CNAME for contoso.com? That's a big no-no. You can't have a CNAME at the root. Delete it or use an A record instead.
• Are you trying to create an A record for contoso.com when one already exists? Then just edit the existing one instead of creating a new one.

If you find a duplicate or a CNAME at the root, delete it (after verifying it's not needed), and try your original creation again. This resolves the error in about half the cases I've handled.

Fix 2: The 5-minute fix — use a subdomain or adjust the record type

If you're actually trying to point contoso.com to an external service (like a web host or Office 365), you likely need an A record, not a CNAME. But the error might still persist if you haven't removed the old root records properly.

Here's what you do:

1. In DNS Manager, expand your zone (e.g., contoso.com).
2. Look for any record that exactly matches the zone name (the empty parent folder). Right-click and delete any A, CNAME, or AAAA record that's a duplicate or leftover from an old setup.
3. Now, if you need to point the root to a new IP, create a New Host (A) record with the name left blank — that's the root — and enter the IP.

# In DNS Manager UI:
Right-click zone -> New Host (A or AAAA)
Name: (leave blank for zone root)
IP address: 203.0.113.10

But if you're trying to do a CNAME for the root (like for a CDN), stop. DNS rules won't allow it. You need to use an A record or, if you're migrating, use a forwarding service. I've wasted hours on this before I realized the answer was to just change the record type.

Fix 3: The 15+ minute advanced cleanup — check for hidden records and use dnscmd

Sometimes the DNS zone has stale or hidden records that don't show up in the GUI. Blame replication issues or old AD-integrated zones. Here's the advanced path:

Step 1: Use dnscmd to list everything

dnscmd /enumrecords contoso.com @ /detail

This dumps every record at the root. Look for anything odd — a CNAME that shouldn't be there, multiple A records with conflicting IPs, or even a stray NS record pointing to a dead server.

Step 2: Delete the offending record with dnscmd

dnscmd contoso.com /recorddelete contoso.com A 203.0.113.5 /f

Replace contoso.com with your zone name, the record type, and the IP. The /f skips the confirmation prompt.

Step 3: Check for application partitions

If this is an AD-integrated zone, the record might be in the DomainDnsZones or ForestDnsZones partition. You'll need to connect to that partition:

dnscmd /enumrecords contoso.com @ /detail /partition:DomainDnsZones

Then delete from there as well. I've seen root records duplicated across partitions that caused this exact error.

Step 4: Verify after deletion

dnscmd /enumrecords contoso.com @ /type:A

Make sure you see the correct A record. Then try your original operation again.

Pro tip: If you're using a third-party DNS (like on a web host), this error can also appear because the zone root has DS records (DNSSEC) that conflict. In that case, you need to disable DNSSEC for the zone temporarily, fix the record, then re-enable.

Why this error happens in the real world

I've seen this most often during Office 365 migrations. Someone tries to create a CNAME for contoso.com (for autodiscover or verification) and hits this error because the root already has an A record from an old website. The fix is usually to delete the old A record and create a new one with the correct IP, or use a subdomain like autodiscover.contoso.com instead.

Another common trigger: someone accidentally creates an A record at the root when they meant to create it for a host. Then later they try to add a different record type and the server rejects it. Clean out the root, and you're good.

Prevention for next time

Stop creating records at the zone root unless you absolutely have to. Use subdomains for everything. The root is reserved for SOA, NS, and possibly one A record for the main site. If you need to point to a CDN, use a CNAME on a subdomain and configure your app to use that subdomain. It saves you from this headache.

If you've tried all three fixes and still get the error, check if the zone is read-only or if you're working on a read-only domain controller. I've seen that too — the DNS zone is read-only, and the error is misleading. You'll need to make the change on a writable DC.

That's the whole battle plan. Start with the quick check, move to the subdomain fix, and only dig into dnscmd if you're still stuck. Nine times out of ten, it's a duplicate record or a CNAME at the root that needs to go.