ERR_NAME_NOT_RESOLVED: what it means and how to fix it

What ERR_NAME_NOT_RESOLVED means

Before a browser can connect to anything, it has to turn a hostname into an IP address through DNS. Chromium's error list defines ERR_NAME_NOT_RESOLVED (code -105) as "The host name could not be resolved." Chrome's resolver tracks more detail internally, such as a timeout, a server failure or a malformed answer, but it folds all of those into this one code before the page sees it. The code tells you the lookup failed. It does not tell you why.

That is also how it relates to DNS_PROBE_FINISHED_NXDOMAIN. When a whole page fails with ERR_NAME_NOT_RESOLVED, Chrome runs a quick probe: it resolves google.com through your DNS settings and through Google Public DNS. If your DNS works, Chrome relabels the error NXDOMAIN and blames the name. If only Google's servers answer, you see DNS_PROBE_FINISHED_BAD_CONFIG, and if neither answers, DNS_PROBE_FINISHED_NO_INTERNET. The original code stays on screen when the probe does not run or is inconclusive. You also see it verbatim in these places:

• The DevTools console, as net::ERR_NAME_NOT_RESOLVED, when the page loads but one of its scripts, images or API calls points at a hostname that does not resolve.
• Android apps that show web content in a WebView. Their error screen reads "Webpage not available" and ends with the code.
• Headless browser tools. Puppeteer and Playwright throw net::ERR_NAME_NOT_RESOLVED at https://... from page.goto().

ERR_NAME_NOT_RESOLVED vs similar errors

Chrome names a failed page load after the first step that broke. The first three rows are all failed name lookups, told apart by Chrome's probe. The last three got an IP address and failed later, on the route or the TCP handshake.

Error	What happened at the network or protocol level	Where to look first
DNS_PROBE_FINISHED_NXDOMAIN	The lookup failed, then Chrome's probe resolved google.com through your DNS settings, so it blamed the name itself.	The spelling, then the domain's registration, delegation and records
ERR_NAME_NOT_RESOLVED	The lookup failed for any reason (no such name, no address record, a DNS server that failed or never answered), and no probe narrowed it down.	Compare your resolver's answer with a public resolver's
DNS_PROBE_FINISHED_BAD_CONFIG	Your configured DNS server failed the probe while Google Public DNS answered it.	DNS settings on the device, router or VPN; see DNS server not responding
ERR_ADDRESS_UNREACHABLE	DNS returned an address, but the operating system or a router reported there is no path to it ("No route to host").	Routes and VPN on your side, then firewalls that reject with ICMP
ERR_CONNECTION_TIMED_OUT	DNS and routing worked, but the TCP handshake got no reply before the timeout.	A firewall or security group that drops packets, or a server that is down
ERR_CONNECTION_REFUSED	The host answered the handshake with a TCP reset (or ICMP port unreachable): nothing accepted that port.	The web server process, its listen port, and REJECT firewall rules

How the error appears

Chrome shows "This site can't be reached" with "example.com's server IP address could not be found." Firefox shows "Hmm. We're having trouble finding that site." Command-line tools say more than the browser does, because they print the DNS status. Ask a specific resolver with dig:

dig www.example.com A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5512
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

The status field is the part to read:

• NOERROR with ANSWER: 0: the name exists but has no record of the type you asked for. Chrome treats that as a failed lookup too.
• NXDOMAIN: the name does not exist in the zone.
• SERVFAIL: the resolver could not get a valid answer, usually because the domain's nameservers are down or misconfigured, or DNSSEC validation failed.
• no servers could be reached, after one or more timeout lines: your resolver never answered.

On Windows, nslookup prints "Non-existent domain" for NXDOMAIN, "Server failed" for SERVFAIL and "DNS request timed out." when the server does not answer. Resolve-DnsName in PowerShell reports "DNS name does not exist" and "DNS server failure" for the first two. To see where the chain breaks, dig +trace www.example.com follows the delegation from the root servers down to the domain's own nameservers and stops at the step that fails.

What causes ERR_NAME_NOT_RESOLVED

On the domain's side, where every visitor is affected:

• A missing A or AAAA record for the exact hostname. www.example.com and example.com are separate names, and each needs its own record, a CNAME or a matching wildcard.
• A domain that is unregistered, expired or on hold. Once the registry removes a domain from DNS, or holds it with the clientHold or serverHold status, lookups return NXDOMAIN for everyone.
• Nameservers that are down or lame. If the servers listed at the registrar do not answer, or answer without authority for the zone (common after a DNS provider move), resolvers return SERVFAIL.
• A broken DNSSEC chain. An expired signature, or a DS record at the registrar that no longer matches the zone's key, makes validating resolvers refuse the answer. Resolvers that do not validate still answer, so the site works for some visitors and not for others.

On the visitor's side, where one device or network is affected:

• An unreachable or failing resolver. A router pointing at a DNS server that no longer exists, a VPN that breaks DNS when it connects or drops, or a captive portal on hotel or airport Wi-Fi that blocks or redirects lookups until you sign in.
• A secure DNS setting that names a provider which is down or filtering: Chrome's Use secure DNS, or Private DNS on Android.
• A stale cache in the browser, the operating system or the router, holding a failure from before the record was fixed.

In development environments, where a test, a container or a script fails:

• Container names on Docker's default bridge network. Containers resolve each other by name only on a user-defined network.
• Kubernetes Service names used outside the cluster, or a short Service name used from a pod in another namespace.
• Containers using DNS servers they cannot reach. Containers use the host's DNS servers by default. When those servers cannot be reached from the container network, every lookup inside the container fails.

How it looks from the outside

Take your own network out of the picture first. Query a public resolver directly with dig @8.8.8.8 www.example.com or nslookup www.example.com 1.1.1.1. If that answers and your default resolver does not, the fault is on your side. If it fails too, look at the domain's DNS.

For a site you run, add more vantage points. A DNS lookup run from multiple locations shows what resolvers in different places return, and the pattern points at the cause:

• No address from any location. The record, delegation or registration is missing, or the nameservers fail for everyone. The status from dig separates the two: NXDOMAIN for a missing name, SERVFAIL for broken nameservers or DNSSEC.
• Addresses from some locations, failures from others. Some resolvers validate DNSSEC and some do not, so a broken chain fails only part of them. Nameservers that serve different versions of the zone do the same, as does a recent change that is still aging out of caches.
• Different addresses in different places. A content delivery network answering per region, which is normal, or a change in progress.
• Every location gets an address except you. Your resolver, VPN, secure DNS setting or cache.

A record that resolves in some places but not others for a while after a change is DNS propagation, explained in how to check DNS propagation.

How to fix it on your device

1. Flush the DNS caches. Windows: ipconfig /flushdns. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux with systemd-resolved: sudo resolvectl flush-caches. In Chrome, also clear the host cache at chrome://net-internals/#dns.
2. Switch to a public resolver such as 1.1.1.1 or 8.8.8.8 for the connection, replacing what your router or ISP provides while you test. In Windows 11 it is under Settings, Network & internet, your connection, DNS server assignment. On a Chromebook, choose Google name servers in the Wi-Fi network's Network settings.
3. Check secure DNS. In Chrome, open chrome://settings/security and look at Use secure DNS. On Android, also open Settings, Network & internet, Private DNS. A named provider that is down breaks every lookup, so switch back to the default or Automatic setting to test.
4. Disconnect from the VPN and retry, or reconnect it if the error started when the VPN dropped.
5. Finish signing in to the network. On hotel, airport or office guest Wi-Fi, complete the sign-in page first; many captive portals block or redirect DNS until you do.
6. Restart the router if every site fails on that network, not just one.

Fixes for site owners and developers

Records and nameservers

dig www.example.com A +short
dig example.com A +short
dig NS example.com +short
dig @ns1.example-dns.net www.example.com A +norecurse

The first two are separate names and need separate records. The last asks your nameserver directly, and the reply should carry the aa (authoritative answer) flag. A nameserver that replies REFUSED, or answers without aa, does not host the zone and should come off the NS list at the registrar. Check with your registrar that the registration is active and not on hold. If you run your own nameserver, check the zone file before reloading, because a zone that fails to load stops answering for the whole domain, and make sure port 53 is open over both UDP and TCP:

named-checkzone example.com /etc/bind/db.example.com
sudo ufw allow 53/udp
sudo ufw allow 53/tcp

DNSSEC

dig www.example.com @1.1.1.1
dig www.example.com @1.1.1.1 +cd
dig DS example.com +short
dig DNSKEY example.com +multi

If the plain query returns SERVFAIL and the +cd query (checking disabled) returns an address, DNSSEC validation is what fails. The first number in each DS record is a key tag, and it must match the key id that +multi prints for the zone's key-signing key. A DS record left at the registrar after a move to a DNS provider with different keys is a common cause. Remove it, or replace it with the new provider's DS record.

Docker and Kubernetes

Docker's embedded DNS resolves container names only on user-defined networks. On the default bridge, a test container running headless Chrome gets ERR_NAME_NOT_RESOLVED for http://web:3000. Put both containers on one network:

docker network create appnet
docker run -d --name web --network appnet my-web-image
docker run --rm --network appnet my-test-image

If containers cannot resolve public or company names at all, pass --dns to docker run, or give the daemon DNS servers that work on your network in /etc/docker/daemon.json and restart Docker:

{
  "dns": ["10.0.0.2", "1.1.1.1"]
}

In Kubernetes, a Service gets a name of the form my-svc.my-namespace.svc.cluster.local, where cluster.local is the usual cluster domain. A short name like my-svc resolves only from pods in the same namespace, and none of these names exist outside the cluster, so a browser on your laptop fails on all of them. Test resolution from inside:

kubectl run dnstest --rm -it --restart=Never --image=busybox:1.36 -- nslookup my-svc.my-namespace.svc.cluster.local

How to prevent ERR_NAME_NOT_RESOLVED

DNS failures are easy to miss from inside, because an office network and its cached records can keep working long after visitors elsewhere start failing. A DNS check that runs from 300+ checkpoints in 158 cities catches a nameserver outage, an expiring registration or a broken record when it starts affecting resolution, not after the support inbox fills up. HostTracker has monitored websites since 2004 and alerts by email, SMS, voice call, Slack, Telegram and more.

Frequently asked questions

What is the difference between ERR_NAME_NOT_RESOLVED and DNS_PROBE_FINISHED_NXDOMAIN?

Both start from the same failed lookup. ERR_NAME_NOT_RESOLVED is the failure itself, with no cause attached. DNS_PROBE_FINISHED_NXDOMAIN is the label Chrome shows after its probe finds your DNS working for other names, so it concludes that this particular name does not exist.

Why do I see net::ERR_NAME_NOT_RESOLVED in the console when the page itself loads?

One of the page's resources lives on a hostname that does not resolve: an analytics script, a font, an ad, or an API on a retired domain. The Network tab in DevTools shows which request failed. A DNS filter or ad blocker that blocks the hostname produces the same entry.

Is ERR_NAME_NOT_RESOLVED the same as the site being down?

No. The browser never reached the server, so the server may be running normally. The failure is in DNS, either for the domain itself or on your side.

Can an expired domain cause this error?

Yes. Once an expired domain is removed from its zone or put on hold, every lookup returns NXDOMAIN. Before that, many registrars point it at a parking page, so the site changes rather than failing outright.

Why does the site work on mobile data but not my home Wi-Fi?

That points at the resolver your home network uses, either your router's DNS server or your ISP's. Switching that network to a public resolver like 1.1.1.1 usually confirms and fixes it.

Why does an Android app show net::ERR_NAME_NOT_RESOLVED?

The app displays a web page in a WebView, which uses the same network code as Chrome and shows the raw error. The causes are the same: switch between Wi-Fi and mobile data, check Private DNS, and pause VPN or ad-blocking apps.

I just added a new subdomain and it won't resolve. Why?

Confirm the record exists first, with dig subdomain.example.com A sent to the authoritative nameserver directly. If it does, a resolver that looked the name up before you created it is holding the old negative answer, which expires after the negative-caching time in the zone's SOA record.

Does DNSSEC ever cause this error on a domain that is otherwise fine?

Yes. If DNSSEC signatures expire or the chain of trust breaks, a validating resolver refuses to answer rather than return data it cannot verify, which looks identical to a resolution failure from the visitor's side.

Sources and further reading

• Chromium net error list, the definitions of ERR_NAME_NOT_RESOLVED (-105) and the other network error codes.
• RFC 1035, Domain names: implementation and specification.
• Docker: bridge network driver, on name resolution between containers on user-defined networks.
• Kubernetes: DNS for Services and Pods.