Site Unreachable but Ping by IP Works: Fixing DNS on Windows

This is one of the most common tickets a helpdesk sees. A user says the site is down. You ping the site's IP address and it answers. You ping the name and it fails, or it resolves to something strange. Nothing is down. Name resolution is broken somewhere between the PC and the internet.

The good news is that DNS problems follow a predictable chain. The PC asks its configured resolver, that resolver asks a forwarder, and the forwarder asks the root servers. Find the first link that gives a wrong answer and you have found the fault.

Confirm it is DNS and not the network

Before you touch any settings, prove the layer. Open a command prompt on the affected PC and run the two checks below. If the IP answers and the name does not, stop chasing the firewall and the ISP. You have a resolution problem.

Ping the site by IP: `ping 1.1.1.1` or the IP of the server the user is trying to reach.
Ping the same site by name: `ping www.example.com`. Note whether it says "could not find host" or resolves to an unexpected address.
Run `nslookup www.example.com` and read the first two lines. They show which server the PC asked. If that server is not the one you expect, that is your first clue.
Run `Test-NetConnection www.example.com -Port 443` in PowerShell. It reports the resolved address and whether the TCP connection succeeded, which separates DNS from a blocked port in one shot.

nslookup www.example.com
ipconfig /all | findstr /i "DNS Servers"
Test-NetConnection www.example.com -Port 443

Fix it on the workstation first

Most single-user DNS tickets are local. A stale cache, a VPN client that left a resolver behind, or a hand-typed DNS server that nobody remembers setting. Clear the easy ones before you escalate.

If the PC is on a domain, the DNS servers should point at your domain controllers and nothing else. Adding a public resolver such as 8.8.8.8 as a secondary looks harmless but causes intermittent failures for internal names, because Windows will happily use the secondary after one slow answer from the primary.

Flush the local cache: `ipconfig /flushdns`. Then repeat the nslookup.
Check for a VPN adapter or a leftover virtual adapter that has its own DNS servers. Disconnect the VPN and test again.
Open the adapter's IPv4 properties and confirm DNS is set to "Obtain automatically" on a DHCP network, or to the correct internal servers on a static one.
Check the hosts file at `C:\Windows\System32\drivers\etc\hosts` for an old override. Malware and old developers both leave entries there.
Run `ipconfig /registerdns` on domain machines so the PC re-registers its own record, then `gpupdate /force` if a policy sets DNS.

ipconfig /flushdns
ipconfig /registerdns
Get-DnsClientServerAddress

When the whole office is affected

If several users open tickets at once, the fault is on the resolver, not the PCs. On a Windows domain that resolver is a domain controller running the DNS role. Log in to it and test from there.

The most common server-side causes are a dead forwarder, a stuck DNS service after a patch, and a firewall rule that quietly blocked outbound port 53 from the server. Work through them in that order because each is a one-minute check.

On the DNS server, run `nslookup www.example.com 127.0.0.1`. If that fails, the server itself cannot resolve.
Open DNS Manager, right-click the server, choose Properties, then the Forwarders tab. Test each forwarder with `nslookup www.example.com <forwarder IP>`. Replace any that time out.
Restart the service: `Restart-Service DNS`. Check Event Viewer under Applications and Services Logs > DNS Server for errors after the restart.
Confirm the firewall allows UDP and TCP 53 outbound from the server. Large responses fall back to TCP, so both are needed.
If forwarders are fine but internal names fail, check Active Directory replication with `repadmin /replsummary`. AD-integrated zones ride on replication.

nslookup www.example.com 127.0.0.1
Restart-Service DNS
repadmin /replsummary

The name resolves but to the wrong place

Sometimes the lookup works and still lands on the wrong host. A site moved to a new IP and your resolver still holds the old record. Or an internal zone shadows a public name, which happens when a company uses its public domain as its Active Directory domain and forgets to create a record for www.

Use `nslookup` against a public resolver to compare answers. If the public answer is different from your internal answer, either wait for the TTL to expire or clear the server cache with `Clear-DnsServerCache` on the DNS server. If the record is missing from an internal zone that shadows the public one, add it by hand and keep a note, because you will need to update it every time the public site moves.

nslookup www.example.com 1.1.1.1
Clear-DnsServerCache -Force

Frequently asked questions

Why does ping by IP work when the name does not?

Ping by IP skips name resolution entirely. If it answers, the route, the firewall and the remote host are fine. Only the lookup step is failing, which points squarely at DNS.

Should I just set every PC to 8.8.8.8?

Not on a domain. Domain-joined machines must use the domain controllers for DNS or they lose the ability to find the domain, apply policy and log on cleanly. Set public resolvers as forwarders on the server instead.

How long does a DNS change take to show up?

As long as the record's TTL, which is often between five minutes and a day. Flushing the client cache and the server cache lets you see the new answer sooner if your resolver has already picked it up.

Takeaway

Treat a "site is down" ticket as a DNS ticket the moment ping by IP works. Prove it with nslookup, fix the PC if one user is affected, and fix the resolver or its forwarders if many are. If the office DNS server has been limping for a while, RackLedge can review the design and put monitoring on it so the next failure pages someone before the users notice.