DNS_PROBE_FINISHED_NXDOMAIN: what it means and how to fix it

What the error means

NXDOMAIN is DNS response code 3, which RFC 1035 calls a Name Error: an authoritative server stating that the name in the query does not exist. Chrome's label sits one step away from that code. When a page fails to load because its hostname could not be resolved, Chrome runs a short DNS probe. It looks up google.com through your current DNS settings and through Google Public DNS (8.8.8.8 and 8.8.4.4), then names the error after the result:

• Your own DNS resolved google.com: DNS_PROBE_FINISHED_NXDOMAIN. The resolver works, so Chrome assumes the name you asked for does not exist.
• Your DNS failed but Google Public DNS answered: DNS_PROBE_FINISHED_BAD_CONFIG, or DNS_PROBE_FINISHED_BAD_SECURE_CONFIG when Chrome's secure DNS setting names a specific provider.
• Google Public DNS was unreachable as well: DNS_PROBE_FINISHED_NO_INTERNET.
• The probe did not run or was inconclusive: Chrome shows the underlying code, ERR_NAME_NOT_RESOLVED.

So the label is an inference, and two cases mislead. Chrome folds nearly every kind of lookup failure into one internal code, which means a domain whose own nameservers fail or never answer can also be labeled NXDOMAIN, as long as google.com resolved during the probe. And on setups where Chrome cannot test the device's DNS settings directly (Chromium's source names Android as the example), it reports NXDOMAIN whenever Google Public DNS answers, even if the phone's own resolver is the part that failed. Before acting on the label, check what DNS returned with dig, nslookup or Resolve-DnsName.

Other browsers word the same failure differently. Firefox shows "Hmm. We're having trouble finding that site." Safari says it "can't find the server".

Negative answers are cached. Under RFC 2308 a resolver keeps a "no such name" answer for the smaller of two values in the zone's SOA record: the record's own TTL and its MINIMUM field. A record created two minutes ago can still fail on your machine until that cached answer expires or someone clears it, and the cache can sit in several places at once: the operating system, the router and the ISP's resolver. Chrome keeps a host cache of its own on top of those.

DNS_PROBE_FINISHED_NXDOMAIN vs similar errors

Chrome names a failed page load after the first step that broke: the name lookup, the route to the address, then the TCP handshake. The first three errors below never got an IP address to connect to. The last three did and failed further along.

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

Why it happens

• A typo in the hostname. One wrong letter, a missing hyphen or the wrong ending (.co for .com) produces a name nobody published. Rule it out first.
• The domain is not registered, or it expired. An expired domain can keep resolving for a while, often to a registrar's parking page, and stops once it is removed from the zone.
• The domain is on hold. The registry or registrar can set the clientHold or serverHold status, which keeps the domain out of DNS. ICANN lists non-payment, legal disputes and pending deletion as typical reasons. A WHOIS lookup shows the status.
• No nameserver delegation. The domain exists at the registrar but has no NS records pointing at a DNS provider, so the parent zone has nothing to refer a resolver to.
• The record was deleted or never created. A missing record for www produces this error for www.example.com while the bare domain still works. Unless the zone has a matching wildcard, each hostname needs a record of its own.
• A change has not reached your resolver yet. A resolver that cached the old "no such name" answer keeps returning it until the negative-caching time runs out.
• A filtering resolver or ad blocker. Family-safety DNS, network ad blockers and security filters block names by returning NXDOMAIN or a null address, depending on the product.
• Internal names off the internal network. Company hostnames and single-label names like intranet resolve only through the office or VPN DNS server. Off the VPN, the public internet has no such name.
• The device's own resolver failed. On phones in particular, a broken Private DNS setting, a VPN app or the carrier's resolver can produce this label, as described above.

How to fix it on your device

Check the spelling, then work outward from the browser to the network, and retest after each step. Start with Chrome itself, which behaves the same on every platform.

In Chrome

1. Open the address in a private window or another browser. If it loads there, an extension or a cached page is involved, not DNS.
2. Clear Chrome's host cache at chrome://net-internals/#dns (Clear host cache), then flush open connections at chrome://net-internals/#sockets (Flush socket pools). Chrome's cache is separate from the operating system's, so an OS flush alone may change nothing.
3. Check secure DNS at chrome://settings/security (Use secure DNS). On Android it is in Chrome's Settings, Privacy and security. In the default automatic mode Chrome falls back to ordinary DNS when a secure lookup fails; with a specific provider selected it does not, so a provider that is down or filtering breaks lookups. Turn the setting off briefly to test.

Windows

1. Flush the resolver cache: ipconfig /flushdns
2. See what Windows itself gets, then ask a public resolver directly, in PowerShell:

   Resolve-DnsName www.example.com
   Resolve-DnsName www.example.com -Server 1.1.1.1
   Get-DnsClientServerAddress -AddressFamily IPv4

   "DNS name does not exist" from both servers means the name is missing. An answer from 1.1.1.1 alone means your configured DNS server is the problem, and the last command shows which server that is for each adapter.
3. Renew the DHCP lease, which also reloads the DNS servers your router hands out:

   ipconfig /release
   ipconfig /renew

4. Change the DNS server. In Windows 11 it is under Settings, Network & internet, your Wi-Fi or Ethernet connection, DNS server assignment, Edit. From an elevated prompt: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
5. On a corporate VPN, list its name resolution rules with Get-DnsClientNrptPolicy. A rule that sends a domain to a DNS server you cannot reach makes every name under that domain fail.

Android

1. Switch between Wi-Fi and mobile data. If the site loads on one, the DNS server behind the other connection is the problem.
2. Turn airplane mode on and off. Android keeps a DNS cache for each network connection, so reconnecting starts with an empty one.
3. Check Private DNS in Settings, Network & internet, Private DNS (search the settings for "Private DNS" if your phone's menus differ). The choices are Off, Automatic, or a provider hostname. If a hostname is set, choose Automatic and retest: a filtering provider may block the name, and one that cannot be reached breaks every lookup on the phone.
4. Pause ad-blocking, firewall and VPN apps. Many of them filter DNS through a local VPN connection and answer blocked names themselves.

ChromeOS

1. Select the time at the bottom right, select the Wi-Fi network, select your network's name, then Network. Under "Name servers", choose Google name servers, or Custom name servers to enter your own.
2. Turn Wi-Fi off and on to reconnect, then clear Chrome's host cache as described above.
3. On a school or work Chromebook, the administrator usually sets DNS and filtering, and you may not be able to change them. If only some sites fail, ask the administrator.

macOS and Linux

• macOS: flush the cache with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, list the servers in use with scutil --dns | grep nameserver, and set a public resolver with sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1.
• Linux with systemd-resolved: sudo resolvectl flush-caches, then resolvectl query www.example.com to test and resolvectl status to see the servers per interface. With NetworkManager, change the resolver on the connection itself:

  nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
  nmcli con up "Wired connection 1"

Router

1. Power cycle the router. Most home routers run a small forwarding resolver with its own cache, and a restart clears it.
2. In the router's admin page, check the DNS servers under WAN or DHCP settings. If they point at an old internal server or a filtering service, replace them.

If you own the domain

NXDOMAIN on your own site means the name is not published where resolvers look. Work down the chain: registration, delegation, then the record.

whois example.com | grep -i -E "status|expir"
dig NS example.com +short
dig example.com +trace

A clientHold or serverHold status, or an expiry date in the past, explains the error on its own. An empty NS answer means the parent zone has no delegation, so no resolver can reach your DNS provider, whatever records you created there. The +trace output shows the referral chain and the step where it stops. If the delegation is fine, ask your provider's nameserver directly, without recursion, to confirm the record exists in the zone that is live:

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

An NXDOMAIN response carries the zone's SOA record in its authority section, and the TTL on that line is how long resolvers will cache the negative answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41377
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.  300  IN  SOA  ns1.example-dns.net. hostmaster.example.com. 2026101301 7200 3600 1209600 300

In BIND zone file format, a zone that covers the bare domain, www and a hosted subdomain looks like this. Every hostname visitors use needs a record of its own or a matching wildcard, and a CNAME has to point at a name that resolves:

$ORIGIN example.com.
$TTL 3600
@     IN  SOA  ns1.example-dns.net. hostmaster.example.com. (
               2026101301 ; serial
               7200       ; refresh
               3600       ; retry
               1209600    ; expire
               300 )      ; minimum, the negative-caching time
@     IN  NS     ns1.example-dns.net.
@     IN  NS     ns2.example-dns.net.
@     IN  A      203.0.113.10
www   IN  CNAME  example.com.
shop  IN  CNAME  shops.example-host.net.

Mistakes that produce NXDOMAIN on an otherwise healthy domain:

• Editing records at a DNS provider the domain is no longer delegated to. After a move, the old provider's dashboard still accepts changes that no resolver will see. Compare the output of dig NS example.com +short with the provider you are editing.
• Adding www but not the bare domain, or the reverse.
• A CNAME pointing at a hostname that was removed, such as a deleted hosting or storage endpoint. The lookup follows the CNAME and gets NXDOMAIN for the target.

After you add a missing record, the old negative answer stays cached elsewhere for up to the negative-caching time, so wait that long before deciding the fix did not work. DNSSEC failures look different on the wire: validating resolvers return SERVFAIL, not NXDOMAIN, even though Chrome may still show this label.

How it looks from the outside

Every fix in the device section changes only your own machine. First find out whether the name resolves for anyone else. Compare your default resolver with two public ones:

dig www.example.com +short
dig @1.1.1.1 www.example.com +short
dig @8.8.8.8 www.example.com +short

nslookup www.example.com 8.8.8.8

If your resolver returns nothing and 1.1.1.1 returns an address, the record exists and your side is holding a stale negative answer or filtering the name. If every resolver returns nothing, the problem is on the domain's side, and the status line in full dig output says which kind: NXDOMAIN means the name is not published, SERVFAIL means the domain's nameservers or DNSSEC are broken.

Two public resolvers still give you one vantage point. The DNS query check resolves the name from many locations at once and shows what each one returned. The patterns read like this:

• No address from any location. The name is not published, or its nameservers fail for everyone. Check registration, delegation and the record, in that order.
• An address from some locations, none from others. A recent change while old negative answers age out, or nameservers that serve different versions of the zone, which happens after a DNS provider move when the old servers are still listed at the registrar.
• 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, a filter, a VPN or a cache on your side.

Reading those answers over time is DNS propagation, which has its own guide on how to check DNS propagation.

Catching a name that stops resolving

A record that disappears leaves no trace on your server: no request arrives, so nothing is logged, and the first sign is a traffic graph that drops. A lookup that runs on a schedule from outside your network catches it instead. HostTracker has been monitoring websites since 2004 and runs checks from 300+ checkpoints in 158 cities, alerting by email, SMS, voice call, Slack, Telegram and more when a name stops resolving or starts answering with the wrong address. Related problems are in the fix guides, including how to fix a slow DNS lookup for names that resolve but take too long.

Frequently asked questions

Is DNS_PROBE_FINISHED_NXDOMAIN a problem with my device or with the website?

It can be either. Test the name against a public resolver or from another network. If it fails everywhere, the domain's DNS or registration is the problem and only the owner can fix it. If it works elsewhere, the cause is your device, a browser setting, your router or your ISP's resolver.

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

The two connections use different DNS servers. The one behind your Wi-Fi, usually the router forwarding to your ISP, is returning a stale or filtered answer. Restart the router or set a public resolver on the Wi-Fi connection.

How long until a new record stops showing this error?

Up to the negative-caching time from the zone's SOA record, counted from the moment each resolver last got "no such name" for it. You can read that time from the SOA line in the authority section of an NXDOMAIN response. A resolver that never asked before sees the new record right away.

Does the error mean the domain expired?

Not by itself. A WHOIS lookup shows the expiry date and the status codes. An expiry date in the past, or a clientHold or serverHold status, explains the error; an active registration points at the DNS records or at your own resolver.

Why do I see this error on every site, not just one?

Then your device's own DNS is the likely failure, and the label is misleading. On Android this matches the case described above, where Chrome may not be able to test the phone's own settings, so check Private DNS and any VPN or ad-blocking app first. On a computer, check the DNS servers set on the network adapter and on the router.

Sources and further reading

• Chromium source: DNS probe service, the logic that chooses between the DNS_PROBE_FINISHED_* labels.
• RFC 1035, Domain names: implementation and specification (response code 3, Name Error).
• RFC 2308, Negative caching of DNS queries.
• ICANN: EPP status codes, including clientHold and serverHold.