Fixing DNS Resolution Failures on Windows

DNS resolution failures on Windows — websites failing to load with name-resolution errors while the underlying network connection otherwise looks fine, or resolution working inconsistently across different applications on the same machine — usually trace back to one of a small number of specific, checkable causes, rather than requiring a full network stack reset as a first response.

Confirming this is actually a DNS problem, not a broader connectivity issue

ping 8.8.8.8
ping google.com

If pinging a raw IP address succeeds but pinging a hostname fails, that confirms the problem is specifically DNS resolution rather than a broader connectivity or routing problem — worth confirming explicitly before assuming DNS is the actual cause, since a broader connectivity problem needs an entirely different troubleshooting path.

Checking what DNS servers are actually configured

ipconfig /all

This shows the actual DNS servers configured for each network adapter — worth checking directly rather than assuming, since a VPN connection, a corporate network policy, or a misconfigured static IP setting can silently push DNS server settings you didn’t expect, especially if the machine has recently joined a new network or VPN.

Clearing the DNS client cache

Windows caches resolved DNS lookups locally, and a stale or incorrect cached entry (from a domain that’s since changed its DNS records, or a corrupted cache entry) can cause resolution failures or outdated results that persist even after the underlying DNS records have changed:

ipconfig /flushdns

This is a low-risk, fast first step worth trying before more involved diagnostics, since it directly addresses one of the more common and easily-fixed causes.

Testing resolution against a different DNS server directly

nslookup google.com 1.1.1.1

This explicitly queries a known-reliable public DNS server directly, bypassing whatever DNS server is currently configured on the adapter — if this succeeds while ordinary resolution (using the configured DNS servers) fails, that isolates the problem specifically to the configured DNS server or the path to reach it, rather than a broader Windows-side DNS client problem.

Checking the DNS Client service itself

sc query dnscache

The DNS Client service (internally named Dnscache) handles caching and resolution coordination — confirming it’s actually running, and restarting it if not, addresses cases where the service itself has stopped or become unresponsive:

net stop dnscache
net start dnscache

Checking for a misbehaving VPN or security software DNS hook

VPN clients and some security software install their own DNS filtering or redirection components, which can occasionally conflict with normal resolution — particularly noticeable if DNS problems started specifically after installing a new VPN client or security product, or specifically only occur while that software is active. Testing resolution with the suspected software temporarily disabled isolates whether it’s actually the cause before assuming a deeper system-level DNS problem.

Checking the hosts file for unexpected overrides

notepad %systemroot%\System32\drivers\etc\hosts

The hosts file overrides DNS resolution entirely for any entry it contains, and an unexpected or forgotten entry (added by other software, or by a previous troubleshooting attempt) can cause a specific hostname to resolve incorrectly regardless of what the actual DNS servers would otherwise return — worth checking directly for the specific problem domain, since this override takes priority over DNS resolution entirely and won’t be fixed by any DNS-server-side troubleshooting.

Resetting the Winsock catalog as a broader, more disruptive step

If none of the above resolves the problem, resetting the Windows Sockets (Winsock) catalog addresses corruption in the networking stack’s own configuration that can manifest as DNS or broader connectivity problems:

netsh winsock reset
netsh int ip reset

This requires a restart and is a genuinely more disruptive reset than the steps above (it can affect other networking configuration beyond just DNS), which is why it’s positioned as a later step rather than a first response, reserved for cases where the more targeted diagnostics above haven’t identified and resolved a specific cause.

Why working through this order matters

Confirming the problem is genuinely DNS-specific, then checking configuration and cache state before escalating to a full networking stack reset, resolves the large majority of DNS issues at one of the earlier, less disruptive steps — jumping straight to a Winsock reset or driver reinstall skips past checking for the simpler, far more common causes first.