The error is Chrome's wrapper around a plain DNS response code. Chrome asked for the hostname, the resolver answered NXDOMAIN — "this name does not exist" — and Chrome ran its own probe to confirm DNS is otherwise working before showing the page. The probe part matters: it means Chrome believes your DNS is functional in general and that *this specific name* came back missing. That is a narrow, useful signal.
# Bypass every local cache — ask a public resolver directly
dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A
# Read the status line: NXDOMAIN means the name really is absent
# NOERROR with an ANSWER section means your machine is the problemServer-side: the record genuinely does not exist
If public resolvers also return NXDOMAIN, nothing on the visitor's device will help. Work through the zone in this order — each step rules out a whole class of cause.
- Is the domain registered and not expired? An expired domain has its delegation pulled and every name under it returns NXDOMAIN. Check registration and expiry with the WHOIS Lookup or the Domain Age Checker.
- Is the delegation present? Run the NS Record Lookup. If no nameservers come back, the registry is not publishing a delegation — the domain is expired, suspended, or was never fully configured.
- Does the record exist in the authoritative zone? Query a nameserver from that NS set directly:
dig @ns1.provider.com www.example.com A. If the authoritative server says NXDOMAIN, the record is not there, regardless of what your DNS panel shows. - Did you edit the right zone? The single most common cause. If the NS records name a provider you are not editing, your changes went into an inactive zone. This is covered in detail in Why Is My DNS Not Propagating?.
- Is the host field wrong? Entering
www.example.comin a panel that already appends the domain createswww.example.com.example.com. Look at the fully qualified name the panel displays after saving, not what you typed. - Is `www` missing while the apex works? These are separate names.
example.comresolving does not createwww.example.com— that needs its own A record or CNAME. See CNAME vs A Record. - Is the record newly created? Then negative caching applies: resolvers that asked before it existed keep returning NXDOMAIN until the SOA minimum expires. Read the value with the SOA Record Lookup.
One distinction is worth internalising. If the SOA in the NXDOMAIN response belongs to the TLD (com. and a registry contact), the delegation itself is missing — a registration problem. If the SOA belongs to your own zone, your nameservers are answering and stating the name is absent — a record problem. dig shows the SOA in the authority section, and SERVFAIL vs NXDOMAIN explains how to read it.
Client-side: the record exists but this device cannot see it
If dig @1.1.1.1 returns the address and Chrome still shows the error, the record is fine and something between the browser and the internet is not. Chrome, the operating system, the local network, and any VPN each maintain their own view of DNS, and any one of them can be stale or filtered.
| Layer | Symptom | Fix |
|---|---|---|
| Chrome host cache | Chrome fails; dig and other browsers work. | Clear the host cache at chrome://net-internals/#dns, then flush socket pools at chrome://net-internals/#sockets. |
| OS resolver cache | Every browser fails; dig @1.1.1.1 works. | Flush the OS cache (commands below). |
| Chrome secure DNS (DoH) | Only Chrome fails, including after a cache clear. | Chrome can resolve through its own DoH provider, bypassing the OS. Toggle "Use secure DNS" in Chrome's Security settings and retest. |
| Router / gateway resolver | All devices on the network fail; cellular works. | Reboot the router, or set the device to use 1.1.1.1 / 8.8.8.8 directly. |
| ISP or filtering resolver | Public resolvers work, the configured one returns NXDOMAIN. | Content filtering or DNS-based blocking. Switch resolvers to confirm, then take it up with whoever runs the filter. |
| VPN or split DNS | Fails only while connected. | The VPN pushes its own resolvers, which may not know public names or may serve a different internal zone. Disconnect and retest. |
| hosts file | One machine fails persistently, immune to every flush. | Check /etc/hosts (macOS/Linux) or C:\Windows\System32\drivers\etc\hosts for a stale entry. |
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows (Command Prompt or PowerShell, as Administrator)
ipconfig /flushdns
ipconfig /release && ipconfig /renew
# Linux with systemd-resolved
sudo resolvectl flush-caches
resolvectl status # shows which resolvers are actually in use
# Linux running nscd or dnsmasq
sudo systemctl restart nscd
sudo systemctl restart dnsmasqchrome://net-internals/#sockets as well, or restart the browser entirely.Cases that look like NXDOMAIN but are not
- A typo in the address bar. Chrome offers a search suggestion for obvious typos but not always. Read the hostname in the error message character by character before doing anything else.
- An internal-only hostname. Names that resolve only through a corporate VPN or split-horizon DNS return NXDOMAIN on the public internet by design. Nothing is broken.
- A different error code.
DNS_PROBE_FINISHED_NO_INTERNETmeans connectivity, not a missing name.ERR_NAME_NOT_RESOLVEDis a closely related failure but not necessarily an authoritative NXDOMAIN.ERR_CONNECTION_REFUSEDmeans DNS worked fine and the server declined the connection — check with the Port Checker or Ping Test. - A certificate error mistaken for DNS. If the page loads far enough to warn about the certificate, DNS succeeded. See Fix ERR_CERT_DATE_INVALID and the SSL Certificate Checker.
- A DNSSEC failure. That returns SERVFAIL, not NXDOMAIN, and Chrome usually shows a different message — but the two get conflated in bug reports. Test with the DNSSEC Checker.
Once the record is in place, confirm it has reached resolvers worldwide with the DNS Propagation Checker, and compare resolvers directly with DNS Compare if reports are inconsistent.