DNS Address Could Not Be Found: What the Browser Is Really Telling You

Q: How do I fix DNS address could not be found in Chrome?

Flush your DNS cache (ipconfig /flushdns on Windows) and Chrome's own cache at chrome://net-internals/#dns, then switch to a public resolver like 1.1.1.1. Also check Chrome's Secure DNS setting under Privacy and security, which can make one browser fail where others work.

Q: How do I know if the problem is my computer or the website?

Test other sites and run nslookup example.com 8.8.8.8. If only one site fails and it does not resolve against a public resolver either, the problem is the domain - a typo, an expired registration, or unpropagated records. If many sites fail, your DNS setup is the issue.

The DNS address could not be found error - Chrome’s wording, but every browser has a version - means the browser asked a DNS server to turn the domain name into an IP address and got nothing back. The name did not resolve. The fastest fixes, in order: flush your DNS cache, switch to a public resolver like 1.1.1.1, and confirm the domain is actually spelled right and still exists. Most of the time it is a stale cache or a flaky resolver, not the site being down - and you can tell which in under a minute.

The error blames DNS, and it is usually right, but DNS covers a lot of ground - your cache, your resolver, the domain’s own records. The trick is to narrow down which of those failed before you start changing settings at random.

First, is it one site or all sites?
Flush the DNS cache
Switch to a public resolver
Check the browser’s Secure DNS setting
When it is the domain, not you
How this fits the rest of the stack
FAQ

First, is it one site or all sites?

This single question splits the problem in half. Try a few other websites.

Only one site fails - the problem is that domain: a stale cache entry, a typo, or the domain’s own DNS records. Your resolver is basically fine.
Every site fails - the problem is your DNS setup: the resolver is down or unreachable, or your DNS configuration is broken.

Then test resolution directly:

nslookup example.com
nslookup example.com 1.1.1.1

If your default resolver fails but forcing 1.1.1.1 succeeds, your resolver is the problem and a public one works. If both fail, the domain itself may not resolve anywhere - which points at the site, not you. That two-line test tells you where to aim before you touch a single setting.

Flush the DNS cache

If a specific site fails - especially one that worked yesterday or recently changed hosts - a stale cache entry is the most likely cause. Clear it:

Windows:  ipconfig /flushdns
macOS:    sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux:    sudo resolvectl flush-caches

Also clear the browser’s own DNS cache, which is separate. In Chrome, visit chrome://net-internals/#dns and click Clear host cache, then chrome://net-internals/#sockets and flush sockets. Chrome keeps its own cache on top of the OS one, so an OS flush alone sometimes is not enough.

After both, retry the site. A stale cache is behind a large share of these errors, and flushing is a thirty-second fix that costs nothing to try first.

Switch to a public resolver

If many sites fail, or forcing 1.1.1.1 in the nslookup test worked, point your device at a public resolver:

Cloudflare: 1.1.1.1 / 1.0.0.1
Google: 8.8.8.8 / 8.8.4.4
Quad9: 9.9.9.9

Set them in your OS network settings (not just the browser). On Windows, adapter properties, IPv4. On macOS, Network, Details, DNS. On Linux, your connection settings.

Public resolvers are more reliable than most ISP defaults, and if switching fixes it, you have confirmed your assigned resolver was failing. This also sidesteps a subtler cause: some ISP resolvers block or misroute certain domains, so a name that fails on their resolver resolves fine on a neutral public one.

Check the browser’s Secure DNS setting

If the site fails in one browser but works in another - or works in an app but not the browser - the browser’s own Secure DNS (DNS-over-HTTPS) setting is the likely culprit. A browser with Secure DNS on uses its own resolver, independent of the OS, so it can fail where the rest of the system succeeds, or vice versa.

Chrome: Settings, Privacy and security, Security, Use secure DNS.
Edge: Settings, Privacy, search, and services, Security, Use secure DNS.
Firefox: Settings, Privacy and Security, DNS over HTTPS.

Try toggling it. If Secure DNS is pointed at a resolver that cannot answer the name - or is being blocked - turning it off (so the browser follows the OS resolver) or switching its provider often fixes it immediately. This is the number one reason a site works everywhere except one browser.

When it is the domain, not you

Sometimes the honest answer is that the name genuinely does not resolve, and nothing on your machine will fix that:

Typo - gogle.com, a wrong TLD, an extra character. Check the spelling.
Expired or misconfigured domain - the owner let it lapse or broke their DNS records. It fails for everyone.
Very recent DNS change - the domain moved and the new records have not propagated yet. Wait; propagation can take up to a day.
Internal-only name - a corporate or local hostname that only resolves on a specific network you are not on.

Confirm with an external check: an online DNS lookup tool, or nslookup against 8.8.8.8 from your machine and, if you can, from a phone on cellular. If the name fails to resolve everywhere, the problem is the domain, and the fix is on the owner’s side - or in your typing - not in your DNS settings.

How this fits the rest of the stack

This error is a lesson in DNS propagation and caching, which is exactly what you meet from the other side when you point a fresh domain at a deployed app and it does not resolve yet. Knowing that records propagate on a TTL, and that caches lag, turns a scary red page into a predictable wait. The RunxBuild hosting calculator lays out the service, database, storage, and bandwidth as separate line items, and the RunxBuild dashboard is where the team watches deploys, logs, and restarts as they happen.

Useful related references:

FAQ

What does DNS address could not be found mean?

It means your browser asked a DNS server to resolve the domain name into an IP address and got no answer, so it cannot load the site. Usually it is a stale DNS cache or a failing resolver rather than the site being down. Flushing DNS and switching resolvers fixes most cases.

How do I fix DNS address could not be found in Chrome?

Flush your DNS cache (ipconfig /flushdns on Windows) and Chrome’s own cache at chrome://net-internals/#dns, then switch to a public resolver like 1.1.1.1. Also check Chrome’s Secure DNS setting under Privacy and security, which can make one browser fail where others work.

Why does a site fail in Chrome but work in another browser?

Most likely Chrome’s Secure DNS (DNS-over-HTTPS) is pointed at a resolver that cannot answer the name, while the other browser follows the OS resolver. Toggle Use secure DNS under Chrome’s Privacy and security settings, or switch its provider, to fix it.

How do I know if the problem is my computer or the website?

Test other sites and run nslookup example.com 8.8.8.8. If only one site fails and it does not resolve against a public resolver either, the problem is the domain - a typo, an expired registration, or unpropagated records. If many sites fail, your DNS setup is the issue.

Can a recently changed domain cause this error?

Yes. If a domain just moved to new DNS records, they may not have propagated to your resolver yet, so the name fails to resolve temporarily. Propagation can take up to a day. Flushing your cache helps once the new records reach your resolver.