Fix DNS Server Not Responding (All Devices)

What "DNS Server Not Responding" Actually Means

Every time you visit a domain, your device's stub resolver sends a UDP query to a DNS server asking for its IP address. Per RFC 1035 §7.2, a resolver that gets no answer retransmits the query a limited number of times against a per-request counter, then reports a temporary error once that counter hits zero — that temporary error is what surfaces as "DNS server not responding."

This is distinct from NXDOMAIN (the domain doesn't exist) or SERVFAIL (the server replied but refused to answer). Those are responses. "Not responding" means no response arrived at all — the packet was lost, the server is down, or something between you and it dropped the query.

The exact wording differs by platform:

• Windows Network Diagnostics: "DNS server isn't responding"
• Chrome / Edge: page hangs, then often falls back to DNS_PROBE_FINISHED_NXDOMAIN once the browser gives up and treats the silence as a failed lookup
• macOS Safari: "Safari Can't Find the Server"
• Android: "Server DNS Address Could Not Be Found" or "Web page not available"

Root Causes, Ranked

Ranked by how often each one is the actual cause, based on Microsoft's client resolution-timeout documentation and RFC 1536's list of common resolver implementation failures:

1. Your configured DNS resolver is unreachable. This is almost always the ISP's default resolver having an outage, being rate-limited, or being unreachable from your current network (common on public Wi-Fi that blocks external DNS).
2. Router DNS relay/forwarding is stuck. Home routers often act as a DNS relay, forwarding client queries to the ISP resolver. If the router's own cache or forwarding process hangs, every device behind it fails simultaneously — a strong diagnostic signal.
3. Local negative cache poisoning. Per RFC 1536 §4, a resolver that caches a failed lookup will keep returning that failure until the cache entry expires or is flushed, even after the server recovers.
4. Firewall or security software blocking port 53/853. Antivirus suites and corporate firewalls sometimes intercept or drop outbound DNS traffic, especially DNS-over-TLS (port 853).
5. Stale or incorrect DNS server IP in network settings. A manually set resolver address that's now decommissioned or typo'd will never respond.
6. VPN split-tunnel or proxy misconfiguration. Some VPN clients route DNS queries to an internal resolver that's unreachable once the tunnel drops.
7. Outdated or corrupted network adapter driver. Rare, but a known cause on Windows after a driver update.

Diagnose Before You Fix

Before changing settings, confirm the DNS layer — not your internet connection — is the actual failure point.

# Test if DNS resolution works against a known-good public resolver
nslookup google.com 1.1.1.1

If this succeeds but a plain nslookup google.com (using your default resolver) fails, the problem is your configured resolver — not your internet connection. Cross-check with the DNS Lookup tool to confirm the domain resolves correctly from outside your network, and use the NS Lookup tool to verify the domain's authoritative nameservers are actually reachable. If the domain resolves fine everywhere except your device, the fault is local (cache, adapter, firewall) — not the domain's DNS.

Fix It: Windows

# 1. Flush the local resolver cache
ipconfig /flushdns

# 2. Release and renew the DHCP lease (also refreshes DNS if assigned via DHCP)
ipconfig /release
ipconfig /renew

# 3. Reset Winsock (fixes corrupted network stack entries)
netsh winsock reset

# 4. Reset the TCP/IP stack
netsh int ip reset

Restart after step 4. If the error persists, set a public DNS server manually: Control Panel → Network and Sharing Center → Change adapter settings → right-click the active adapter → Properties → Internet Protocol Version 4 (TCP/IPv4) → Use the following DNS server addresses → 1.1.1.1 (preferred) and 8.8.8.8 (alternate).

Fix It: macOS

# Flush the DNS cache and restart the mDNSResponder daemon
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

If that doesn't resolve it, set DNS manually: System Settings → Network → [active connection] → Details → DNS → add 1.1.1.1 and 8.8.8.8, remove any stale entries, then toggle Wi-Fi off and on.

Fix It: Linux

Most modern distributions run systemd-resolved as the local stub resolver:

# Flush the systemd-resolved cache
sudo resolvectl flush-caches

# Check which resolver is actually configured
resolvectl status

# Restart the resolver service if it's hung
sudo systemctl restart systemd-resolved

If NetworkManager manages the connection, DNS servers can be set per-connection with nmcli con mod <connection-name> ipv4.dns "1.1.1.1 8.8.8.8" followed by nmcli con up <connection-name>.

Fix It: Router

Because a router's DNS relay serves every connected device, this is worth checking first if the error affects multiple devices at once:

1. Power-cycle the router and modem. Unplug both, wait 30 seconds, plug the modem in first, wait for sync, then the router. This clears the router's own DNS cache and forces a fresh handshake with the ISP.
2. Log into the router admin panel (commonly 192.168.1.1 or 192.168.0.1) and check the WAN/DNS settings — confirm it isn't pointed at a dead custom resolver IP.
3. Set the router's DNS servers explicitly to 1.1.1.1 / 8.8.8.8 instead of "obtain automatically from ISP," so every device behind it gets a working resolver by default.

Fix It: Android

1. Settings → Network & Internet → Private DNS → set to Private DNS provider hostname → enter dns.google or one.one.one.one.
2. If already set, switch to Automatic and back to force a re-handshake.
3. As a fallback: forget the Wi-Fi network, then reconnect and re-enter the password — this clears the device's cached network config for that SSID.

Fix It: iOS

1. Settings → Wi-Fi → tap the ⓘ next to the connected network → Configure DNS → Manual → remove existing entries → add 1.1.1.1 and 8.8.8.8.
2. If the error persists: Settings → General → Transfer or Reset iPhone → Reset → Reset Network Settings (this also clears saved Wi-Fi passwords, so have them ready).

Verify the Fix

After applying a fix, confirm resolution actually works before assuming it's solved:

# Should return an IP address with no timeout
nslookup thednsnexus.com

Then cross-check with the DNS Propagation Checker to confirm the domain resolves consistently from multiple global resolvers, not just your local one. If you manage the domain yourself and suspect an authoritative-side issue rather than a client-side one, the Reverse DNS Lookup tool can confirm your server's PTR record is correctly configured.

Key Takeaways

• ✓ "DNS server not responding" means the query got no reply at all — not NXDOMAIN, not SERVFAIL, per RFC 1035 §7.2.
• ✓ The fastest fix in most cases: flush the local cache, then switch to 1.1.1.1 or 8.8.8.8.
• ✓ If the error hits every device on the network simultaneously, check the router's DNS relay first — not each individual device.
• ✓ A negative cache entry can keep returning failure even after the server recovers, per RFC 1536 §4 — flushing clears it.

Frequently Asked Questions

Next Steps

Run the DNS Propagation Checker to confirm a domain resolves globally once your local fix is in place, or use DNS Lookup to inspect the full record set for any domain. If you're chasing a related caching issue rather than an outright failure, see What Is DNS Cache? and How to Flush DNS Cache (All Platforms). If you changed nameservers recently and suspect that's the root cause, What Are Nameservers? explains how to verify them, and DNS Propagation Still Pending After 24 Hours? covers what to do if resolution stays inconsistent longer than expected.