DNS Errors Explained: Fixing DNS_PROBE_FINISHED

DNS errors are uniquely confusing because the connection is fine — and the error names sound like compiler output. DNS_PROBE_FINISHED_NXDOMAIN is Chrome's way of saying something simple: "I asked what address this website lives at, and the phone book either didn't answer or said no such name exists." Once you know which of those two it was, the fix is usually two minutes.

01 — Thirty Seconds on How DNS Works

Every site visit starts with a lookup: your PC asks a DNS resolver (normally your router, which forwards to your ISP) to translate amarbhattarai.com into an IP address. The answer gets cached — by Windows, by the browser, by the router — so repeat visits skip the question. Which means DNS failures come in exactly two flavors: the resolver is unreachable/broken, or a cache somewhere is holding a stale or poisoned answer.

💡 Plain English: DNS is the phone book. "Connected but DNS fails" is having a working phone and a dead directory service — you can dial any number you already know (that's why ping 8.8.8.8 works), but you can't look anything up by name.

02 — Decode the Error You're Seeing

ErrorMeaningSmells like
DNS_PROBE_FINISHED_NXDOMAINResolver answered: "no such domain"Typo, stale cache, hosts-file entry, or resolver hijack
DNS_PROBE_FINISHED_NO_INTERNETCouldn't reach any resolverResolver down / connection problem
DNS_PROBE_FINISHED_BAD_CONFIGLocal DNS settings invalidBad manual DNS entry, broken adapter config
DNS server not responding (troubleshooter)Configured resolver silentRouter/ISP resolver wedged
ERR_NAME_NOT_RESOLVEDGeneric resolution failureAny of the above

03 — The Five-Minute Fix Sequence

Step 1 — Rule out the obvious. One site failing while others load is usually that site's problem, not yours (check from your phone on mobile data, or a checker like downforeveryoneorjustme.com). Every site failing = your DNS.

Step 2 — Flush the caches.

# Windows resolver cache
ipconfig /flushdns
 
# Chrome/Edge also keep their own — visit:
#   chrome://net-internals/#dns   → Clear host cache
#   edge://net-internals/#dns     → Clear host cache

Step 3 — Identify whether your resolver is the problem. This is the single most diagnostic command in this article — it asks a known-good public resolver directly, bypassing yours:

nslookup amarbhattarai.com 1.1.1.1

If that succeeds while plain nslookup amarbhattarai.com fails, the verdict is in: your configured resolver (router/ISP) is broken, and Step 4 is your fix. If both fail, the problem is below DNS — work through the connection chain in my Wi-Fi diagnostics article first.

Step 4 — Switch to a public resolver. Settings → Network & internet → Wi-Fi (or Ethernet) → Hardware properties → DNS server assignment → Edit → Manual → IPv4 on:

  • Cloudflare: 1.1.1.1 / 1.0.0.1 — fast, privacy-focused
  • Quad9: 9.9.9.9 / 149.112.112.112 — blocks known-malicious domains, a nice free security layer
  • Google: 8.8.8.8 / 8.8.4.4

Or in PowerShell (admin) — replace "Wi-Fi" with your adapter's name from Get-NetAdapter:

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses 1.1.1.1,1.0.0.1

Better yet, change it once on the router (LAN/DHCP DNS setting) and every device benefits — the same setting I walk through in my Pi-hole guide, where the "public resolver" is replaced by your own filtering one.

04 — The Sneakier Causes

  • The hosts file. C:\Windows\System32\drivers\etc\hosts overrides DNS entirely, and both "tweaking" guides and malware write entries there. If exactly one site fails or goes somewhere wrong, open the file in Notepad (as admin) — anything below the comment lines you didn't add yourself should be viewed with suspicion and removed.
  • Resolver hijacking. If NXDOMAIN errors come with redirects to ad-laden "search" pages, check the router: malware that changes a router's DNS to attacker-controlled servers affects every device at once. Verify the DNS servers listed in the router's WAN settings are ones you (or your ISP) chose. While you're there: changing the router's default admin password closes the door this attack walks through.
  • VPNs and security software install their own DNS plumbing, and a crashed VPN client can leave the system pointing at a tunnel that no longer exists. ipconfig /all shows which DNS servers each adapter actually uses — a 10.x address on a machine with no active VPN is the tell. Network reset (Settings → Network & internet → Advanced network settings → Network reset) clears the wreckage.
  • A new device on old DNS: a stale answer cached at the resolver (not your PC) after a website moves servers fixes itself within hours; switching resolvers (Step 4) fixes it now.

05 — DNS-over-HTTPS: Worth Turning On

Classic DNS travels unencrypted — anyone on the path (public Wi-Fi included) can read and tamper with your lookups. DoH wraps them in HTTPS. Windows 11 supports it natively: after setting a manual DNS server (Step 4), the same Edit dialog offers DNS over HTTPS → On (automatic template) for supported resolvers like 1.1.1.1 and 9.9.9.9. Browsers have their own toggle ("Use secure DNS" in Chrome/Edge settings) — fine to enable too, just remember during troubleshooting that the browser may be ignoring the OS resolver entirely, which is why a site can fail in Chrome while nslookup happily succeeds. One honest caveat: if you later run a network-wide filter like Pi-hole, browser DoH bypasses it — choose one strategy per network.

[Personal note placeholder: a quick real example — e.g., a hijacked router DNS or hosts-file entry you've found in the wild.]

🔒 Bottom line: one command — nslookup <site> 1.1.1.1 — splits every DNS problem into "my resolver is broken" (switch resolvers, two minutes) or "something deeper" (flush caches, check the hosts file and router, then the connection itself). The phone book is replaceable; don't suffer a bad one.

← Newer Posts Older Posts →