Troubleshooting

ERR_NAME_NOT_RESOLVED: Causes and the Fix

· 4 min read · 26 views · Getwebup

The short answer

ERR_NAME_NOT_RESOLVED means DNS could not turn the hostname into an IP address, so no connection was ever attempted. Run dig +short yourdomain.com: an empty answer means the record or the nameservers are the problem, and an answer that works elsewhere but not on your machine means your resolver or cache is. Test on a phone using mobile data to tell the two apart in ten seconds.

Not sure which error you have? Decode Chrome's code first — "This Site Can't Be Reached" in Chrome: Every Code Decoded

ERR_NAME_NOT_RESOLVED is a lookup failure, not a connection failure. Chrome never got as far as opening a socket, because it never got an IP address to open one to. Everything you might be tempted to check on the server is irrelevant until DNS answers.

The ten-second test that decides everything

Open the same URL on a phone with Wi-Fi turned off. Different network, different resolver, different cache.

  • It loads on mobile data - the domain is fine and your machine's DNS is not. Go to the local fixes.
  • It fails there too - the domain's DNS is genuinely broken. Go to the domain-side causes.

Doing this first is the difference between a two-minute fix and an afternoon of editing records that were never wrong.

When it fails everywhere: check the zone, then the delegation

Ask what the domain resolves to, from a resolver that is not yours:

dig @1.1.1.1 yourdomain.com A +short

Nothing back? Then find out which nameservers the domain is actually delegated to, and ask them directly:

dig NS yourdomain.com +short
dig @ns1.yourprovider.com yourdomain.com A

Those two commands separate the two domain-side causes cleanly.

Cause 1: the nameservers are right, the zone is empty

If dig NS returns the nameservers you expect but querying them directly returns no A record, the delegation is fine and the zone has nothing in it. This is what happens when a hosting migration deletes the old zone before the new one is populated, or when a zone is created for the wrong domain name. Add the A record for the root and a CNAME or A for www, and it will resolve within the TTL.

Cause 2: the nameservers themselves are wrong

If dig NS returns nameservers you do not recognise, or returns nothing, the problem is at the registrar. Log in and check the nameserver fields character by character - a single typo in ns1.provider.com produces exactly this error and is almost invisible when you skim it. Domains that have expired or been suspended also present this way, so check the expiry date while you are there.

When it only fails for you: the local causes

Work through these in order. They cover the overwhelming majority of single-machine cases.

  1. Chrome's own cache. Go to chrome://net-internals/#dns and click "Clear host cache". Chrome keeps a resolver cache separate from the operating system, which is why flushing the OS alone so often appears to do nothing.
  2. The OS resolver. ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, resolvectl flush-caches on most Linux desktops.
  3. Your hosts file. A leftover development entry overrides DNS completely and survives every cache flush you can run. Look in /etc/hosts, or C:\Windows\System32\drivers\etc\hosts on Windows, and delete any line naming the domain.
  4. Your resolver. Set the adapter's DNS to 1.1.1.1 or 8.8.8.8 and retest. ISP resolvers in India do occasionally serve stale negative answers for hours after a record is fixed.
  5. Extensions and VPNs. Anything that proxies or filters DNS - ad blockers with DNS features, VPN clients, corporate security agents - can return this. Test in an incognito window with extensions disabled.

The www trap

A surprising share of reports turn out to be one hostname working and the other not. In DNS, example.com and www.example.com are two independent names; creating one does not create the other. Check both explicitly:

dig +short example.com
dig +short www.example.com

If one of those is empty, that is your answer. Add a CNAME for www pointing at the root domain, or a second A record carrying the same IP, and make sure your site redirects one to the other so you are not maintaining two addresses for the same content.

A note on negative caching

DNS caches failures as well as successes. The SOA record's minimum TTL controls how long a resolver remembers "this name does not exist", and if that value is set high, a fix you made correctly can appear not to work for hours. If you are about to make DNS changes on a domain that is currently failing, lowering the SOA minimum and the record TTLs beforehand saves a lot of confused retesting afterwards.

Questions people actually ask

err_name_not_resolved dns chrome nameservers troubleshooting