Fix DNS_ERROR_NOT_ALLOWED_UNDER_DELEGATION 0x0000255B

This error means you're trying to create a DNS record that overlaps a delegation. Happens when a parent zone has a delegation for a subdomain you're editing.

When You'll See This Error

You're in the DNS Manager console on a Windows Server (say, 2016 or 2019), right-click to add a new A record or CNAME under a subdomain zone like sub.example.com. You fill in the name and IP, hit OK — and get hit with this error:

DNS_ERROR_NOT_ALLOWED_UNDER_DELEGATION (0x0000255B)
This record is not allowed under a delegation.

This also shows up if you try to import a zone file with dnscmd or PowerShell's Add-DnsServerResourceRecord and the record conflicts with an existing delegation.

What's Actually Happening

The error means your parent zone (say example.com) has a delegation NS record pointing to another DNS server for sub.example.com. That delegation tells the DNS system: "Hey, I don't own sub.example.com — ask those other servers."

When you then try to add a record inside sub.example.com on the same parent server, the DNS service says: "Nope. You delegated this subdomain away. You can't host records here anymore." The delegation is a hard boundary — once you set it, the parent zone can't contain anything under that subdomain except the delegation NS record itself and any glue records (A/AAAA) for the delegated name servers.

The root cause is simple: you're trying to manage records in a zone that's been handed off. DNS doesn't allow split authority — either the parent owns it, or the child does. Not both.

The Fix

You have two paths depending on what you actually need.

Option 1: Remove the Delegation (If You Want to Manage Records Locally)

Open DNS Manager on the parent zone server.
Find the subdomain folder (e.g., sub.example.com). It'll have a gray folder icon with an NS record inside.
Delete that folder entirely. This removes the delegation NS record and the glue records.
Now you can add your A record, CNAME, or whatever else under sub.example.com — the zone is back under local control.

Option 2: Add Records on the Delegated Server (If the Delegation Is Intentional)

Find which DNS server is authoritative for the delegated subdomain by checking the NS record in the parent zone. It'll list one or more name servers.
Log into that server — it should already have a zone for sub.example.com.
Add the record there. That's where it belongs.
If the remote server doesn't have the zone, you need to set it up first. Create a new primary zone for sub.example.com, then add the records.

What to Check If It Still Fails

If the error persists after removing the delegation, something else might be wrong:

Stale delegations: Open the parent zone and look for any leftover NS records pointing to old servers. Use dnscmd /enumrecords example.com @ NS to list them. Delete any that point to sub.example.com.
Zone replication lag: If you removed the delegation on a primary DNS server but the secondary hasn't picked up the change, the secondary still thinks the delegation exists. Force a zone transfer or wait for the serial number to update.
Active Directory integrated zones: If the zone is AD-integrated, the delegation might be stored in multiple DCs. Check every DNS server in the AD site — one might still hold the old delegation. Use Get-DnsServerZone -Name sub.example.com | fl *delegation* in PowerShell on each.
Read-only domain controllers: If you're working on a RODC, you can't create records at all — the error might be unrelated to delegation. Try the writable DC instead.

Bottom line: this error is a guardrail, not a bug. DNS delegations are meant to be boundaries. Respect them, and the error disappears.