How to Solve DNS Server Not Responding Error in Windows

Windows tells you the DNS server is not responding. In a large proportion of cases, the DNS server is working perfectly — Windows simply could not reach it, which is a different problem requiring different fixes.

This matters because the message sends people in a specific direction. They change DNS servers, try public resolvers, and restart things, while the actual fault sits elsewhere entirely.

Before applying any of the fixes below, it is worth understanding what the DNS server not responding message is really reporting, and how to check in ten seconds whether DNS is genuinely involved.

What the Message Actually Means

This message is produced by the Windows Network Diagnostics troubleshooter. When something fails, the troubleshooter runs a series of tests, and if a name lookup fails it reports that the DNS server is not responding.

What it means precisely is: a query was sent to the configured resolver and no usable answer came back. That single symptom has several possible causes:

• The resolver is genuinely down.
• The resolver is up and unreachable from this machine.
• Something on the machine is intercepting or blocking the query.
• The machine is pointing at the wrong resolver.
• The query reached the resolver and the answer was rejected or discarded.
• The network path is broken entirely, and DNS is simply the first thing that failed.

That last one is the important one. If the connection is down, every diagnostic fails at the first step that needs the network, which is usually name resolution. Windows then reports a DNS problem when the real fault is connectivity.

The Ten-Second Test

Open Command Prompt and run two commands:

ping 1.1.1.1

ping google.com

Interpret as follows:

• Both fail. Not a DNS problem. The machine has no working connectivity at all. Investigate addressing, cabling, and the gateway.
• The IP address responds, the name does not. Genuine DNS problem. Continue with this article.
• Both work. Whatever failed has recovered, or the problem is specific to one application rather than to name resolution generally.

This test costs nothing and prevents the most common wasted effort in this scenario.

Fix One: Clear the Cache and Restart the Service

Start here because it is fast and occasionally sufficient.

Open Command Prompt as administrator and run:

• ipconfig /flushdns
• net stop dnscache
• net start dnscache

The second and third commands restart the DNS Client service. Note that stopping it through the Services console is often blocked on modern Windows; the command line works.

This helps specifically when a failed lookup has been cached — Windows remembers failures as well as successes, so a problem fixed several minutes ago may still be reported as broken until the cache clears.

Fix Two: Check Which Resolvers Are Configured

Run ipconfig /all and find the DNS Servers entry for your active adapter.

What to look for:

• Is anything listed at all? An empty entry means DHCP did not supply resolvers, or a manual configuration was cleared.
• Are the addresses correct for this network?
• Is the primary reachable? Ping it directly.
• Are the primary and secondary genuinely different servers? Listing the same address twice, or two addresses on the same failed device, provides no redundancy whatever.
• Is there an unexpected entry? A leftover from a VPN client or a previous network is a common cause.

To test a specific resolver directly, use nslookup with the server named explicitly:

nslookup google.com 8.8.8.8

If that succeeds while the default fails, you have identified the broken resolver.

Fix Three: The Domain-Joined Warning

If this machine is part of a Windows domain, read this before changing anything.

Do not configure a domain-joined machine to use public DNS servers. Domain members locate domain controllers through SRV records held in internal DNS. A public resolver knows nothing about them, and pointing a domain machine at one breaks authentication, Group Policy, and access to internal resources.

The symptoms this creates do not mention DNS. Users see login failures, unavailable network drives, and policies that stop applying — and the person who changed the DNS setting yesterday has no reason to connect the two.

Domain machines must point at internal DNS servers. Those servers forward external queries onward, which is their job.

Using a public resolver temporarily as a diagnostic test is fine. Leaving it configured is not.

Fix Four: IPv6 Interference

On many networks, IPv6 is partially configured — enough for Windows to prefer it, not enough for it to work properly. Windows prefers IPv6 when it appears available, and if the IPv6 resolver is unreachable, lookups may fail before IPv4 is attempted.

Disabling IPv6 on the adapter frequently resolves this, and it is a reasonable diagnostic step. Open ncpa.cpl, open the adapter's properties, and clear the Internet Protocol Version 6 checkbox.

The honest caveat: this is a workaround, not a fix. The underlying problem is a half-configured IPv6 environment, and disabling it on one machine treats the symptom on one desk. If it resolves the issue, the real action is to either configure IPv6 properly across the network or disable it consistently at the network level.

Fix Five: Security Software and VPN Clients

A substantial share of stubborn DNS problems come from software on the machine rather than from the network.

Candidates:

• Antivirus web protection modules that intercept and filter DNS queries.
• VPN clients that alter DNS configuration and fail to restore it cleanly when disconnected.
• Ad-blocking software operating at the DNS level.
• Third-party firewalls blocking UDP port 53.
• Browser secure DNS. Modern browsers can perform their own encrypted lookups independently of Windows, which produces a confusing split where some applications resolve names and others do not.

The diagnostic: disable them one at a time, testing after each. For a suspected VPN client, note that simply disconnecting is not always enough — the configuration may persist until the service is stopped.

For the browser case specifically, check the security or privacy settings for a secure DNS option and disable it temporarily. If resolution then works normally in the browser, you have found it.

Fix Six: The Router

If several devices on the same network show the problem, the fault is not on any of them.

Most small networks use the router itself as their DNS resolver, forwarding queries to the internet provider. When that forwarding function fails — and it does, quietly — every device on the network loses name resolution while local connectivity continues working perfectly.

Steps:

• Restart the router, which resolves this more often than it should need to.
• Check the router's own DNS settings and whether it can resolve names itself.
• Check whether the provider's resolvers are failing, by configuring a public resolver on the router temporarily.
• Update the router firmware, since DNS forwarding bugs are common in older versions.

Fix Seven: Reset the Network Stack

If the problem is confined to one machine and nothing above has helped, the networking configuration itself may be corrupted. This occurs most often on machines that have had several VPN clients or security products installed and removed.

From an administrator Command Prompt:

• ipconfig /flushdns
• netsh winsock reset
• netsh int ip reset
• ipconfig /release
• ipconfig /renew

Then restart the machine. The middle two commands do not take effect until you do.

Be aware that this resets configuration some applications depend on. A VPN client or proxy tool may need reinstalling afterwards.

Fix Eight: The Adapter Driver

Less common, and worth checking when the problem is persistent and machine-specific.

In Device Manager, look for a warning indicator on the network adapter. Update the driver from the computer manufacturer's support site rather than allowing Windows to search — Windows frequently reports that the best driver is already installed when a newer one exists.

While in the adapter's properties, open the Power Management tab and clear the option permitting the computer to turn the device off. This causes a specific symptom: connectivity that works and then fails after the machine has been idle.

When It Is Not Your Machine at All

Two situations produce this message with nothing wrong locally:

Captive portals. Hotel, café, and airport wireless networks intercept traffic until you authenticate through a web page. Until you do, DNS behaves erratically. If the portal page does not appear automatically, try browsing to a plain HTTP address, which is more likely to trigger the redirect than an HTTPS one.

Provider DNS outages. These happen, they affect everyone in a region simultaneously, and they resolve without your involvement. If several networks show the same behaviour at once, wait rather than reconfigure.

The Ordered Checklist

1. Run the two-ping test to confirm DNS is genuinely involved.
2. Flush the cache and restart the DNS Client service.
3. Check configured resolvers with ipconfig /all and test each with nslookup.
4. Confirm domain membership considerations before changing anything.
5. Test with IPv6 disabled as a diagnostic.
6. Disable security software and VPN clients one at a time.
7. Check whether other devices are affected, which moves the investigation to the router.
8. Reset the network stack and restart.
9. Update the adapter driver and disable its power management.

Work through in order. The temptation is to jump to step eight, and the answer is usually found in the first three — which is the general lesson with the DNS server not responding message: it points at a conclusion rather than a cause, and the cause is usually simpler than the message suggests.