DNS_PROBE_FINISHED_NXDOMAIN and ERR_NAME_NOT_RESOLVED both mean the browser could not turn the hostname into an IP address. Neither tells you why. Chrome’s code shows that the DNS_PROBE_* suffix comes from a second test against google.com, so the fastest diagnosis is to ask DNS about the failing name yourself and read the status it returns.
What Chrome is actually telling you
Chromium’s network stack collapses almost every resolution failure into one code. HostResolver::SquashErrorCode() passes through ERR_NAME_NOT_RESOLVED (-105), ERR_INTERNET_DISCONNECTED (-106) and ERR_DNS_NAME_HTTPS_ONLY, and turns everything else into ERR_NAME_NOT_RESOLVED. That includes a timeout (ERR_DNS_TIMED_OUT, -803), a malformed response and a server failure. The detailed error stays inside Chrome; the page only gets -105.
When a page fails with that code, Chrome may start a DNS probe. The probe does not retry your hostname. DnsProbeRunner looks up google.com (an A query with the cache disabled) twice: once through your current DNS configuration, including Chrome’s secure DNS provider if one is selected, and once through Google Public DNS at 8.8.8.8 and 8.8.4.4. EvaluateResults() then picks a status:
| Code on the page | Heading and summary Chrome uses | What the probe found |
|---|---|---|
DNS_PROBE_FINISHED_NXDOMAIN |
“This site can’t be reached” / “Check if there is a typo in host.” | Your DNS resolved google.com, so Chrome assumes the site’s name doesn’t exist |
DNS_PROBE_FINISHED_BAD_CONFIG |
“This site can’t be reached” / “host’s server IP address could not be found.” | Your DNS failed, Google Public DNS worked |
DNS_PROBE_FINISHED_BAD_SECURE_CONFIG |
Same summary, with a “Check your Secure DNS settings” suggestion | As above, while Chrome is in secure DNS mode |
DNS_PROBE_FINISHED_NO_INTERNET |
“No internet” | Your DNS failed and 8.8.8.8 could not be reached |
ERR_NAME_NOT_RESOLVED |
“This site can’t be reached” / “host’s server IP address could not be found.” | Probe not run, or inconclusive (Google Public DNS answered with errors) |
DNS_PROBE_POSSIBLE, DNS_PROBE_STARTED |
“…DNS address could not be found. Diagnosing the problem.” | The probe result has not reached the page yet |
Three consequences follow from the code:
- NXDOMAIN on the page is an inference. Chrome sets it whenever your resolver can answer for google.com. The site’s name might have returned a real NXDOMAIN, an empty answer, or SERVFAIL from a broken DNSSEC chain; all three end on the “check for a typo” page.
ERR_NAME_NOT_RESOLVEDis the raw code. The renderer restores it when the probe is disabled or inconclusive, so it covers the same set of causes.DNS_PROBE_POSSIBLEis a placeholder. The first version of the error page carries it and is replaced when the probe finishes. If it stays, reload: Chrome reuses a probe result for at most five seconds, so a later reload gets a fresh probe.
Headless Chrome doesn’t show the error page; it logs the raw network error, which makes the underlying code easy to see.
Live capture, 3 October 2026. Chrome 154 loading a nonexistent name under www.and.guide, then _dmarc.google.com, a name that exists but has only a TXT record:
CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
"$CHROME" --headless=new --user-data-dir=./chrome-prof2 --no-first-run \
--dump-dom https://andguide-nx-tlqyxzlt.www.and.guide/ 2>&1 >/dev/null | grep 'Page load failed'
"$CHROME" --headless=new --user-data-dir=./chrome-prof2 --no-first-run \
--dump-dom https://_dmarc.google.com/ 2>&1 >/dev/null | grep 'Page load failed'[1016:100836804:1003/125106.037887:ERROR:components/headless/command_handler/headless_command_handler.cc:403] Page load failed: net::ERR_NAME_NOT_RESOLVED
[1703:100839334:1003/125117.191641:ERROR:components/headless/command_handler/headless_command_handler.cc:403] Page load failed: net::ERR_NAME_NOT_RESOLVEDTwo different DNS answers, one browser error. The next section shows how they differ.
Firefox’s equivalent page uses the title “Hmm. We’re having trouble finding that site.” and the internal error code dnsNotFound, according to its localization files. Like ERR_NAME_NOT_RESOLVED, it doesn’t tell you which DNS answer came back. We could not find Safari’s wording in a primary source, so we don’t quote it here.
The same failures from the command line
dig shows the response code the browser hides. All captures below come from a macOS 26 workstation in South Korea using DiG 9.10.6.
NXDOMAIN: the name does not exist
Random names directly under and.guide don’t fail, because of the wildcard described further down, so we used a random label under www.and.guide.
Live capture, 3 October 2026. The system’s default resolver (our ISP’s), asked for a random name:
dig +nocmd andguide-nx-tlqyxzlt.www.and.guide A;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29573
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;andguide-nx-tlqyxzlt.www.and.guide. IN A
;; AUTHORITY SECTION:
and.guide. 1800 IN SOA frida.ns.cloudflare.com. dns.cloudflare.com. 2416226589 10000 2400 604800 1800
;; Query time: 408 msec
;; SERVER: 210.220.163.82#53(210.220.163.82)
;; WHEN: Sat Oct 03 12:48:44 KST 2026
;; MSG SIZE rcvd: 126status: NXDOMAIN with the zone’s SOA in the authority section means the and.guide zone itself says the name doesn’t exist. The SOA owner tells you which zone answered. If the whole domain is unregistered or mistyped, the SOA comes from the TLD instead:
Live capture, 3 October 2026. A random, unregistered .com name at 1.1.1.1:
$ dig +nocmd @1.1.1.1 andguide-unreg-g0uhmhb8.com A +noall +comments +authority | grep -E 'status:|SOA'
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15393
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1790999369 1800 900 604800 900An SOA for com. means the registry has no delegation for that domain. That points to a typo in the domain, an expired registration, or name servers that were never set, rather than a missing record inside a working zone.
NODATA: the name exists, but has no address
Live capture, 3 October 2026. A name with a TXT record and no A record:
dig +nocmd @1.1.1.1 _dmarc.google.com A
dig +nocmd @1.1.1.1 _dmarc.google.com TXT +short;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50142
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dmarc.google.com. IN A
;; AUTHORITY SECTION:
google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 992226757 900 900 1800 60
;; Query time: 66 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Oct 03 12:48:58 KST 2026
;; MSG SIZE rcvd: 96
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"NOERROR with ANSWER: 0 and an SOA is what RFC 2308 calls NODATA. For a website, this usually means the hostname has some other record (a TXT for verification, an MX) but the A, AAAA or CNAME you meant to add is missing or was created on a different name. Chrome reported it as ERR_NAME_NOT_RESOLVED above, the same as a true NXDOMAIN.
SERVFAIL: the answer failed DNSSEC validation
dnssec-failed.org is a test domain whose DS record deliberately doesn’t match its keys.
Live capture, 3 October 2026. 1.1.1.1 with and without checking disabled, then 8.8.8.8 (trimmed to the header and answer lines):
dig +nocmd @1.1.1.1 dnssec-failed.org A
dig +nocmd @1.1.1.1 dnssec-failed.org A +cd
dig +nocmd @8.8.8.8 dnssec-failed.org A;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19926
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...
; OPT=15: 00 09 6e 6f 20 53 45 50 20 6d 61 74 63 68 69 6e 67 20 74 68 65 20 44 53 20 66 6f 75 6e 64 20 66 6f 72 20 64 6e 73 73 65 63 2d 66 61 69 6c 65 64 2e 6f 72 67 2e ("..no SEP matching the DS found for dnssec-failed.org.")
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51102
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
dnssec-failed.org. 300 IN A 96.99.227.255
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41495
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...
; OPT=15: 00 09 4e 6f 20 44 4e 53 4b 45 59 20 6d 61 74 63 68 65 73 20 44 53 20 52 52 73 20 6f 66 20 64 6e 73 73 65 63 2d 66 61 69 6c 65 64 2e 6f 72 67 ("..No DNSKEY matches DS RRs of dnssec-failed.org")RFC 4035 requires a validating resolver to return SERVFAIL for data that fails validation, unless the query sets the CD (checking disabled) bit. +cd sets it, and the address appears: the record exists and the chain of trust is broken. OPT=15 is an Extended DNS Error (RFC 8914); the leading 00 09 is code 9, “DNSKEY Missing”, followed by each resolver’s own explanation. The DNSSEC guide covers how a DS record gets out of step.
What curl reports
Live capture, 3 October 2026. curl 8.7.1 against the NXDOMAIN name, then against the DNSSEC-broken name using 1.1.1.1 over DNS-over-HTTPS:
$ curl -sS -o /dev/null https://andguide-nx-tlqyxzlt.www.and.guide/; echo "exit=$?"
curl: (6) Could not resolve host: andguide-nx-tlqyxzlt.www.and.guide
exit=6
$ curl -sS -o /dev/null --doh-url https://1.1.1.1/dns-query https://dnssec-failed.org/; echo "exit=$?"
curl: (6) Couldn't resolve host name
exit=6Exit code 6 is CURLE_COULDNT_RESOLVE_HOST in libcurl’s error list. The wording differs between the system-resolver path and the DoH path, but neither says whether the cause was NXDOMAIN, NODATA or SERVFAIL. curl gave the same exit 6 for _dmarc.google.com in a separate run. Use curl to confirm that “it’s DNS”, and dig to find out what kind.
Which resolver your computer is using
dig without @server reads /etc/resolv.conf, while most macOS apps go through the system resolver, which can route different domains to different servers. Check both.
Live capture, 3 October 2026. The first resolver block on our workstation:
$ scutil --dns | head -n 20
DNS configuration
resolver #1
nameserver[0] : 210.220.163.82
nameserver[1] : 219.250.36.130
if_index : 14 (en0)
flags : Request A records
reach : 0x00000002 (Reachable)
resolver #2
domain : local
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300000
...resolver #1 is the default for everything: two ISP resolvers on interface en0. The other blocks handle multicast names such as .local. A VPN or a corporate profile usually adds a resolver block with its own domain line, sending only that domain to an internal server, and that is often why one name fails while everything else works.
Live capture, 3 October 2026. The same lookups through the macOS system resolver:
$ dscacheutil -q host -a name and.guide
name: and.guide
ipv6_address: 2606:4700:310c::ac42:2f0c
ipv6_address: 2606:4700:310c::ac42:2cf4
name: and.guide
ip_address: 172.66.47.12
ip_address: 172.66.44.244
$ dscacheutil -q host -a name andguide-nx-tlqyxzlt.www.and.guide
(exit 0)
$ dscacheutil -q host -a name dnssec-failed.org
name: dnssec-failed.org
ip_address: 96.99.227.255A failed lookup prints nothing at all, with exit status 0, so look for missing output rather than an error. The last result matters most: the system resolver handed back an address for dnssec-failed.org, which 1.1.1.1 and 8.8.8.8 refuse to give.
When resolvers disagree
Live capture, 3 October 2026. The NXDOMAIN name at the default resolver, 1.1.1.1 and 8.8.8.8, seven seconds after the first lookup:
$ dig +nocmd andguide-nx-tlqyxzlt.www.and.guide A +noall +comments +authority | grep -E 'status:|SOA'
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32378
and.guide. 1800 IN SOA frida.ns.cloudflare.com. dns.cloudflare.com. 2416226589 10000 2400 604800 1800
$ dig +nocmd @1.1.1.1 andguide-nx-tlqyxzlt.www.and.guide A +noall +comments +authority | grep -E 'status:|SOA'
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42511
and.guide. 1800 IN SOA frida.ns.cloudflare.com. dns.cloudflare.com. 2416226589 10000 2400 604800 1800
$ dig +nocmd @8.8.8.8 andguide-nx-tlqyxzlt.www.and.guide A +noall +comments +authority | grep -E 'status:|SOA'
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23493
and.guide. 1800 IN SOA frida.ns.cloudflare.com. dns.cloudflare.com. 2416226589 10000 2400 604800 1800All three agree and the zone’s serial matches, so this is a name that genuinely doesn’t exist. For dnssec-failed.org they did not agree.
Live capture, 3 October 2026. The default resolver, asked the same question as the SERVFAIL captures above, one second later:
$ dig +nocmd dnssec-failed.org A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52870
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...
;; ANSWER SECTION:
dnssec-failed.org. 240 IN A 96.99.227.255Our ISP’s resolver does not validate DNSSEC, so it returned the address that both validating resolvers withheld. (The missing ra flag is that resolver’s quirk; it answered regardless.) Here is what a split like this means:
| Pattern | Likely meaning |
|---|---|
| All resolvers NXDOMAIN, same SOA serial | The name really doesn’t exist in the published zone |
Validating resolvers SERVFAIL, others answer, +cd answers |
DNSSEC chain broken for that domain |
| One resolver NXDOMAIN, others answer | That resolver cached NXDOMAIN before the record existed, or it filters the name |
| One resolver answers with an unexpected address | Filtering or a captive portal, or an internal (split-horizon) zone |
The DNS lookup tool shows Cloudflare’s and Google’s answers side by side if you are not at a terminal.
Just-created names and our wildcard
If anything looked up a hostname before you created it, resolvers can keep returning NXDOMAIN after the record goes live. That cached “no” lasts for the lower of the SOA record’s TTL and its last field; both are 1800 seconds in the and.guide SOA above, so up to 30 minutes. The negative caching guide measures this across providers and explains how to launch a name without planting an NXDOMAIN first.
The reverse also happens. and.guide has a wildcard pointing at our self-hosted deployment server for our own apps, so a mistyped name directly under the apex does not produce a DNS error at all.
Live capture, 3 October 2026. A random, never-created name under and.guide at the default resolver:
$ dig +nocmd andguide-typo-079911.and.guide A +noall +comments +answer +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33393
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
andguide-typo-079911.and.guide. 300 IN A 115.68.101.36
$ dig +nocmd andguide-typo-079911.and.guide AAAA +noall +comments +answer +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11752
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; AUTHORITY SECTION:
and.guide. 1800 IN SOA frida.ns.cloudflare.com. dns.cloudflare.com. 2416226589 10000 2400 604800 1800The A query gets the wildcard’s address and the AAAA query gets NODATA. A browser would get past DNS and fail later, at TLS or HTTP, with a different error. If your zone has a wildcard, a typo will never show DNS_PROBE_FINISHED_NXDOMAIN; the wildcard subdomains guide covers that trade-off.
Diagnosis table
| Browser message | Likely layer | First command | Typical fix |
|---|---|---|---|
DNS_PROBE_FINISHED_NXDOMAIN (“Check if there is a typo”) |
The site’s DNS: NXDOMAIN, NODATA or SERVFAIL for this name | dig name A, then the same at @1.1.1.1 |
Fix the typo, add the missing record, wait out the negative TTL, or repair DNSSEC |
ERR_NAME_NOT_RESOLVED |
Same as above, without the probe | dig name A and dscacheutil -q host -a name name |
As above |
DNS_PROBE_FINISHED_BAD_CONFIG |
Your configured resolver, router or VPN | scutil --dns, then dig @<that resolver> google.com |
Reconnect, restart the router, or switch resolvers |
DNS_PROBE_FINISHED_BAD_SECURE_CONFIG |
Chrome’s secure DNS provider | Check Use secure DNS in Chrome’s settings | Choose another provider, or your current service provider |
DNS_PROBE_FINISHED_NO_INTERNET (“No internet”) |
Network path, firewall or captive portal | dig @8.8.8.8 google.com |
Reconnect, sign in to the network, check firewall rules |
DNS_PROBE_POSSIBLE / DNS_PROBE_STARTED |
Probe still running | None | Reload after a few seconds |
| Firefox “Hmm. We’re having trouble finding that site.” | Same as ERR_NAME_NOT_RESOLVED |
dig name A |
As above |
curl: (6) Could not resolve host |
Same as ERR_NAME_NOT_RESOLVED |
dig name A |
As above |
One caution about NO_INTERNET: the probe sends plain DNS to 8.8.8.8. On a network that blocks outside DNS servers, a failing local resolver produces this status even when web traffic would work.
It works on my phone but not my laptop
Two devices on different networks are using different resolvers, and a phone on mobile data may also have different DNS settings. Work from the laptop:
- Compare answers. Run
dig name A(system default),dig @1.1.1.1 name Aanddig @8.8.8.8 name A. If the public resolvers answer and the default doesn’t, the problem is your network’s resolver or a cached NXDOMAIN there. - Check what the OS uses.
scutil --dnson macOS lists the resolvers; look for extra blocks added by a VPN, and disconnect it to test.dscacheutil -q host -a name <host>shows what applications get. - Check Chrome’s own resolver settings. Google’s help documents the path: Settings, Privacy and security, Security, then under “Advanced” the Use secure DNS toggle with your current service provider or another one. In Chrome’s settings code, choosing any provider other than your current one switches Chrome to secure mode, where its lookups go only to that DNS-over-HTTPS provider and bypass the resolvers the OS uses.
digcan then succeed while Chrome fails, or the other way round. - Clear the caches you can reach. In Chrome,
chrome://net-internals/#dnshas a Clear host cache button and a lookup box that resolves through Chrome itself. On macOS, Apple’s archived support article givessudo killall -HUP mDNSResponderfor OS X 10.10.4 and later; we did not run it for this guide. On Windows, Microsoft documentsipconfig /flushdnsfor discarding negative cache entries. - Re-test and wait if needed. If a resolver you can’t flush still holds NXDOMAIN, it expires after the zone’s negative TTL. Testing through another resolver in the meantime confirms the record is live.
If the laptop sits behind a validating resolver and the phone doesn’t, a DNSSEC fault looks exactly like our dnssec-failed.org split: SERVFAIL on one, a working site on the other.
For site owners: why visitors see NXDOMAIN
When reports come from visitors, check from the top of the chain down.
Live capture, 3 October 2026. The .guide registry’s delegation for and.guide, then one of our authoritative servers with recursion off:
$ dig +nocmd @v0n0.nic.guide and.guide NS +norec +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65517
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; AUTHORITY SECTION:
and.guide. 3600 IN NS roan.ns.cloudflare.com.
and.guide. 3600 IN NS frida.ns.cloudflare.com.
$ dig +nocmd @frida.ns.cloudflare.com and.guide A +norec +noall +comments +answer
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43883
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; ANSWER SECTION:
and.guide. 300 IN A 172.66.44.244
and.guide. 300 IN A 172.66.47.12The registry points at the two name servers we expect, and one of them answers with aa for the record. Run the same pair for your domain (dig +short NS <tld> gives the registry’s servers), then work through the failure modes:
- Record missing or on the wrong name. The authoritative server returns NXDOMAIN or NODATA for the exact hostname. Check for the record created as
www.example.com.example.comor added in a different zone. The A record vs CNAME guide covers which type the hostname needs. - Typo in the domain or expired registration. NXDOMAIN carries the TLD’s SOA, as with the unregistered .com name above.
- Delegation broken. The registry lists name servers that don’t answer for the zone, or that belong to a provider you left. Fix the NS records at the registrar.
- DNSSEC broken. Validating resolvers return SERVFAIL and
+cdreturns the record. Remove or correct the DS record at the registrar. - Just created. The authoritative answer is correct and some resolvers still say NXDOMAIN. Wait out the negative TTL from the SOA, and flush the public resolvers that offer a flush page.
Only the last case resolves itself. The first four look identical in a visitor’s browser and keep failing until someone changes DNS.