Fix ERROR_NO_SUCH_DOMAIN (0X0000054B) – Domain Not Found
You're seeing this error when trying to join a domain or access network resources. It means Windows can't find or talk to the domain controller. Here's how to fix it starting with the quick stuff.
What's this error really mean?
When you see ERROR_NO_SUCH_DOMAIN (0X0000054B), Windows is telling you it tried to find a domain controller for the domain you specified—and came up empty. This usually happens during a domain join or when mapping a network drive using a domain-based path. The two most common triggers are: you typed the domain name wrong, or your DNS isn't pointing to the right server.
Don't waste time panicking. Start with the simplest fix. You'll be done in 30 seconds or less.
The 30-second fix: Check your domain name spelling
I know it sounds dumb, but I've seen senior admins type "contoso" instead of "contoso.com" and spend an hour chasing ghosts. Double-check what you typed.
- If you're joining a domain, look at the Domain field in the System Properties window. It should match your Active Directory domain name—usually something like
company.localorcompany.com. - If you're mapping a drive, the path should look like
\\domain\share. Don't put extra slashes or spaces. - Try pinging the domain name from a command prompt:
If it resolves to an IP, move on. If not, that's your problem—skip to the DNS fix below.ping contoso.com
Expected outcome: After fixing the domain name, you'll get past the initial error. If it still fails, move to the next section.
The 5-minute fix: Fix DNS resolution
Nine times out of ten, this error is a DNS issue. Your computer needs to find a domain controller by querying DNS for SRV records. If the DNS server is wrong or unreachable, you get 0X0000054B.
Step 1: Check your DNS server settings
- Open Network Connections (press
Win + R, typencpa.cpl, hit Enter). - Right-click your active network adapter (usually Ethernet or Wi-Fi), choose Properties.
- Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
- Make sure Use the following DNS server addresses is selected. Enter the IP of your internal DNS server—not 8.8.8.8. For a domain join, you need the DNS server that hosts the domain's zone.
- Click OK twice to close everything.
After doing this, you should see the DNS server field updated. If you're not sure what IP to use, ask your network admin or check the DHCP settings—your router might hand out the wrong DNS.
Step 2: Flush DNS cache
- Open Command Prompt as administrator (right-click Start, choose Command Prompt (Admin) or Windows Terminal (Admin)).
- Type:
Press Enter. You should see Successfully flushed the DNS Resolver Cache.ipconfig /flushdns - Then type:
This forces your computer to re-register with DNS. Wait a few seconds.ipconfig /registerdns
Step 3: Test domain controller discovery
Run this command:
nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.com (replace yourdomain.com with your actual domain). If you get a server response with an IP, your DNS is working. If you get Non-existent domain, DNS is your problem.
Expected outcome: After fixing DNS, retry the domain join or drive mapping. It should work now. If not, proceed to the advanced fix.
The 15+ minute fix: Network connectivity and firewall checks
If DNS is fine but the error persists, there's something blocking communication between your computer and the domain controller. Could be a firewall, a misconfigured router, or even a network cable issue.
Step 1: Verify the domain controller is reachable
- Open Command Prompt and ping the domain controller's IP address:
(use the actual IP from your nslookup).ping 192.168.1.10 - If ping times out, there's a network break. Check physical cables, Wi-Fi signal, or VLAN settings.
- If ping works, test the required ports:
(389 is LDAP). If telnet fails, a firewall is blocking port 389.telnet 192.168.1.10 389
Note: Telnet isn't enabled by default in Windows 10/11. You can enable it via Turn Windows features on or off, or use Test-NetConnection in PowerShell:
Test-NetConnection 192.168.1.10 -Port 389
Step 2: Check Windows Firewall on the client
- Open Windows Defender Firewall with Advanced Security (type
wf.mscin Run). - Go to Inbound Rules and look for any rules that might block File and Printer Sharing or Network Discovery. These are required for domain operations.
- Make sure these rules are enabled:
- File and Printer Sharing (NB-Session-In)
- File and Printer Sharing (SMB-In)
- Network Discovery (LLMNR-UDP-In)
Step 3: Check the domain controller's firewall
This requires access to the server. The DC needs to allow inbound connections on ports:
| Port | Protocol | Service |
|---|---|---|
| 389 | TCP/UDP | LDAP |
| 636 | TCP | LDAPS |
| 445 | TCP | SMB |
| 135 | TCP | RPC |
| 53 | TCP/UDP | DNS |
If you don't have access to the DC, you'll need to coordinate with whoever does. Tell them to check Windows Firewall rules for Active Directory Domain Controller or Domain Controllers profile.
Step 4: When nothing else works—manual SRV record entry
If the DNS server is correct but the SRV records are missing (maybe a previous admin deleted them), you can manually add a Hosts file entry as a temporary workaround. This won't fix the root cause but will get you logged in.
- Open Notepad as administrator.
- Browse to
C:\Windows\System32\drivers\etc\hostsand open the file. - Add a line like:
(replace with your DC's IP and FQDN).192.168.1.10 dc01.contoso.com - Save the file. Then flush DNS again:
ipconfig /flushdns - Try the domain join again. It will use the Hosts entry to find the DC.
This is a band-aid. Once you're in, you should fix the SRV records on your DNS server using the DNS Manager console—right-click the domain zone, choose Other New Records, and add the Service Location (SRV) record pointing to your DC.
One last thought
I've seen this error pop up after a Windows update changed the network profile from Domain to Public. That can block discovery. Check your network profile in Settings > Network & Internet > Status. If it's Public, switch it to Private or Domain.
If you've gone through all these steps and still get 0X0000054B, you might be dealing with a deeper issue like a corrupted domain trust relationship. In that case, you'll need to remove the computer from the domain and rejoin it—but that's a different article.
Was this solution helpful?