DNS_ERROR_NON_RFC_NAME (0X00002554) – Fix Invalid DNS Names Fast

Why This Error Happens (and the One Fix Most People Need)

If you're staring at DNS_ERROR_NON_RFC_NAME (0X00002554), here's the short version: your DNS name broke RFC 952 and 1123. Those old specs say hostnames can only have letters, numbers, and hyphens. No underscores. No spaces. No weird punctuation.

I see this most often when someone tries to create a host record with an underscore in the name. Like my_server.domain.com instead of myserver.domain.com. Windows DNS server, especially on Server 2016 and later, will reject that out of the box. Had a client last month whose entire print queue died because someone named a printer HP_ColorLaser and the DNS record wouldn't stick.

Let's fix it.

Fix #1: The Underscore in Host Records (Most Common)

This is the number one trigger. You create an A or CNAME record, and the name contains an underscore. Windows DNS says no.

Step 1: Check the Record Name

Open DNS Manager (dnsmgmt.msc). Look for the record that's failing. If the name has an underscore, that's your culprit.

For example: dev_server.domain.com is invalid. dev-server.domain.com is fine.

Step 2: Rename or Recreate Without Underscores

Right-click the record and delete it. Then create a new one using hyphens instead of underscores. Or just remove the underscore entirely.

Old: dev_server.domain.com → A → 192.168.1.10
New: dev-server.domain.com → A → 192.168.1.10

If the device name itself has an underscore (like a Windows hostname), you'll need to rename the device first. Not fun, but it's the clean fix. You can do it through System Properties or PowerShell:

Rename-Computer -NewName "dev-server" -Restart

Fix #2: SRV Records with Underscores (It's Actually Required Here)

Here's where it gets tricky. SRV records — used by Active Directory, LDAP, Kerberos — require underscores in their service names. _ldap._tcp.domain.com is correct and RFC-compliant for SRV records.

But if you're trying to manually create an SRV record and the DNS server throws 0X00002554, the problem is usually in the target hostname, not the service name.

The fix: Check the "host offering this service" field. It must be a valid RFC hostname — no underscores. The service and protocol fields can have underscores, but not the destination.

Example of a bad SRV record:

• Service: _sip
• Protocol: _tcp
• Target: sip_server.domain.com ← This is the problem

Fix it by changing the target to sip-server.domain.com or sipserver.domain.com.

Fix #3: Allow Non-RFC Names via Registry (Use with Caution)

Sometimes you don't control the external application or device. It sends DNS updates with underscores, and you can't change it. Microsoft gives you an escape hatch, but it's ugly and I don't recommend it for security reasons.

The workaround: Turn off strict RFC compliance on the DNS server.

Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

Create a DWORD value named AllowUnderscoresInHostRecords. Set it to 1. Then restart the DNS service.

That lets you create host records with underscores. But here's the catch: lots of older or stricter DNS clients (like BIND or older Linux resolvers) will reject those records. You might fix one server and break queries from everywhere else.

I've only used this once — for a legacy application that sent dynamic updates with underscores and couldn't be patched. Otherwise, avoid it.

Quick-Reference Summary

Bottom line: 90% of the time, it's an underscore in a hostname. Drop the underscore, use a hyphen, and move on. The registry hack exists but you'll regret it later. Don't use it unless you absolutely have to.