When your browser says “DNS server not responding” or “your DNS server might be unavailable”, it means your device sent a query to its configured DNS server and got no response. Without a DNS response, your device cannot resolve the domain name to an IP address. Without an IP address, the browser cannot connect to anything.
The website you are trying to reach is almost certainly fine. The problem is between your device and the DNS server it is trying to use.
What DNS actually does
Every domain name on the internet is an alias for an IP address. When you type a domain into your browser, your device does not know where to connect until it resolves that name to an IP. That resolution happens through DNS – the Domain Name System.
The process works like this:
- You type a domain into your browser
- Your device sends a query to its configured DNS resolver asking for the IP address
- The resolver looks up the answer (either from cache or by querying authoritative nameservers)
- Your device gets back an IP address
- Your browser opens a connection to that IP
This entire process takes milliseconds under normal conditions. It happens before anything else – before SSL negotiates, before the server receives a request, before any content loads.
Your device does not pick a DNS server at random. It uses whatever is configured in your network settings, which is typically assigned automatically by your router via DHCP. Your router in turn usually forwards DNS queries to your ISP’s DNS servers unless you have configured otherwise.
When that chain breaks at any point, DNS fails and everything looks offline even though the internet and the websites themselves are fine.
What TTL means and why it matters
Every DNS record has a TTL – Time to Live. This is a value in seconds that tells resolvers how long they are allowed to cache the record before fetching a fresh copy. A record with a TTL of 3600 can be cached for one hour. A record with a TTL of 300 expires in five minutes.
TTL affects how quickly DNS changes propagate. When a website changes its IP address (migrating to a new server, for example), the old IP stays cached on resolvers around the world until their cached copies expire. During this window, some visitors hit the old server and some hit the new one – this is what people mean by “DNS propagation.”
If you are troubleshooting a DNS issue and recently made a DNS change, propagation time is often the explanation. The record changed, but your resolver is still serving the old cached value. There is nothing wrong with your configuration – you just need to wait for the TTL to expire.
Flushing your local DNS cache forces your device to fetch a fresh copy immediately rather than waiting for the TTL. It does not affect what other resolvers around the world have cached.
Common causes
ISP DNS outage
The most common cause, and one you cannot fix on your end. Your ISP’s DNS servers are having problems. Since most devices default to using ISP-provided DNS, an outage at the ISP affects all DNS resolution for everyone on that network.
A telltale sign: the problem affects all websites simultaneously, apps that are already connected continue working (they do not need DNS for existing connections), and the problem resolves on its own after some time. Switching to a public DNS server bypasses the ISP’s servers entirely and usually resolves this immediately.
Router DNS cache corruption
Your router maintains its own DNS cache and often acts as a local DNS relay – your devices send queries to the router, and the router forwards them upstream. If the router’s DNS process stalls or its cache becomes corrupted, DNS queries stop getting answered.
Restarting the router clears its internal state and resets the DNS process. This is effective more often than people expect.
Stale or corrupted local DNS cache
Your operating system caches DNS responses to avoid repeating the same lookups. Under normal circumstances this speeds things up considerably. Occasionally a cached entry becomes corrupted or an entry for a recently migrated site points to an IP that no longer hosts it.
Flushing the local cache forces a fresh lookup. Unlike a router restart this is instant and non-disruptive.
Firewall or security software blocking DNS
Some firewalls, security suites, and network monitoring tools inspect or filter DNS traffic. DNS uses UDP port 53 by default. If a rule is blocking outbound traffic on this port, no DNS queries reach the server.
This is more common after installing new security software or on corporate networks with strict egress filtering. Temporarily disabling the firewall to test is a quick way to confirm.
VPN changing DNS configuration
VPNs typically route DNS queries through their own servers to prevent DNS leaks revealing which sites you visit. If the VPN’s DNS server is slow, unreachable, or misconfigured, DNS failures follow. The problem disappears when you disconnect from the VPN.
Some VPNs also modify your DNS settings in a way that persists after disconnection if not properly cleaned up. If you recently used a VPN and are still seeing DNS failures with it disconnected, check your DNS configuration manually.
Manually configured DNS server is unreachable
If your device has a manually configured DNS server – perhaps set up by an IT department, left over from a previous network, or configured by a now-disconnected VPN – and that server is no longer reachable, DNS will fail. Setting DNS back to automatic (DHCP-assigned) or switching to a public server fixes this.
The domain itself has a DNS problem
If DNS works for every site except one specific domain, the problem is not your DNS server – it is the domain’s DNS configuration. Common causes include expired domain registration, deleted DNS records, misconfigured nameservers, or a nameserver that is down.
This is not something you can fix on your end, but you can confirm it is the cause by checking the domain’s DNS records from a neutral location. SiteProbe’s DNS lookup tool queries authoritative nameservers directly and shows you exactly what records exist (or do not exist) for any domain.
How to diagnose the problem
Test by querying a public DNS server directly
This is the most useful first test. Instead of using your configured DNS server, query a public one directly:
Windows:
nslookup google.com 1.1.1.1
Mac/Linux:
dig google.com @1.1.1.1
This bypasses your configured DNS server completely and queries Cloudflare’s public DNS at 1.1.1.1. If you get a valid IP address back, your internet connection is fine and the problem is specifically with your configured DNS server. If this also fails, the problem is your network connection, not DNS.
Check what DNS server your device is using
Windows:
ipconfig /all
Look for “DNS Servers” under your active adapter.
Mac:
scutil --dns | head -20
Linux:
cat /etc/resolv.conf
If the listed server is a private IP like 192.168.1.1, your device is using the router as its DNS server. If the router’s DNS process is broken, that is your problem.
Test basic connectivity independent of DNS
ping 1.1.1.1
If this works, you have internet connectivity but DNS is the problem. If it fails, your network connection itself is broken – DNS is downstream of that.
Check the specific domain’s DNS records
If the problem is domain-specific, look up the domain’s DNS records directly. tools.hostney.com/dns lets you query any domain’s A, AAAA, MX, TXT, CNAME, NS, and SOA records. If the domain has no A record or its nameservers are not responding, the issue is on the domain owner’s side and nothing you do locally will fix it.
This is particularly useful when you have recently migrated a site and are waiting for DNS propagation – you can see exactly what IP the DNS records point to, confirm the new records are in place, and verify that your local resolver has picked up the change.
How to fix it
Switch to a public DNS server
This resolves the majority of DNS failures caused by ISP outages, slow resolvers, or misconfigured router DNS. Switching to a public DNS server also tends to be a permanent improvement – Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8 are faster and more reliable than most ISP-provided DNS servers.
Recommended public DNS servers:
| Provider | Primary | Secondary |
|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 |
| 8.8.8.8 | 8.8.4.4 |
Windows:
- Open Settings > Network & Internet > your active connection > Hardware properties
- Click Edit next to DNS server assignment
- Switch to Manual, enable IPv4
- Enter primary and secondary addresses
- Save
Mac:
- Open System Settings > Network > your connection > Details
- Go to the DNS tab
- Remove existing entries, add the new addresses
- Click OK
Linux (systemd-resolved):
sudo nano /etc/systemd/resolved.conf
Under the
[Resolve]
section set:
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4
Then restart the service:
sudo systemctl restart systemd-resolved
Flush your local DNS cache
Forces your device to discard cached entries and perform fresh lookups. Does not affect other resolvers on the network.
Windows:
ipconfig /flushdns
Mac:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux (systemd-resolved):
sudo resolvectl flush-caches
Linux (nscd):
sudo systemctl restart nscd
After flushing, retry the failing domain. If a stale cache entry was the problem, it resolves immediately.
Restart your router
Unplug for 30 seconds, plug back in, wait for it to fully restart. This clears the router’s DNS cache and resets its DNS relay process. Effective for problems caused by router DNS process stalls or corrupted router cache.
Check your firewall
If you recently installed security software, temporarily disable it and test DNS. If DNS works with it disabled, the software is blocking UDP port 53. Add an exception for outbound DNS traffic or configure the software to use its own DNS rather than blocking system DNS.
Disconnect your VPN
Test DNS with the VPN disconnected. If DNS works without it, the issue is the VPN’s DNS configuration. Most VPN clients have settings to control which DNS server is used – switch to your system DNS or a public server.
If the problem persists after disconnecting the VPN, check whether the VPN modified your DNS settings and did not restore them on disconnect. Review your network adapter’s DNS configuration and set it back to automatic.
DNS and hosting migrations
DNS failures during or after site migrations are a specific and common scenario worth understanding separately.
When you migrate a WordPress site to a new host, one of the final steps is updating the domain’s DNS A record to point to the new server’s IP address. The old IP stays cached across DNS resolvers worldwide until the record’s TTL expires. During this propagation window:
- Some visitors hit the old server (seeing the old cached IP)
- Some visitors hit the new server (seeing the updated record)
- Your own device may hit either, depending on what your resolver has cached
This is not a DNS failure. It is the system working as designed. Propagation usually completes within a few hours for most resolvers, though it can take up to 48 hours in worst-case scenarios with long TTLs.
To minimize propagation time before a planned migration, lower your DNS TTL to 300 seconds (5 minutes) at least 24 hours before the migration. Once all resolvers have refreshed their caches with the low TTL, the actual DNS switch propagates in minutes rather than hours.
To verify what IP a domain resolves to from an authoritative perspective during propagation, use tools.hostney.com/dns. This queries the authoritative nameservers directly and shows you exactly what records are published, independent of what any particular resolver has cached.
When the problem is intermittent
Intermittent DNS failures are harder to diagnose because they are gone by the time you start investigating. Common causes:
- ISP DNS servers that are overloaded during peak hours but functional at other times
- Router DNS cache that accumulates stale entries and needs periodic clearing
- A VPN with an unreliable DNS server in your geographic region
- A DNS record with a very short TTL that briefly goes missing during zone updates
Switching to a public DNS server usually eliminates intermittent failures caused by ISP DNS reliability. If the problem continues after switching, the issue is your network connection rather than the DNS server.
Summary
“DNS server not responding” means your device cannot reach its configured DNS server to resolve domain names. The most effective fix for most people is switching to a public DNS server like Cloudflare (1.1.1.1) or Google (8.8.8.8), which bypasses ISP DNS entirely and tends to be faster and more reliable. Flushing your local DNS cache and restarting your router resolve the remaining common causes. If the problem is domain-specific rather than affecting all sites, use SiteProbe’s DNS lookup tool to check whether the domain itself has a DNS configuration problem – in that case the fix is on the domain owner’s side, not yours.