DNS_PROBE_FINISHED_NXDOMAIN error explained

What the message means

DNS_PROBE_FINISHED_NXDOMAIN is Chrome's way of saying the DNS lookup for the domain returned "NXDOMAIN", the DNS answer for "this name does not exist". The browser probes the resolver, the resolver walks the tree, and the authoritative server for the domain says there is no such name. It is different from a timeout (the answer never came back) and from ERR_NAME_NOT_RESOLVED in an edge case that hides the same root cause. NXDOMAIN is final: at this moment, the domain has no record.

One user or everyone

The first question is always "does it fail for everyone or just this device?". That splits the cause in half:

With a browser open, test in a private window first (add-ons can block DNS). Then move off the device: nslookup example.com 8.8.8.8 from a terminal, or load the site over mobile data. If the domain resolves with a public resolver, the server-side record is fine and the problem is your path only; if it fails everywhere, the domain itself has no record.

Check the registrar layer first when it fails everywhere

NXDOMAIN for the whole world usually starts at the registration, not the web server:

• The domain expired. The registrar pulls the zone; every resolver then gets NXDOMAIN. The expired-domain rescue covers the recovery and the redemption pricing that shows up.
• The nameservers at the registrar point at nothing. The domain's NS records in the registry name servers that do not host the zone. For a domain that was just moved to a new DNS host, this is the repeat of a half-finished copy: the DNS zone copy article explains the cutover sequence that avoids it.
• The zone was deleted on the new nameserver instead of created. A domain whose console shows "no zone" for the domain resolves to nothing no matter what the web host does.

Check with a line that shows the truth:

dig example.com +trace        # walk root to authoritative
whois example.com             # see nameservers + status
dig example.com @1.1.1.1      # bypass your local resolver

dig +trace shows the resolving path to the authoritative server (the last hop names the exact zone problem), whois shows the registration status, and dig @1.1.1.1 bypasses whatever resolver your machine currently uses.

Check the subdomain and your own records

If the apex resolves but a subdomain fails, the check is smaller:

• A typo or a missing record: the subdomain needs its own A, CNAME, or similar in the zone. The record types reference lists what each one means.
• A DNS provider that only hosts the apex: some hosts only create the apex record and leave www and subdomains uncreated, so the subdomain returns NXDOMAIN until someone adds it.
• A record created in the wrong zone: an A added to the staging host instead of the live host. Searching the zone with the provider's search box finds this fast.

For your own device, the fix list is: flush the OS resolver (ipconfig /flushdns, sudo dscacheutil -flushcache), reboot the browser, or change the network DNS to a public resolver. Chrome's own chrome://net-internals/#dns shows the failed name entry that the cache holds.

Prevention

• Buy domains with auto-renewal enabled and alert email read.
• After a registrar/DNS move, verify whois, NS records and one A record online before announcing the move.
• Keep the same hostname in the DNS console and the web host's own DNS console aligned; stale "sources of truth" create phantom NXDOMAINs that one panel shows and the other does not.
• If you change nameservers, lower the TTL before the change so a broken half-zone is only cached for minutes, not hours. The propagation article covers the timing side of that window.

The usually adjacent errors have their own checks and are worth ruling out before this one: a host-level lookup with "cannot find host" belongs to the server-configured-resolver path (dns server not responding), and an expired registration has its own page too (domain expired, site down).