How to Fix the "DNS Server Not Responding" Error?

Every website is suddenly unreachable, you run Windows Network Diagnostics, and it reports: "Your computer appears to be correctly configured, but the device or resource (DNS server) is not responding." On a Mac or phone you might just see pages failing to load while chat apps that use cached connections keep working. This is a different problem from a site that "doesn't exist" — your device isn't getting a bad answer from DNS, it's getting no answer at all. If you're seeing a specific browser code like DNS_PROBE_FINISHED_NXDOMAIN instead, the guide to that NXDOMAIN error is the better starting point.

This article walks through a methodical way to isolate where the silence is coming from — your device, your router, your ISP's resolver, or something blocking DNS traffic in between — and the fix for each. It also covers the server-side version of the problem, for when the "DNS server" that isn't responding is one you run yourself.

What "Not Responding" Means at the Protocol Level

When an application needs an IP address, your operating system sends a query to the resolver configured for your network connection — usually your router, which forwards it to your ISP's recursive resolver. The query normally travels over UDP port 53. The OS waits briefly for a reply, retries, possibly tries a secondary resolver, and eventually gives up.

"Not responding" means that timeout happened. Nothing came back — not an error code, not a refusal, just silence. That points to one of four places:

1. Your device — wrong DNS server configured, a VPN or security tool intercepting port 53, a broken network stack, or an outdated driver.
2. Your router — its DNS forwarder has crashed or hung, which is extremely common on consumer routers.
3. The upstream resolver — your ISP's DNS service is overloaded or down.
4. The path between — a firewall, captive portal, or network policy is dropping DNS traffic.

The trick is to test each layer separately rather than trying random fixes.

Step 1: Separate DNS Failure from Connectivity Failure

First, confirm that your internet connection works at all, independent of DNS. Ping a well-known IP address — no name lookup required:

ping -c 4 1.1.1.1

ping -n 4 1.1.1.1

If the ping succeeds but websites won't load, you have a pure DNS problem and can carry on. If the ping fails too, the issue is basic connectivity (Wi-Fi, cable, modem, ISP outage), and no DNS fix will help until that's sorted.

Step 2: Find Out Which DNS Server You're Using

You can't fix a resolver until you know which one your device is talking to.

On Windows:

Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object { $_.ServerAddresses }

On macOS:

scutil --dns | grep "nameserver\[[0-9]*\]" | sort -u

On Linux with systemd-resolved:

resolvectl status

The Windows command lists each network adapter with the resolver addresses assigned to it. The macOS command prints the active nameservers from the system's resolver configuration. On Linux, resolvectl status shows the per-link DNS servers; note that /etc/resolv.conf on these systems usually points at 127.0.0.53, a local stub that forwards to the real upstream servers listed by resolvectl.

Typically you'll see your router's address (something like 192.168.1.1), your ISP's resolvers, or a public resolver you configured earlier.

Step 3: Query Each Resolver Directly

Now test whether each layer answers. Query your configured resolver, then a public one, with a short timeout so failures show up fast:

# Your router or configured resolver
dig @192.168.1.1 example.com A +time=2 +tries=1

# A public resolver, bypassing the router's DNS
dig @1.1.1.1 example.com A +time=2 +tries=1

# The same query over TCP, in case UDP is being blocked
dig @1.1.1.1 example.com A +tcp +time=2 +tries=1

On Windows, the equivalent tests are:

Resolve-DnsName example.com -Server 192.168.1.1 -DnsOnly
Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly
Resolve-DnsName example.com -Server 1.1.1.1 -TcpOnly -DnsOnly

# Check that TCP port 53 is reachable at all
Test-NetConnection 1.1.1.1 -Port 53

-DnsOnly stops Windows from falling back to NetBIOS or the hosts file, so you're testing DNS and nothing else. Test-NetConnection only tests TCP, but if TCP 53 is open and UDP queries still time out, that's a strong hint something is filtering UDP.

Read the results like this:

Router query	Public resolver (UDP)	Public resolver (TCP)	Likely culprit
Times out	Works	Works	Router's DNS forwarder or ISP resolver
Times out	Times out	Works	UDP port 53 blocked by firewall, VPN, or network
Times out	Times out	Times out	All DNS blocked, or device network stack broken
Works	Works	Works	Problem is in an app, browser, or local cache

For a deeper look at why DNS normally uses UDP and when it falls back to TCP, see why DNS uses port 53.

Step 4: Apply the Fix for Your Scenario

If the router or ISP resolver is the problem

This is the most common case by far.

1. Restart the router and modem. Power them off for 30 seconds, then turn the modem on first and the router after it's online. Consumer routers' built-in DNS forwarders frequently hang after long uptime, and a restart clears them.
2. Switch to a public resolver. If restarting doesn't help, or the problem keeps returning, configure Cloudflare (1.1.1.1 / 1.0.0.1), Google (8.8.8.8 / 8.8.4.4), or Quad9 (9.9.9.9 / 149.112.112.112). Doing it on the router fixes every device at once — see how to change DNS servers on your router. If you're wondering whether to switch permanently, the post on whether your ISP's DNS server is slowing you down is worth a read.

To change it on a single device from the command line:

# Windows: set public resolvers on the Wi-Fi adapter (run as Administrator)
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

# Revert to whatever DHCP provides
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses

# macOS: set public resolvers on the Wi-Fi service
sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

# Revert to DHCP-provided servers
sudo networksetup -setdnsservers Wi-Fi Empty

Use Get-NetAdapter on Windows or networksetup -listallnetworkservices on macOS if your interface isn't named "Wi-Fi." For phones and tablets, follow the per-device guide for Windows, Mac, iPhone, and Android.

If UDP port 53 is being blocked

When TCP queries work but UDP queries don't, something on the path is dropping DNS packets:

• Third-party firewalls and antivirus suites sometimes include "web protection" that proxies DNS and breaks when it malfunctions. Temporarily disable it and retest.
• VPN clients often redirect all DNS to their own servers. If the VPN tunnel is half-connected, DNS goes nowhere. Disconnect fully, or reinstall the client.
• Corporate and school networks may block outbound DNS except to their own resolvers. Use the resolver the network provides; trying to bypass it usually violates policy.
• Captive portals in hotels and airports intercept DNS until you accept their terms. Open a plain http:// page to trigger the login screen.

If the device's network stack is broken

If nothing works even with public resolvers, reset the local networking components.

On Windows (as Administrator):

ipconfig /flushdns
ipconfig /release
ipconfig /renew
netsh winsock reset
netsh int ip reset
Restart-Service -Name Dnscache -Force -ErrorAction SilentlyContinue

These commands clear the resolver cache, request a fresh DHCP lease (including DNS server assignments), and reset Winsock and the TCP/IP stack to defaults. Reboot after running them. The Dnscache service restart may be refused on newer Windows builds, where it's protected — that's harmless, which is why errors are suppressed.

On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux:

sudo systemctl restart systemd-resolved
sudo resolvectl flush-caches

Cache flushing on every platform is covered in detail in how to flush the DNS cache.

Two more device-level checks are worth doing:

1. Update the network adapter driver. Outdated Wi-Fi and Ethernet drivers on Windows are a well-known cause of intermittent DNS timeouts. Get the latest driver from the laptop or adapter manufacturer.
2. Try another adapter. If Wi-Fi fails but Ethernet works (or vice versa), the problem is specific to that adapter's configuration or driver.

Step 5: Watch for Intermittent Timeouts

Sometimes DNS works most of the time but times out often enough to make browsing feel broken. A quick loop shows whether the failures are random or constant:

for i in $(seq 1 20); do
  printf "%2d: " "$i"
  dig @192.168.1.1 example.com A +time=2 +tries=1 +noall +stats | grep "Query time" || echo "timeout"
  sleep 1
done

The loop sends 20 queries one second apart and prints each response time, or "timeout" if no answer arrived. A handful of timeouts alongside normal 10–40 ms responses points to an overloaded router or a flaky Wi-Fi link; consistently high times (hundreds of milliseconds) suggest a slow upstream resolver. Run the same loop against 1.1.1.1 to compare.

When the DNS Server That Isn't Responding Is Yours

If you run your own resolver — BIND, Unbound, dnsmasq, Pi-hole, or a Windows DNS Server — "not responding" errors from clients usually come from one of these:

• The service isn't running. Check with systemctl status named (or unbound, dnsmasq, pihole-FTL).

• It isn't listening on the right interface. Confirm it's bound to port 53 on the address clients use:

sudo ss -tulpn | grep ':53 '

• Another process grabbed port 53. On Ubuntu, systemd-resolved's stub listener on 127.0.0.53 can conflict with a resolver you install. Set DNSStubListener=no in /etc/systemd/resolved.conf and restart systemd-resolved if you need the port.
• A firewall blocks it. Allow both UDP and TCP 53 from your client networks:

# ufw example: allow DNS from the LAN only
sudo ufw allow from 192.168.1.0/24 to any port 53 proto udp
sudo ufw allow from 192.168.1.0/24 to any port 53 proto tcp

• Access control drops the query. BIND silently ignores or refuses clients outside allow-query and allow-recursion; Unbound's access-control defaults to refusing everything but localhost. Make sure your client subnets are listed.

Check the server's logs (journalctl -u named -f) while a client queries — a query that never shows up in the log is being blocked before it reaches the daemon.

Preventing It from Happening Again

• Configure two resolvers from different providers on the router (for example, Cloudflare primary and Quad9 secondary) so one provider's outage doesn't take you offline.
• Keep router firmware updated — DNS forwarder bugs are a frequent firmware fix.
• Reboot consumer routers occasionally, or schedule it if the router supports that.
• For your own servers, monitor resolution from outside so you hear about a stopped DNS service before your users do.

---

DNS Server Not Responding FAQ

Conclusion

"DNS server not responding" is a timeout, not a verdict about any particular website, and that makes it very fixable once you stop guessing. Confirm raw connectivity with a ping to an IP address, find out which resolver your device uses, and query it and a public resolver directly over UDP and TCP. The pattern of what answers and what doesn't tells you whether the router, the ISP, a filter on the path, or your own device is at fault.

For most home users the answer is a router restart or a switch to a reliable public resolver, set on the router so every device benefits. When that isn't enough, resetting the device's network stack, updating drivers, and checking VPN and security software cover nearly everything else. And if the unresponsive server is one you operate, the service status, listening sockets, firewall rules, and access-control lists are the four places to look.

These references go deeper on resolver behavior and the tools used above:

1. Microsoft Learn: Resolve-DnsName — reference for the PowerShell DNS query cmdlet and its switches.
2. Microsoft Learn: Set-DnsClientServerAddress — reference for setting and resetting DNS servers on Windows adapters.
3. RFC 1035: Domain Names - Implementation and Specification — the core DNS specification, including UDP and TCP transport on port 53.
4. Cloudflare: 1.1.1.1 documentation — setup instructions for Cloudflare's public resolver on routers and devices.
5. Google Public DNS: Get started — configuration steps for Google's public resolvers on each platform.