What does DNS_PROBE_FINISHED_NXDOMAIN mean?

The lookup for the name failed, and Chrome's follow-up check found that DNS itself works on your connection. So the failure is about that one name: the DNS answer was NXDOMAIN, 'no such domain'. Chrome uses the same page for some related failures, so check the real status with dig or nslookup.

Is it my computer or the website?

Open the site on your phone with Wi-Fi off, or look the name up with a public resolver such as 1.1.1.1. If it resolves there, the domain is fine and the cause is your device, VPN or network DNS. If it fails everywhere, only the domain owner can fix it.

I just added the record and still get NXDOMAIN. Why?

Something looked the name up before the record existed, and that 'does not exist' answer is cached for the negative TTL from your zone's SOA record. Query your authoritative nameserver directly to confirm the record is there, then wait out that time.

Can an expired domain cause NXDOMAIN?

Yes, once the registry pulls it from the zone, which happens with clientHold, serverHold and later stages of expiry. Earlier in the expiry process many registrars point the domain at a parking page instead, so you may see ads rather than an error.

DNS_PROBE_FINISHED_NXDOMAIN: What It Means and How to Fix It

What the error is telling you

Chrome shows “This site can’t be reached”, then “name’s server IP address could not be found”, then the code DNS_PROBE_FINISHED_NXDOMAIN. The code has two parts.

DNS_PROBE_FINISHED means the lookup failed, so Chrome ran a quick probe to see whether DNS works at all on this connection. NXDOMAIN is the outcome: DNS is working, so the problem is the name. NXDOMAIN is the DNS response code for “no such domain”: a server that is authoritative for that part of the namespace says this name doesn’t exist, with any record type.

That’s the theory. In practice Chrome shows the same page for a few neighbours: a name that exists but has no address record, and some lookups that failed with SERVFAIL. Treat the error page as “the name didn’t resolve” and let dig or nslookup tell you which failure it really was. Firefox says “Hmm. We’re having trouble finding that site” for the same situation, Safari “Safari Can’t Find the Server”.

If you’re just visiting the site

Thirty seconds sorts out whose problem it is.

Read the address again. A missing letter, .co for .com, or a hyphen in the wrong place produces exactly this error, and it’s the most common cause by far.
Open the same address on your phone with Wi-Fi turned off. Mobile data uses your carrier’s DNS, a completely different path.
Ask a public resolver directly. On any OS: nslookup example.com 1.1.1.1. Or use the DNS lookup, which asks several public resolvers from outside your network.

If the name resolves from your phone or from public resolvers, the domain is fine and the cause is on your side. Skip to Causes on your own device or network.

If it fails everywhere, the domain is broken or gone, and nothing on your computer will change that. If it’s a site you depend on, tell the owner; an expired domain is a common reason.

Read the status line, not the browser

$ dig www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

On Windows, Resolve-DnsName www.example.com -Server 1.1.1.1 says “DNS name does not exist” for NXDOMAIN, and nslookup says “Non-existent domain”.

The status is what you diagnose from:

Status	What it means
`NXDOMAIN`	The name doesn’t exist at all. No records of any type, no wildcard covering it.
`NOERROR` with `ANSWER: 0`	The name exists but has no record of the type you asked for (often called NODATA). Typical: the apex has MX and TXT records but no A.
`SERVFAIL`	The resolver couldn’t get a trustworthy answer: unreachable or misconfigured nameservers, or a DNSSEC validation failure.
`REFUSED`	The server you asked won’t answer for this name. Usually you asked a nameserver that doesn’t host the zone.

Only the first one is a true NXDOMAIN. The other three can still put the same error page in front of a visitor, and each has a different fix.

Who said “doesn’t exist”? Look at the SOA

An NXDOMAIN answer carries the SOA record of the zone that issued it, in the authority section. That one line tells you where to look.

If the SOA belongs to your own domain, as in the example above, the delegation works: the registry sent the resolver to your nameservers, and your zone said it has no www. The problem is inside your zone.

If the SOA belongs to the top-level domain, the registry itself has no delegation for the domain:

$ dig nosuch-example-name-4821.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5121

;; AUTHORITY SECTION:
com.   900   IN   SOA   a.gtld-servers.net. nstld.verisign-grs.com. 1759823456 1800 900 604800 86400

That means the domain was never registered, is misspelled, or has been removed from the TLD zone (expired, on hold, deleted). Nothing you do in your DNS provider’s dashboard will help, because resolvers never reach it.

dig +trace shows the whole path from the root and where it stops:

$ dig +trace www.example.com
.                 518400  IN  NS  a.root-servers.net.
...
com.              172800  IN  NS  a.gtld-servers.net.
...
example.com.      172800  IN  NS  ns1.dns-provider.example.
example.com.      172800  IN  NS  ns2.dns-provider.example.
...
example.com.      300     IN  SOA ns1.dns-provider.example. hostmaster.example.com. 2026100701 7200 3600 1209600 300
;; Received 105 bytes from 192.0.2.53#53(ns1.dns-provider.example) in 24 ms

If the trace never gets an example.com. NS referral from the .com servers, the problem is at the registry. If it gets the referral but the nameservers time out or refuse, the delegation is broken. If your own nameserver answers with its SOA, the record is missing.

Causes when you run the domain

The domain isn’t in the TLD zone: hold, expiry, deletion

Look up the domain’s registry status with the RDAP lookup, or whois example.com | grep -i status. The statuses that take a domain out of DNS:

clientHold: set by the registrar. Usual reasons are an unpaid renewal, an abuse complaint, or a registrant email address that was never verified; ICANN requires registrars to verify contact details for gTLD domains and suspend the domain if that doesn’t happen. Check the inbox of the registrant contact for a verification mail.
serverHold: set by the registry, typically for legal, abuse or policy reasons. Only the registrar can tell you why.
redemptionPeriod and pendingDelete: the domain expired and passed the registrar’s grace period. It is out of the zone; in redemption you can usually still restore it, at a fee.
inactive: no nameservers are set at the registry at all.

Under the EPP rules registries follow, a domain on hold is not published in the zone, so every name under it returns NXDOMAIN from the TLD servers. A domain that has only just expired often behaves differently: many registrars point it at their own parking nameservers, and visitors get a page full of ads instead of an error.

Fix it at the registrar: renew, verify the contact, or resolve whatever the hold is for. Once the registry republishes the delegation, resolvers that cached the TLD’s NXDOMAIN keep it for the TLD’s negative-cache time. That’s the lower of the SOA record’s TTL and its last field; for .com in the example above it works out to 900 seconds. Check your own TLD with dig com SOA (or kr, net, and so on).

You edited the zone that isn’t live

The most common reason a record “exists” but resolves to nothing: you added it in one dashboard while the domain’s nameservers point at another provider. Registrars usually offer a DNS panel of their own, and it does nothing once the domain is delegated to Cloudflare, Route 53 or anyone else.

dig +short NS example.com

If the names that come back don’t belong to the provider where you made the change, that’s it. Either make the change at the provider those nameservers belong to, or change the nameservers. The nameserver mismatch guide covers comparing the registry’s view with each nameserver’s.

The record exists under a different name

Some DNS panels append the zone name to whatever you type. Enter www.example.com in the name field and you’ve created www.example.com.example.com. Test the doubled name:

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

If that returns your IP, delete the record and recreate it with just www (or @ for the apex). The zone-file version of the same mistake is a missing trailing dot: shop CNAME stores.example.net without the final . becomes stores.example.net.example.com..

Also check you created the name people actually type. A site set up only at www.example.com gives NXDOMAIN for example.com if the apex has no records at all, and NODATA if the apex has only MX and TXT. Create both, and redirect one to the other.

A CNAME points at something that was deleted

$ dig shop.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18822

;; ANSWER SECTION:
shop.example.com.   3600   IN   CNAME   example-store.old-platform.example.

;; AUTHORITY SECTION:
old-platform.example.   900   IN   SOA   ns.old-platform.example. dns.old-platform.example. 2026090101 3600 600 604800 900

Your record is there; the name it points to isn’t. The response carries NXDOMAIN for the chain as a whole, and the SOA is from the target’s zone, not yours. This happens when a store, app or storage bucket on a hosted platform is deleted but the CNAME stays behind.

Point the CNAME at the right target or delete it. Don’t leave it: if someone else can create a resource with that name on the same platform, they get your subdomain. That’s subdomain takeover, and a dangling CNAME is its usual starting point.

The record is new and NXDOMAIN was cached

You create newapp.example.com, it works on your laptop, and a colleague’s machine insists the name doesn’t exist. Someone or something, often a monitoring check or a certificate request, looked it up before the record existed, and the resolver cached the NXDOMAIN.

Confirm the record is published by asking your nameserver directly, bypassing caches:

dig @ns1.dns-provider.example newapp.example.com A +norecurse +noall +answer

If the authoritative server answers, the record is fine and you’re waiting for negative caches to expire. How long is in your SOA; the DNS propagation guide and the TTL guide explain the calculation. Cloudflare and Google have pages to purge a name from 1.1.1.1 and 8.8.8.8 respectively, which helps users of those two resolvers. Next time, create the record before pointing anything at the name.

The delegation is broken (usually SERVFAIL, same error page)

After registering a domain or changing nameservers, the servers listed at the registry may not actually serve the zone: the zone was never created at the new provider, the nameserver names are mistyped, or the old provider deleted the zone too early. Those servers answer REFUSED or not at all, and resolvers return SERVFAIL.

A DNSSEC mismatch, typically a DS record at the registry left over from a previous provider, also gives SERVFAIL, but only on validating resolvers such as 1.1.1.1 and 8.8.8.8. Compare dig @1.1.1.1 example.com A with the same query plus +cd (checking disabled): if +cd gets an answer and the normal query doesn’t, it’s DNSSEC. Both cases are covered in the nameserver mismatch guide.

The name only exists inside a network

Names like intranet.corp.example.com often exist only on an internal DNS server. From outside, or with the VPN disconnected, they’re NXDOMAIN by design. If a name works in the office and not at home, that’s the first thing to check.

Causes on your own device or network

If public resolvers find the name and your machine doesn’t, the domain is fine. In rough order of likelihood:

A cached negative answer. Your OS or browser cached the NXDOMAIN, maybe from a moment the site really was down. Flush them:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches

Chrome keeps its own cache: chrome://net-internals/#dns, “Clear host cache”.

A VPN or corporate DNS. A VPN typically pushes its own resolver. Internal names only resolve while you’re connected; some VPN resolvers handle public names badly, or keep being used after a sloppy disconnect. Disconnect fully, flush, and try again.

Chrome’s secure DNS. In Chrome’s settings, under Privacy and security → Security, “Use secure DNS” can send lookups to a provider you picked instead of your network’s resolver. Internal and split-horizon names then come back NXDOMAIN in Chrome while nslookup on the same machine works. Switch it back to your current service provider and compare.

A filtering resolver. Some resolvers answer blocked names with NXDOMAIN: Quad9 for domains on its threat lists, and Pi-hole, AdGuard Home, NextDNS, parental controls or ISP filtering, depending on configuration. If nslookup example.com 1.1.1.1 works and nslookup example.com (your default) says “Non-existent domain”, your resolver is blocking or broken. Check its block log, or change the DNS server in your network settings.

The hosts file, in reverse. A hosts entry can’t produce NXDOMAIN; it makes a name resolve. But it explains the opposite complaint, “it works for me and visitors get NXDOMAIN”: someone added the name to /etc/hosts or C:\Windows\System32\drivers\etc\hosts while testing a migration and forgot. Remove the line before you trust your own browser again.

After the fix

How quickly NXDOMAIN goes away depends on where it was cached:

A record you added or fixed in your zone: up to your zone’s negative-cache time for resolvers that cached the NXDOMAIN.
A domain back in the TLD zone (hold lifted, new registration, restored from redemption): up to the TLD’s negative-cache time, then normal resolution.
A nameserver change: resolvers that cached the old delegation keep it for the delegation TTL; for .com that’s 48 hours. The propagation guide covers the details.

The propagation check asks six large public resolvers at once, so you can watch them switch from NXDOMAIN to an answer. The DNS lookup shows the records and their TTLs once they’re there.

ERR_NAME_NOT_RESOLVED: Chrome’s general “couldn’t resolve” error, of which NXDOMAIN is one case.
Nameserver mismatch: when the registry and your DNS provider disagree.
DNS propagation delay: why some resolvers still have the old answer.
Domain expiry and hold statuses: what each RDAP status means for a domain.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.