You're trying to join a Windows 10 or Server 2022 machine to the domain. You get the error DNS_ERROR_DS_UNAVAILABLE (0X000025F5) - The directory service is unavailable. It happens right after you enter domain admin credentials and click OK. The machine sits there for 30 seconds, then throws this error. The culprit here is almost always DNS — the client can't resolve the domain's LDAP SRV records because it's pointing to the wrong DNS server or the DNS server itself isn't responding.
What actually causes this error?
Active Directory Domain Services (AD DS) relies on DNS for service location. When a client joins a domain, it queries DNS for _ldap._tcp.dc._msdcs.<domain> SRV records. If the client's DNS points to a forwarder that can't see the internal AD zone, or to a DNS server that's offline, you get 0X000025F5. Firewalls blocking UDP 53 or TCP 389 can also trigger it. Less common causes: broken NetBIOS over TCP/IP, or the domain controller itself having a corrupted DNS zone.
The fix — step by step
- Check the client's DNS server IP. Run
ipconfig /all. Look at the DNS Servers line for the connected adapter. It should list your domain controller's IP — not a public DNS like 8.8.8.8. If it's wrong, set it statically or fix DHCP. - Test DNS resolution. On the client, run
nslookup <your_domain_name>. If it returns an IP that matches your DC, move on. If it times out or returns a different IP, your DNS is misconfigured. - Verify the SRV record. Run
nslookup -type=srv _ldap._tcp.dc._msdcs.<your_domain_name>. Expect one or more DC IPs. If nothing comes back, the DNS zone is missing the _msdcs subdomain or the DC's Net Logon service isn't registered. - Check firewall ports. From the client, run
Test-NetConnection <DC_IP> -Port 53in PowerShell. Do the same for ports 135, 389, 445, and 464. Any failure means a firewall between client and DC is dropping traffic. - Flush DNS and reset NetBIOS. Run
ipconfig /flushdns, thennbtstat -R. On older Windows 7/Server 2008 R2 machines, broken NetBIOS cache can cause this. Rare but worth trying if you're stuck. - Test from another device. Grab a known good workstation already on the domain. Run the same nslookup commands. If it works, the problem is on the failing client. If not, the issue is on the DNS server side.
Still failing? Check these
| Scenario | What to do |
|---|---|
| Client has correct DNS but can't reach DC | Ping the DC by IP. If it fails, check routing, VLANs, or a hardware firewall. Use tracert <DC_IP> to find where it drops. |
| DNS resolves but SRV records are missing | Log into the DC, open DNS Manager, expand Forward Lookup Zones, find your domain zone. The _msdcs subdomain should exist with _ldap._tcp.dc records. If not, run net stop netlogon && net start netlogon on the DC to re-register. |
| Client is in a different subnet or remote site | Ensure the client's DNS points to a DC that serves that subnet. If you have multiple sites, check site links and subnet definitions in AD Sites and Services. |
| Firewall rules look fine but still blocked | Check for IPsec policies or third-party AV with network filtering. Temporarily disable Windows Firewall on the client (for testing only) and retry the join. |
When you've tried everything
I've seen cases where the domain controller's DNS zone got corrupted after a failed update. Restart the DNS Server service on the DC. If that doesn't help, stop the Net Logon service, delete the _msdcs.<domain> zone from DNS Manager, restart Net Logon, and let it rebuild. Also check that the DC's own DNS server settings point to itself as the primary DNS, not to any external forwarder for internal zones. Last resort: verify time sync between client and DC. Kerberos requires time within 5 minutes — use w32tm /query /status on both sides.
This error is stubborn but it's almost never a deeper AD problem. Nine times out of ten it's a simple DNS mispoint or a firewall rule someone forgot to open. Follow the steps above and you'll have that machine joined in under 10 minutes.