How to fix DNS server not responding

What the error means

Every connection starts with a lookup. Your device sends the hostname to a resolver, usually your router, your ISP, or a public service such as 1.1.1.1, and waits for an IP address. If no answer arrives within the timeout, the operating system retries, tries the secondary server, and eventually gives up. Windows then runs its troubleshooter, which reports that the DNS server is not responding.

The wording points at the server, but it is really a statement about a path. Any of these produces the same message: the resolver is down, the resolver is up but unreachable from your network, a firewall drops port 53, the address configured on your adapter is wrong, or the router in the middle stopped forwarding. Silence looks identical in all five cases.

Distinguish it from its neighbors before you start. A resolver that answers "no such name" gives you NXDOMAIN, covered in DNS_PROBE_FINISHED_NXDOMAIN. A resolver that answers slowly but correctly is a different problem again, and it has its own section below. This error is the case where nothing comes back.

Why it happens

• The router stopped forwarding. Consumer routers run a small DNS forwarder that jams more often than the rest of the device, so the network looks online and only name lookups fail.
• The configured DNS server is wrong. A static address left over from an old network, or a server that has been decommissioned.
• The ISP resolver is having an outage or is overloaded and dropping queries rather than answering them.
• A firewall or security suite blocks port 53. Some products intercept DNS themselves and fail closed when their own service is not running.
• A VPN is half connected. The tunnel pushed its internal resolvers onto your adapter, then dropped, leaving addresses that are only reachable inside the tunnel.
• IPv6 is configured but not usable. The system prefers an IPv6 resolver, gets no route to it, and waits out the timeout before falling back.
• The Windows DNS Client service is stopped or its cache is corrupt.
• Malware or an unwanted app changed the resolver to an address it controls, which then goes away.
• The network requires a captive portal login that has not happened yet, so all outbound DNS is swallowed.

How to fix it

Work out whether the network itself is up before touching DNS settings. ping 1.1.1.1 uses no name resolution at all. If that fails too, you have a connectivity problem, not a DNS problem. If it succeeds while ping example.com fails, DNS is confirmed as the broken piece and the steps below apply.

Windows

1. Flush the cache and restart the client service:

   ipconfig /flushdns
   net stop dnscache
   net start dnscache

2. See what your adapter is using: ipconfig /all | findstr /C:"DNS Servers"
3. Set a public resolver instead: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
4. Test that specific server directly: nslookup example.com 1.1.1.1
5. Reset the stack if nothing sticks, then reboot:

   netsh int ip reset
   netsh winsock reset

6. Uncheck IPv6 on the adapter if the machine has no working IPv6, then retest.

macOS

1. Flush the cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Read the resolvers in use: scutil --dns | grep nameserver
3. Replace them: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Return to whatever DHCP hands out: sudo networksetup -setdnsservers Wi-Fi empty

Linux

1. Check status and flush: resolvectl status, then sudo resolvectl flush-caches
2. Query one server explicitly to see whether it answers at all: dig @1.1.1.1 example.com +short
3. Change the resolver on the connection rather than editing /etc/resolv.conf, which is usually generated:

   nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
   nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
   nmcli con up "Wired connection 1"

4. Restart the stub resolver if it is wedged: sudo systemctl restart systemd-resolved

Router

1. Power cycle it and wait for the WAN link to come back before testing.
2. In the admin page, set the WAN DNS servers to a public pair instead of "obtain automatically" if the ISP resolver is the suspect.
3. Update the firmware. DNS forwarder bugs are a common reason a router needs restarting every few weeks.
4. Bypass it as a test: connect a phone to mobile data and resolve the same name. Success there narrows the fault to your network.

Browser

1. Chrome, Edge and Firefox can send DNS over HTTPS to a provider of their own, independent of your system settings. If the browser fails while dig succeeds, turn secure DNS off in the browser's privacy settings and retest.
2. Clear Chrome's internal cache at chrome://net-internals/#dns.

When the lookup is slow rather than broken

Not every DNS complaint is a failure. If pages eventually load but stall for a second or two before anything happens, the resolver is answering, just late, and the fixes above will not change much. Measure it before you guess:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"

Anything in single or low double digit milliseconds from a warm cache is normal. Several hundred milliseconds, or a figure that changes wildly between runs, means the resolver is far away, overloaded, or timing out on its first server and falling back to a second. That is a different diagnosis with different fixes, set out in how to fix a slow DNS lookup.

Check it from outside

Everything so far assumes the fault is near you, which it usually is. Confirm that before spending an afternoon on it. Ask a resolver that has nothing to do with your network whether the name resolves:

dig @8.8.8.8 example.com +short
dig @9.9.9.9 example.com +short
nslookup example.com 1.1.1.1

An answer from those while your own resolver stays silent proves the domain is fine and the problem is your side. Silence from all of them shifts attention to the domain's own nameservers, which may be down or unreachable from part of the internet.

Reachability of a nameserver is not global. Run the DNS query check to send the same lookup from checkpoints in different countries and compare the answers side by side. When some locations get a result and others time out, you are looking at a routing or provider problem affecting a region, not a broken record, and no amount of flushing on your laptop will show you that.

When your own nameserver goes quiet

A nameserver that goes quiet takes a site down as completely as a dead web server, and it does it without producing a single line in your access log. Nobody reaches you to say so, because they cannot reach you at all. HostTracker runs scheduled checks from 300+ checkpoints in 158 cities across 13 monitor types, so a name that stops resolving in one region is caught by the checkpoints there rather than by a customer email. The rest of this section is in the fix cluster, and if the question is whether a recent DNS change has reached everyone yet, that is how to check DNS propagation.