Is ERR_NAME_NOT_RESOLVED the same as DNS_PROBE_FINISHED_NXDOMAIN?

They come from the same failure. When a page's main address won't resolve, Chrome often runs a quick DNS check and shows a DNS_PROBE_ code instead. ERR_NAME_NOT_RESOLVED is what you see for images, scripts and API calls, and in many apps built on Chromium. Either way, ask DNS directly with dig or nslookup to find out what actually failed.

nslookup finds the site but Chrome says ERR_NAME_NOT_RESOLVED. Why?

Chrome isn't asking the same resolver or is using a stale cache. Check Chrome's Use secure DNS setting, clear its cache at chrome://net-internals/#dns, and disconnect any VPN. A custom secure DNS provider can't see internal or split-horizon names.

The site works on 8.8.8.8 but not on my ISP's DNS, or the other way round. What does that mean?

If validating resolvers like 1.1.1.1 and 8.8.8.8 fail while a non-validating one works, suspect DNSSEC, usually a stale DS record left at the registrar. If only one resolver fails, that resolver is filtering the name or is broken.

Can an expired domain cause ERR_NAME_NOT_RESOLVED?

Yes. Once a domain is on hold or past its grace period, the registry stops publishing it and every name under it fails to resolve. Check the domain's status with an RDAP lookup and renew or clear the hold at the registrar.

ERR_NAME_NOT_RESOLVED: What It Means and How to Fix It

What the error means

ERR_NAME_NOT_RESOLVED (Chromium net error -105) means the browser asked DNS for the address of a hostname and got nothing it could use. It never reached a server. No TCP connection, no TLS, no HTTP. So nothing about the web server, its certificate or its firewall matters until the name resolves.

Where you see it depends on what failed:

For a page’s main address, Chrome usually runs a quick DNS probe after the failure and shows the result instead: DNS_PROBE_FINISHED_NXDOMAIN, DNS_PROBE_FINISHED_NO_INTERNET, DNS_PROBE_FINISHED_BAD_CONFIG and similar. The DNS_PROBE_FINISHED_NXDOMAIN guide covers that page.
For everything a page loads, such as images, scripts, fonts and API calls, there’s no probe. You get net::ERR_NAME_NOT_RESOLVED in the DevTools console against the failing hostname.
In apps built on Chromium (Electron apps, Android WebViews), the raw code tends to appear directly.

Other tools report the same failure in their own words. curl says curl: (6) Could not resolve host: example.com. Node.js throws getaddrinfo ENOTFOUND when the name doesn’t exist and EAI_AGAIN when the lookup failed temporarily. Python on Linux says Name or service not known or Temporary failure in name resolution. The browser code doesn’t distinguish those cases, but they need different fixes, which is why the next step is to ask DNS yourself.

Thirty seconds: is it you or the domain?

Read the hostname again. A dropped letter, .co for .com, a stray hyphen. It’s the most common cause, and no amount of DNS debugging fixes a typo.
Try another network. Open the address on your phone with Wi-Fi off. Mobile data uses your carrier’s resolver, a completely separate path.
Ask from outside. The DNS lookup queries public resolvers from our servers, not from your network. The propagation check asks several large resolvers at once.

If the name resolves from outside, the domain is fine and the cause is your device, browser or network (skip to When only your machine fails). If it fails everywhere, the domain’s DNS is broken and only whoever runs the domain can fix it.

Ask DNS directly and read the status

dig www.example.com A

On Windows without dig: nslookup www.example.com 1.1.1.1, or in PowerShell Resolve-DnsName www.example.com -Server 1.1.1.1.

The status line in dig’s header is the diagnosis:

What dig shows	Meaning	Usually fixed by
`status: NXDOMAIN`	The name doesn’t exist at all	Domain owner: missing record, typo, expired or held domain
`status: NOERROR`, `ANSWER: 0`	The name exists but has no A/AAAA record (“NODATA”)	Domain owner: add the address record
`status: SERVFAIL`	The resolver couldn’t get a trustworthy answer	Domain owner: broken delegation or DNSSEC
`connection timed out; no servers could be reached`	Your resolver didn’t answer at all	You: network, router or resolver settings

Now compare resolvers. Run the same query against two or three:

dig @1.1.1.1 www.example.com A +short
dig @8.8.8.8 www.example.com A +short
dig www.example.com A +short          # whatever your system uses

All fail the same way: it’s the domain. Only your default fails: it’s your resolver. Validating public resolvers fail with SERVFAIL while your ISP’s works: read the DNSSEC section below.

SERVFAIL: the case people misdiagnose

NXDOMAIN is an answer. SERVFAIL means the resolver tried and couldn’t get one it trusted. The browser shows the same error either way, but the fixes have nothing in common with each other.

DNSSEC validation failure

The classic: the domain had DNSSEC enabled at its old DNS provider, moved to a new provider that doesn’t sign the zone (or signs it with different keys), and the old DS record is still published at the registry. Validating resolvers see a chain of trust that doesn’t match and refuse to return anything. Non-validating resolvers ignore DNSSEC and answer normally. The result is “works for some people, not others”, depending on which resolver they use.

The test is +cd (checking disabled), which asks the resolver to skip validation:

dig @1.1.1.1 example.com A          # status: SERVFAIL
dig @1.1.1.1 example.com A +cd      # status: NOERROR, with an answer

If +cd gets an answer and the normal query doesn’t, it’s DNSSEC. Recent dig versions also print an Extended DNS Error line when the resolver supplies one (Cloudflare’s resolver often does), such as EDE: 6 (DNSSEC Bogus) or EDE: 7 (Signature Expired).

Then look at what the registry publishes:

dig DS example.com +short
dig DNSKEY example.com +short

A DS record with no matching DNSKEY in the zone is the stale-DS case. Fix: either remove the DS record at your registrar, or turn on DNSSEC at the new provider and replace the DS with the one it gives you. Validating resolvers recover once the old DS has expired from their caches. Signature Expired points to a zone whose automatic re-signing has stopped; that’s a problem at whoever signs the zone.

Broken delegation

The registry lists nameservers for the domain, but those servers don’t serve the zone. It happens after a nameserver change when the zone was never created at the new provider, when the nameserver names were mistyped, or when the old provider deleted the zone before the switch. The servers answer REFUSED or nothing at all, and resolvers give up with SERVFAIL. Cloudflare’s resolver tends to tag this EDE: 22 (No Reachable Authority).

Ask the registry what it delegates to, then ask each of those servers directly:

dig NS com +short                                    # the TLD's own nameservers
dig NS example.com @a.gtld-servers.net +norecurse    # what the registry delegates to
dig SOA example.com @ns1.dns-provider.example +norecurse

The registry’s answer is a referral, so the nameservers appear in the authority section rather than the answer section. Swap com for your TLD (kr, net, io) and use one of the servers it returns.

A healthy nameserver answers with status: NOERROR and the aa (authoritative) flag. REFUSED, SERVFAIL or a timeout from a listed nameserver means that delegation is broken. The nameserver mismatch guide walks through comparing the registry’s list with what each server actually serves.

One more variant: nameservers inside the domain itself (ns1.example.com serving example.com) need glue records, meaning their IP addresses registered at the registrar. Without glue, resolvers can’t find the nameservers’ addresses without first resolving the domain they serve. Most registrars handle this under a name like “host records” or “register nameservers”.

NXDOMAIN and NODATA: the name really isn’t there

These are covered in depth in the DNS_PROBE_FINISHED_NXDOMAIN guide. The short version, with the cases that come up most:

The record exists for one name but not the one people type. The site is set up at www.example.com and someone types example.com, or the other way round. If the apex has MX and TXT records but no A, you get NODATA rather than NXDOMAIN. Create both names and redirect one to the other.
The domain is out of the TLD zone. clientHold, serverHold, expiry past the grace period. The registry stops publishing the domain, so every name under it fails. A newly registered .com or other gTLD domain whose registrant never confirmed the contact verification email gets suspended the same way. Check the status with the RDAP lookup; the domain status guide explains each stage.
A CNAME points at something that was deleted. dig shows your CNAME in the answer section and NXDOMAIN for the whole chain. Typical after a hosted shop, app or storage bucket is removed while the DNS record stays. Fix or delete the record; a dangling CNAME is also how subdomain takeovers start.
The record is new and “doesn’t exist” was cached. Something looked the name up before you created it, and resolvers keep that negative answer for the time set in your zone’s SOA record. Confirm with dig @<your nameserver> name A +norecurse that the record is published, then wait it out.
You edited a zone that isn’t live. Compare dig NS example.com +short with the provider whose dashboard you changed.

When only your machine fails

The domain resolves from outside but not for you. In rough order of likelihood:

A stale cache. Your OS or browser cached the failure, perhaps from a moment the site really was down.

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches

Chrome also keeps its own: open chrome://net-internals/#dns and click “Clear host cache”.

Chrome’s secure DNS. Settings → Privacy and security → Security → “Use secure DNS”. If it’s set to a specific provider, Chrome sends lookups there instead of to your network’s resolver. That provider can’t see names that only exist on your company or home network, so those fail in Chrome while nslookup on the same machine works. If the chosen provider is unreachable from your network, every lookup fails, and Chrome may show DNS_PROBE_FINISHED_BAD_SECURE_CONFIG on main pages. Switch it to use your current service provider and compare. Android has a similar system-wide setting called Private DNS, which fails the same way if the configured hostname can’t be reached.

A VPN. VPNs usually push their own resolver. Internal names resolve only while connected, some VPN resolvers handle public names badly, and a messy disconnect can leave the VPN’s resolver configured with no way to reach it. Disconnect fully, flush, try again. On Linux, resolvectl status shows which resolver each interface is actually using; on Windows, ipconfig /all.

A filtering resolver. Resolvers that block names often answer NXDOMAIN for them: security-filtering public resolvers, Pi-hole, AdGuard Home, NextDNS, parental controls, some ISPs. If nslookup example.com 1.1.1.1 works and nslookup example.com doesn’t, your resolver is blocking or broken. Check its block log.

Public Wi-Fi before you’ve logged in. Some captive portals block DNS until you sign in. Open a plain-HTTP page such as http://neverssl.com to bring up the login page, then retry.

What the hosts file does and doesn’t do. An entry in /etc/hosts (or C:\Windows\System32\drivers\etc\hosts) makes a name resolve, so it can’t cause this error. It can cause the opposite confusion: a stale entry makes a site work on your machine while everyone else gets ERR_NAME_NOT_RESOLVED. If you test migrations with hosts entries, remove them before you trust your own browser.

When the page loads but something on it doesn’t

If the page itself works and the console shows net::ERR_NAME_NOT_RESOLVED against another hostname, the broken name is a dependency. Common reasons:

A third-party script, font or widget whose provider shut down or let its domain lapse.
A staging, localhost-like or internal hostname baked into a production build or an environment variable.
An internal API name that only resolves on the office network or VPN, so the page works for staff and breaks for everyone else.
A tracker or ad domain that a visitor’s DNS-level blocker answers with NXDOMAIN. That’s their choice, and your page should survive without it.

To check every hostname your build references in one go:

grep -rhoE 'https?://[A-Za-z0-9.-]+' dist/ | sed 's#^.*://##' | sort -u |
while read -r h; do
  [ -n "$(dig +short "$h" A "$h" AAAA)" ] || echo "does not resolve: $h"
done

Replace dist/ with your build output directory. Anything listed either needs fixing or removing.

After the fix

A nameserver or delegation fix can take a while to reach every resolver, because the old delegation stays cached for its TTL. The DNS propagation guide explains the timing; the propagation check shows you which large resolvers have caught up.
After a DNSSEC fix, test against a validating resolver (dig @1.1.1.1 example.com A) without +cd. That’s the one that was failing.
Test every name people use: the apex, www, and any subdomain in links or emails.

DNS_PROBE_FINISHED_NXDOMAIN: the error page Chrome shows for the main address, with SOA reading and NXDOMAIN causes in depth.
Nameserver mismatch: when the registry and your DNS provider disagree.
clientHold and pendingDelete: what each domain status means and how to recover.
ERR_CONNECTION_TIMED_OUT: the next step down, when the name resolves but the server doesn’t answer.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.