DNS server not responding: what it actually means and how to fix it

All four of those messages mean the same thing underneath: your device asked "what is the IP address for this name" and did not get a usable answer back. Everything else about your connection can be perfectly fine. The cable is plugged in, the Wi-Fi is strong, packets are flowing. You just cannot turn a name into a number, and since almost nothing on the internet is reached by raw IP any more, the whole thing looks like an outage.

DNS problems are worth understanding properly because they masquerade as so many other things. "The internet is slow." "This one site is down." "Email stopped working." "The app says no connection." All of those can be DNS, and all of them get misdiagnosed for hours by people restarting routers.

What actually happens when you type a name

The chain is longer than most people expect, and any link in it can break independently.

1. Your device checks its own cache. Recently visited names may never leave the machine.
2. It sends a query to the resolver it was handed by DHCP. On a home network that is almost always the router's own address.
3. The router forwards the query to your ISP's resolver, or to whatever resolver it was configured with.
4. That resolver, if it does not already know the answer, walks the hierarchy: root servers, then the top level domain servers for .com or .app, then the authoritative nameservers for the domain itself.
5. The authoritative server returns the record, which gets cached at every step on the way back with a lifetime set by the record's TTL.

Five hops, at least three caches, two or more organisations. "DNS is broken" could mean any one of them.

Which error are you getting?

The exact wording narrows things down a lot, so it is worth reading instead of skimming.

Message	What it means
NXDOMAIN (DNS_PROBE_FINISHED_NXDOMAIN)	A resolver answered, and the answer was "this name does not exist." Usually a typo, an expired domain, a record that was deleted, or a name that only exists on an internal network you are not currently on.
SERVFAIL	A resolver tried and failed. Often a DNSSEC validation failure, or the authoritative nameservers are unreachable or misconfigured.
Timeout / "DNS server isn't responding"	No answer came back at all. The resolver you are pointed at is down, unreachable, or being blocked. This is the most common home network case.
REFUSED	The server you asked is working but will not answer queries from you. Common when a device is pointed at a resolver that only serves a different network.
Resolves, but to the wrong address	Stale cache, a hosts file entry, a split horizon setup, or DNS hijacking by a network you do not control.

The one test that splits the problem in half

Here is the trick that saves the most time: resolve the same name twice, against two different resolvers. Once with whatever your network gave you, and once explicitly against a public one like 1.1.1.1 or 8.8.8.8.

The DNS Lookup tool has a custom server field for exactly this. Two lookups, ten seconds, and the answer is immediately obvious:

Default resolver	1.1.1.1	Verdict
Fails	Works	Your resolver is the problem. Router DNS forwarder stuck, ISP resolver down, or a filtering service blocking it. Change DNS and move on.
Fails	Fails	The domain is the problem, or nothing is getting out of your network at all. Check that you can ping 1.1.1.1 first.
Works	Works	DNS is fine. Your problem is somewhere else: routing, TLS, the server itself.
Different answers	Different answers	Something is intercepting or rewriting your DNS, or you are looking at a record mid propagation.

Two lookups. That single comparison eliminates half the possible causes before you touch a single setting.

# Same name, two resolvers
https://netdebug.app/open/dns?target=example.com
https://netdebug.app/open/dns?target=example.com&server=1.1.1.1

If it is your side

The router's DNS forwarder has wedged

This is the single most common cause on home networks and it is maddening because nothing looks wrong. Consumer routers run a small forwarding resolver, and after weeks of uptime it can stop answering while continuing to route traffic normally. Everything else works. Names stop resolving.

The fix is a router reboot, and the long term fix is to stop depending on it: set your router's DHCP to hand out 1.1.1.1 and 1.0.0.1, or 8.8.8.8 and 8.8.4.4, directly to clients.

Your ISP's resolver is having a bad day

ISP resolvers go down more often than people realise, and the failures are frequently partial: some names resolve, some do not, some take four seconds. If your router forwards to the ISP, you inherit all of that. The two resolver comparison above catches it immediately.

A VPN, profile or filtering app is intercepting queries

Anything that installs a DNS proxy (a VPN, a content filter, a parental control app, an ad blocker that works at the DNS layer) becomes a new single point of failure. A VPN that disconnected badly and left its resolver configured behind is a classic. If the problem follows your device to a different network, this is almost certainly it.

DNS over HTTPS is quietly doing something else

Modern browsers and iOS can use encrypted DNS that bypasses the resolver your network handed out. That means the browser and the rest of the system can disagree about whether DNS works. If one app resolves a name and another does not, check for encrypted DNS settings before blaming the network.

Stale cache after a change

If the site moved recently and you are still hitting the old address, you are looking at a cached record. Check the TTL in the DNS Record Explorer: it tells you exactly how many seconds that answer is allowed to live. A 3600 second TTL means an hour of patience in the worst case.

If it is the domain's side

When a public resolver also fails, the problem is not yours to fix, but it is still worth identifying so you stop trying.

The domain expired

Domains fall off a cliff when they expire: the registry pulls the delegation and every lookup returns NXDOMAIN. A quick Whois lookup shows the expiry date and the registrar. If you own the domain, you now know exactly who to call and what to pay.

The nameservers are wrong or unreachable

Pull the NS records with the DNS Record Explorer and then try resolving the domain directly against one of those nameservers. If the NS records point somewhere that no longer serves the zone (a very common outcome after moving hosts) you get failures that look random because different resolvers have cached different states.

DNSSEC is misconfigured

When a zone's DNSSEC signatures are stale or the delegation is broken, validating resolvers return SERVFAIL while non validating resolvers answer normally. If 8.8.8.8 fails but a different resolver succeeds, suspect DNSSEC. It tends to break at exactly 2am on the day a key rolls over.

The record was never created

New subdomain, new service, someone forgot the record or created it on the wrong zone. The Record Explorer showing nothing for a name that should exist is a much faster answer than clicking through a hosting control panel.

A checklist you can actually follow

1. Confirm the network works at all

   Ping 1.1.1.1. If that fails, stop. You do not have a DNS problem, you have a connectivity problem.

2. Resolve the name against your default resolver

   Note the exact failure: timeout, NXDOMAIN, SERVFAIL. The wording matters.

3. Resolve it again against 1.1.1.1

   Works? The problem is your resolver. Fails the same way? The problem is the domain.

4. Pull the full record set

   A, AAAA, CNAME, NS and TTL. This tells you whether the record exists, where it points and how long the answer sticks around.

5. Check the domain itself if everything upstream is clean

   Whois for expiry and registrar, NS records for delegation. Two lookups, and you know whether to wait, call someone, or fix your own settings.

Save that sequence as an automation and it becomes a single tap the next time someone tells you a site is down. Every run gets timestamped in Run History, which is surprisingly useful when a problem is intermittent and you need to prove it happened.

The short version

DNS failures are not one problem, they are five. Read the exact error, then resolve the same name against two different resolvers. That single comparison tells you whether to change a setting on your own network or go looking at the domain. Everything after that is just following the trail.