Fix 0X0000214C DNS Lookup Failure in Active Directory

You're stuck on this error. Let's fix it.

That 0X0000214C error usually shows up when you're trying to promote a new domain controller, join a machine to the domain, or run an AD tool like DSA.msc. The exact message reads: "The DSA operation is unable to proceed because of a DNS lookup failure." It's frustrating because everything else on the network seems fine. But here's the thing: Active Directory is picky about DNS. It's not just about resolving names — it's about resolving the right SRV records.

I've seen this a hundred times. The fix is almost always the same. Let's walk through it.

The primary fix: Check your DNS server configuration

Here's the step-by-step. I'm assuming you're on Windows Server 2016, 2019, or 2022. The process is the same for all three.

1. Log in to the server that's throwing the error. Use an account with domain admin privileges.
2. Open Network Connections. Press Windows + R, type ncpa.cpl, hit Enter.
3. Right-click the network adapter that's connected to your domain network (usually Ethernet0 or similar). Select Properties.
4. In the list, scroll down to Internet Protocol Version 4 (TCP/IPv4). Select it, then click Properties.
5. Look at the DNS server addresses. Here's the rule: The primary DNS server must be another domain controller that hosts Active Directory — or this server itself if it's already a DC. Never point a DC's primary DNS to an external IP like 8.8.8.8 or your ISP's DNS. That breaks AD.
6. If you're promoting this server to a DC, set the primary DNS to the IP of an existing DC. The secondary can be another DC or left blank. Do not set it to 127.0.0.1 yet — that causes loop errors during promotion.
7. Click OK on all dialogs to save changes.
8. Open a command prompt as Administrator. Run ipconfig /flushdns to clear the local cache.
9. Then run ipconfig /registerdns to force a refresh.
10. Now test DNS resolution. Run nslookup -type=SRV _ldap._tcp.dc._msdcs.<yourdomain.com>. Replace yourdomain.com with your actual domain name. You should see at least one SRV record pointing to a DC.

After you do that, retry the operation that failed. In 9 out of 10 cases, it works immediately.

Why this works

Active Directory depends on SRV records in DNS to locate domain controllers. When a server tries to start a DSA operation (like replication or authentication), it queries DNS for those records. If the DNS server can't answer — because it's not authoritative for the domain, or the zone is missing — you get the 0X0000214C error. By pointing the NIC to a proper AD-integrated DNS server, you're giving the system the right source for those records. The flush and register steps clear any stale data and force a fresh lookup.

Less common variations of the same issue

Sometimes the NIC config is fine but the problem runs deeper. Here are three other scenarios I've run into.

1. The DNS zone is missing or corrupt

Open DNS Manager on a working DC. Expand the server, then Forward Lookup Zones. You should see a zone named after your domain (e.g., contoso.com). Inside, there should be folders like _tcp, _udp, and _msdcs. If any are missing or look empty, right-click the zone and select Reload. If that doesn't help, run this command on a DC:

dnscmd /ZoneResetType <yourdomain.com> /Primary

This rebuilds the zone. You'll need to restart the DNS service afterward: net stop dns && net start dns.

2. The wrong DNS suffix is appended

Go back to the NIC settings. Click Advanced, then the DNS tab. Make sure Append primary and connection specific DNS suffixes is selected and that the primary DNS suffix matches your domain. If it's set to something else (like a parent domain that doesn't have AD), change it. This one trips up people who have a multi-level domain like corp.company.local.

3. Firewall or network ACLs blocking DNS

If you're on a segmented network, check that UDP port 53 is open between this server and the DNS server. Use Test-NetConnection -ComputerName <DNS_IP> -Port 53 in PowerShell. If it fails, talk to your network team. Also verify TCP 53 for zone transfers, though that's less common in this scenario.

How to prevent this from happening again

Set up your DNS infrastructure right from the start. Here's what I recommend:

• Use at least two DCs, each with DNS installed. Point each DC's primary DNS to the other DC, and secondary to itself. For example, DC1 primary = DC2 IP, secondary = 127.0.0.1. DC2 primary = DC1 IP, secondary = 127.0.0.1. This gives redundancy without loops.
• Never change a DC's DNS settings after it's promoted unless you know exactly what you're doing. A wrong change can break replication across the whole domain.
• Monitor DNS health with tools like dcdiag /test:dns. Run it monthly. It catches issues like missing records before they cause errors.
• Document your DNS IP scheme in a place your team can access. When I see this error in a new environment, it's almost always because someone forgot what the DNS servers were supposed to be during a rebuild.

That's it. Fix the DNS lookup, and the DSA operation will go through. You don't need to rebuild the server or reinstall AD — just get the DNS pointing right.