DNS error: what it means and how to find the real cause

What "DNS error" covers

Underneath that one phrase are several distinct failures that share nothing except where they happen. A browser can say the name does not exist at all. It can say the resolver never answered. It can load the page eventually, just slowly, after a visible stall. A whole office can lose the ability to resolve any name while the internet connection itself stays up. Or your own site's records can stop working for visitors in one region while looking completely normal to you. Each of those has a different cause and a different fix, and none of them is solved by the generic advice to "restart your router and try again," which fixes exactly one of the five.

The rest of this page is a short set of questions. Answer them in order and you will land on the specific guide that matches what is happening, instead of working through five unrelated fix lists hoping one of them helps.

Is it just this device, or every device?

Try the same lookup from a phone on mobile data, not your Wi-Fi. If the name resolves there and fails on your laptop, the problem is local: a bad DNS setting on that one machine, a stuck cache, a VPN holding onto resolvers that are no longer reachable, or security software intercepting DNS on its own. If it fails on the phone too, on a completely different network, move on to the next question, because the fault is not on your device or even your local network.

Is it just one site, or is everything broken?

Try resolving a well-known name you are confident works, such as a major search engine. If that also fails, your resolver itself is unreachable or not responding, which is a router or network problem, not something wrong with the one site you were trying to reach. If the well-known name resolves fine and only the site you wanted fails, the problem sits with that one domain: its records, its nameservers, or a change still spreading to some resolvers and not others.

Does a lookup against a public resolver work?

This single test does more triage work than anything else here, because it separates "my network" from "the domain itself" in one command:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Replace example.com with the actual name that is failing. Three outcomes are possible, and each points somewhere different:

• You get a normal answer back. The domain resolves fine from the outside. Your default resolver, whatever your device or router is configured to use, is the broken piece. That is DNS server not responding if it fails silently, or a caching problem if a lookup used to work and stopped.
• You get an explicit "no such name" answer (NXDOMAIN). A public resolver with no reason to have anything cached is telling you the record genuinely does not exist right now, or a stale negative answer is cached somewhere in the chain. That exact message and what to check next is DNS_PROBE_FINISHED_NXDOMAIN.
• You get an answer, but it takes a noticeably long time or the timing is inconsistent between runs. The resolver is working, just slowly. Add +stats to a dig query or watch the delay by eye. That is how to fix a slow DNS lookup, a different cause and a different fix from the two above.

What resolvectl status tells you on Linux

On a Linux machine using systemd-resolved, one command shows what your system is actually configured to ask, which is where a surprising number of "DNS is broken" reports turn out to be wrong from the start:

resolvectl status

Read the "Current DNS Server" line for the interface you are using. If it lists an address that is not the resolver you expect, for instance a VPN's internal server that is no longer reachable, or an old router address from a network you left, that mismatch is the whole problem, and no amount of flushing caches fixes a wrong address. If the listed server matches what you expect and lookups still fail, the resolver configuration is not the issue and the fault is further along the chain, back with the questions above.

Recently changed a DNS record?

If you or someone on your team edited a record, moved hosting, or switched DNS providers in the last day or two, and the error is inconsistent, working for some people and not others, that is not a broken record. It is expected behavior while old cached answers expire at their own pace across different resolvers. That specific situation, including how to tell whether the change actually saved correctly, is covered in how to check DNS propagation. Do not chase a "DNS error" as a bug if the timeline lines up with a recent change; give it the TTL window first.

Frequently asked questions

Which guide do I need if the browser shows a specific error code?

Search for that exact code. DNS_PROBE_FINISHED_NXDOMAIN means the name does not exist and is covered on its own page linked above. A generic "DNS server not responding" or "cannot find server" message with no specific code matches the second question on this page: try a public resolver directly and see which of the three outcomes you get.

I ran the checks and everything resolves fine now. What happened?

Most DNS failures are transient: a resolver was briefly overloaded, a cache entry expired mid-troubleshooting, or a network blip cleared itself. If it resolves cleanly now and stays that way, there is nothing further to fix. If it comes back intermittently, that pattern itself is a clue, and it is worth checking whether it correlates with a specific time of day, network, or app.

Is a DNS error the same as the site being down?

No, and the distinction matters. A DNS error means the name never resolved to an address, so no connection was ever attempted. A site being down usually means the name resolved fine but the server did not respond, refused the connection, or returned an error page. The public-resolver test above tells you which situation you are in: an address comes back, or it does not.

Why does the same domain work for me but not for a colleague?

This is almost always caching, not a broken record. Different networks use different resolvers, each holding its own cached copy of an answer with its own expiry time. One of you may be seeing a stale cached result while the other's resolver already refreshed. Confirm the current, correct record against the domain's own nameservers before assuming anything is actually wrong.

Should I just switch to a public DNS resolver and stop troubleshooting?

Switching to 1.1.1.1 or 8.8.8.8 is a reasonable permanent choice and it does rule out a broken ISP or router resolver quickly. It is a real fix when your default resolver turns out to be the problem, not just a workaround, but it will not help if the fault turns out to be with the domain's own nameservers rather than with the resolver answering you.

Where do I check if a name resolves differently in different countries?

A resolver on your own network only shows you one vantage point, and DNS answers genuinely differ by region during a migration or a partial outage. Run the same lookup from multiple locations at once with the DNS query tool, which checks from several countries in one pass and shows where an answer differs or times out.