LiveChat 
Support 
DNS Error: What It Means and How to Fix Every Type
You typed a familiar address, hit enter, and instead of a website you got a blunt little message: DNS error. No page, no warning, just a dead end. The frustrating part is that “DNS error” tells you almost nothing about what actually broke. It’s a category, not a diagnosis.
Here is the calm way to think about it. Every time you visit a site, your device has to translate a human-friendly domain name into a numeric IP address that machines route to. That translation is DNS — the Domain Name System. A DNS error is simply any failure in that translation. The lookup breaks somewhere along the chain, and your browser has no IP to connect to, so it gives up and shows an error.
The good news: although there are a dozen different DNS error messages, they nearly all collapse into two buckets, and once you know which bucket you’re in, the fix is usually obvious. Let’s isolate the cause step by step.
Key Takeaways
• A DNS error is any failure to translate a domain name into an IP address — the lookup breaks before your browser can connect.
• The common DNS errors (NXDOMAIN, “server not responding”, BAD_CONFIG, SERVFAIL, “can’t find server”) all split into two categories: resolver-side and record-side.
• One test sorts almost every case: try the same domain on a completely different network (such as mobile data).
• Works elsewhere? The problem is your network or device — fix it locally. Fails everywhere? It’s the domain’s records or registration — the site owner’s job.
• The universal toolkit: flush DNS, switch to a public resolver, restart the router, disable your VPN, and confirm the domain hasn’t expired.
What exactly is a DNS error?
A DNS error occurs when the system that turns `example.com` into an address like `93.184.216.34` cannot finish the job. Think of DNS as the internet’s phone book. When you request a site, your device asks a DNS resolver to look up the matching number. That resolver may check its cache, then query the domain’s authoritative nameservers, then hand the answer back. If any link in that chain fails — the resolver is unreachable, the record doesn’t exist, the configuration is wrong, the domain has lapsed — you get a DNS error.
This is why the message feels vague. The same red screen can mean “your Wi-Fi router has a stale setting” or “this domain was deleted last week.” They are completely different problems with completely different owners. Your job when you hit a DNS error is not to panic but to isolate which link in the chain broke. For the bigger picture of how this entire lookup chain works end to end, see the complete guide on DNS for hosting and how visitors reach your server.
What are the common DNS errors and what do they mean?
Different browsers and operating systems phrase the same underlying failures differently. Chrome shows `DNS_PROBE_FINISHED_*` codes, Firefox says it “can’t find the server,” and Windows tends to say the “DNS server isn’t responding.” Underneath, they describe a small set of failure modes. Here is the map.
| Error message | What it means | Likely cause | Read more |
|---|---|---|---|
| DNS_PROBE_FINISHED_NXDOMAIN / ERR_NAME_NOT_RESOLVED | The domain has no DNS record — the name doesn’t resolve to anything | Typo, expired domain, missing/deleted DNS record, or local DNS cache holding a bad entry | NXDOMAIN guide |
| DNS server not responding | Your resolver can’t be reached at all | Router or network glitch, wrong DNS server set, ISP resolver down, firewall blocking port 53 | “DNS server not responding” guide |
| DNS_PROBE_FINISHED_BAD_CONFIG | Your device’s DNS configuration is malformed or invalid | Corrupt local DNS settings, bad manual DNS entries, conflicting network adapters | This guide (resolver-side) |
| SERVFAIL | The resolver reached the authoritative server but got a failure back | Broken DNSSEC, misconfigured nameservers, authoritative server error | This guide (record-side) |
| “Can’t find server” / “Server not found” | Generic catch-all — the browser got no usable IP | Any of the above; needs isolation to pin down | This guide |
A few notes on reading this table. NXDOMAIN and ERR_NAME_NOT_RESOLVED are close cousins: both mean “no record found.” DNS server not responding is fundamentally different — there the record might be perfectly fine, but you never reached anything that could tell you. SERVFAIL is the subtle one: the lookup got far enough to talk to the domain’s nameservers, but something on the authoritative side failed, often a DNSSEC mismatch.
You don’t need to memorize every code. You need to know which of two buckets each one falls into — and that’s the insight that makes troubleshooting fast.
The two-bucket model. “DNS error” is an umbrella over a dozen specific failures, but they split cleanly into just two categories that determine your fix. On one side are resolver-side errors: your device or network can’t reach or use its DNS server. “Server not responding” and BAD_CONFIG live here — the lookup never gets a clean answer because the path to DNS is broken. On the other side are record-side errors: the lookup reached DNS perfectly fine, but the domain has no record or the wrong one. NXDOMAIN and ERR_NAME_NOT_RESOLVED live here — DNS answered, and the answer was “nothing.” The single test that sorts almost every DNS error into the right bucket is this: try the same domain on a completely different network, such as your phone on mobile data with Wi-Fi turned off. If it works there, the problem is your resolver or network — fix it locally by switching DNS, flushing the cache, or restarting the router. If it fails everywhere, the problem is the domain’s records or registration — that’s the site owner’s to fix, usually an expired domain or a missing record. One test, two buckets, and the right fix follows immediately.
How do I tell if it’s me or the site?
Before you change a single setting, run the universal test. It costs thirty seconds and saves you from “fixing” things that were never broken.
- Open the failing site on a different network. Easiest version: grab your phone, turn off Wi-Fi so it uses mobile data, and load the same URL. A different network uses a different resolver, so this instantly separates a local problem from a global one.
- Interpret the result.
- It loads on mobile data but not on your computer → resolver-side. The site is fine; your device or network is the problem. Move to the local toolkit below.
- It fails on every device and every network → record-side. The domain itself isn’t resolving anywhere. If you don’t own the site, you can only wait; if you do own it, jump to the record checks.
- Optional confirmation with a command. Run a direct lookup (see the code below). If a public resolver like `8.8.8.8` returns an answer but your normal connection doesn’t, that’s a resolver-side problem confirmed.
This single test is the backbone of methodical DNS troubleshooting. Everything after it is just applying the correct toolkit to the correct bucket.
What are the general DNS error fixes that work for almost any case?
If the test points at your side — or you just want to rule out the easy stuff first — work through this universal toolkit in order. These fixes resolve the large majority of everyday DNS issues.
1. Flush your DNS cache
Your computer stores past lookups to save time. When one of those stored entries goes stale (the site changed servers, or it cached a failure), you keep hitting a dead address. Clearing the cache forces a fresh lookup.
“`bash
ipconfig /flushdns
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
sudo resolvectl flush-caches “`
For the full walkthrough across every OS and browser, see the dedicated guide.
2. Switch to a public DNS resolver
Your ISP’s default resolver may be slow, overloaded, or temporarily down. Pointing your device at a reliable public resolver often clears the error immediately.
- Google Public DNS: `8.8.8.8` and `8.8.4.4`
- Cloudflare: `1.1.1.1` and `1.0.0.1`
On Windows, set these under Network adapter properties → Internet Protocol Version 4 → “Use the following DNS server addresses.” On macOS, they go under System Settings → Network → DNS. On a phone, you can set a private DNS hostname in network settings.
3. Restart your router
A router caches DNS too, and routers run for months without a reboot. Power it off, wait thirty seconds, and power it back on. This clears stale router-level DNS state and re-establishes a clean connection to your ISP — a tired fix that genuinely works more often than it should.
4. Disable your VPN or proxy
VPNs route DNS queries through their own resolvers, which sometimes fail or get misconfigured. Temporarily turn off any VPN, proxy, or “secure DNS” browser feature and reload. If the site appears, your VPN’s DNS was the culprit; switch its DNS settings or pick another server.
5. Try another device on the same network, then another network
If the site fails on your laptop but works on another device on the same Wi-Fi, the problem is that one device — its cache, adapter, or DNS config. If it fails on every device on your network but works on mobile data, the problem is your router or ISP. This is the test from earlier, applied with precision to narrow the blast radius.
6. Check that the domain hasn’t expired
If nothing resolves anywhere, the domain may simply be expired or deleted. A lapsed registration pulls the records, producing NXDOMAIN globally. A quick WHOIS lookup shows the registration and expiry status — and if it’s expired, no local fix will help; the owner must renew.
7. Check your records (if you own the site)
If you control the domain and visitors report DNS errors, verify your DNS records and nameservers directly. A missing A record, a typo in a CNAME, or nameservers pointing at the wrong provider will break resolution for everyone. Confirm the record exists and matches your server’s IP, then allow time for changes to take effect — record edits aren’t instant. If you recently moved hosts or changed records, you may simply be waiting on to finish.
When the resolver itself seems unreachable rather than the record being wrong, that’s a different failure mode worth reading up on.
How do I run a DNS lookup to confirm the problem?
Commands turn guesswork into evidence. Two are enough for almost any DNS error.
“`bash
nslookup example.com
nslookup example.com 8.8.8.8
dig example.com +short dig example.com @1.1.1.1 +short “`
Read the output like a diagnostician:
- You get an IP address back → DNS is working; the error is elsewhere (the server, a firewall, or a stale browser tab).
- `NXDOMAIN` → no record exists. Record-side problem; check the domain’s registration and records.
- No response or timeout from your resolver, but `8.8.8.8` answers → resolver-side. Switch your DNS or restart the router.
- `SERVFAIL` → the authoritative side failed, often DNSSEC. If you own the domain, check your DNSSEC and nameserver config.
For the most common record-side message specifically, the focused fix lives in the .
DarazHost runs fast, reliable, redundant DNS for hosted domains, so the authoritative side answers correctly — every time a visitor’s resolver comes knocking, the right record is there to hand back. And if you own a site and visitors are hitting DNS errors, our 24/7 support helps you verify your records, nameservers, and domain status fast, so the problem is found and fixed instead of guessed at. When the lookup chain has to work for real traffic, the answer-side reliability is exactly where it should never be left to chance.
How long does a DNS error take to resolve?
It depends entirely on which bucket you’re in. Resolver-side errors — your network, cache, or device — usually clear the moment you flush DNS, switch resolvers, or restart the router: seconds to a few minutes. Record-side errors are slower. If a record was just added or corrected, it can take time to propagate across resolvers worldwide; if a domain expired, resolution returns only after renewal and re-propagation. The two-bucket test tells you which timeline you’re on before you start waiting.
Frequently asked questions
What does a DNS error actually mean? It means your device could not translate a domain name into the IP address needed to connect. The lookup failed somewhere — either your network couldn’t reach a DNS server (resolver-side) or the domain had no valid record to return (record-side). The message itself is generic; the cause is one of those two.
Why do I get a DNS error on only one website? If one specific site fails while everything else loads, the problem is almost certainly with that site’s DNS records or its server — not your network. Your resolver is clearly working for other domains. Confirm with a lookup: an `NXDOMAIN` or `SERVFAIL` for just that domain points to a record-side issue you can’t fix unless you own it.
Will flushing DNS fix every DNS error? No. Flushing the DNS cache only helps when the problem is a stale or bad entry stored locally — a resolver-side issue. If the domain genuinely has no record or has expired, flushing changes nothing, because the failure is on the authoritative side, not in your cache.
Is a DNS error the same as the site being down? Not necessarily. A site can be fully online while a DNS error stops you from reaching it — for example, if your resolver is misconfigured or a record was recently changed and hasn’t propagated. Conversely, the site really can be unreachable if its domain expired. Run the cross-network test to tell which.
Can changing to 8.8.8.8 or 1.1.1.1 cause problems? For the vast majority of users, no — these public resolvers are fast and reliable. The rare exception is a network that depends on internal DNS (such as a corporate or campus network) to reach private resources. On those networks, overriding DNS can hide internal sites, so switch back when you leave.
