DNS_PROBE_FINISHED_NXDOMAIN: what it means

You type an address, press Enter, and Chrome shows an error page with the code DNS_PROBE_FINISHED_NXDOMAIN. No page loaded, and the browser never even tried to connect to a server.

The error comes from an earlier step: turning the name into an IP. Knowing that saves time, because changing application code or restarting the server won't fix it. The defect is in the name, the DNS record or a cache. The page looks roughly like this (the exact text varies with Chrome's version and language):

This site can't be reached
example.com's server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

What is NXDOMAIN?#

NXDOMAIN (non-existent domain) is DNS response code 3, "Name Error". It means the server walked the DNS hierarchy and concluded the name does not exist. Because names form a tree, RFC 8020 defines that if foo.example does not exist, no name below it exists either (bar.foo.example, for instance).

Don't confuse it with these other answers:

• NXDOMAIN: the name does not exist.
• NODATA (a NOERROR response with no records): the name exists but has no record of the requested type, such as a name with an A record but no AAAA.
• SERVFAIL: the server failed to answer. That is a different DNS failure, with a different browser error code.

In practice, DNS_PROBE_FINISHED_NXDOMAIN is how Chrome displays the "that name does not exist" answer. Other browsers show their own messages for the same problem.

What are the most common causes?#

The most frequent causes, in the order worth checking them:

1. Typo or nonexistent domain. exmaple.com, a .com where it should be .co.uk, or a domain that was never registered.
2. Expired domain. The registration lapsed and the domain may have left the TLD's zone.
3. Missing DNS record. The domain exists, but the subdomain you visit (app.example.com, www.example.com) has no A, AAAA or CNAME record.
4. DNS edited at the wrong provider. You created the record in the dashboard where you bought the domain, but the nameservers point to another provider. The right record sits somewhere nobody queries.
5. Negative cache. Someone looked the name up before the record existed, and a resolver stored "does not exist".
6. Faulty local cache or DNS. System cache, the hosts file, your router's or ISP's DNS, a VPN or a blocking extension.

How do you diagnose it with dig or nslookup?#

Before changing settings, find out which layer produces the error. Query the name on two public resolvers:

dig example.com A @8.8.8.8
dig example.com A @1.1.1.1

In the output, look at the status field in the header:

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

On Windows without dig:

nslookup example.com 8.8.8.8

A Non-existent domain response is the same as NXDOMAIN. Now read the result:

If you got NXDOMAIN, query the authoritative servers directly, since they hold the reference answer:

dig NS example.com +short
dig @ns1.dns-provider.example example.com A +short

If the authoritative server returns the IP and the public resolvers do not, the problem is caching. If it also says NXDOMAIN, the record does not exist in that zone.

How do you fix each cause?#

Typo and nonexistent domain. Check the spelling and the TLD. Look the domain up in your registrar's WHOIS or RDAP tool to see whether it is registered and when it expires.

Expired domain. Renew it at the registrar. Once renewed, the domain returns to the TLD's zone, but caches may take a while to forget the negative answer.

Missing record. In your DNS provider's dashboard, create a record for the exact name you visit. For an IP, that is an A (IPv4) or AAAA (IPv6) record. To point at another name, a CNAME. The guide to DNS records explains each type.

Wrong DNS provider. Run dig NS example.com +short and see which nameservers answer. Edit the records at that provider, or change the nameservers at the registrar to the provider where you created the records. When switching, keep identical records on both sides during the transition.

Negative cache. RFC 2308 defines the cache time of a "does not exist" answer as the lesser of the zone's SOA MINIMUM field and the SOA record's own TTL. In practice, a name you just created can keep failing for minutes or hours for anyone who already queried it. More in DNS propagation.

How do you flush the cache and change DNS on your computer?#

If the public resolvers return the IP and only your machine fails:

ipconfig /flushdns

On Windows, according to Microsoft's documentation, this command also discards negative cache entries. On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux with systemd-resolved:

sudo resolvectl flush-caches

Then restart the browser or test in a private window. After that, rule out local suspects:

• The hosts file. An old line that points the domain at a bad address breaks resolution. On Windows it is at C:\Windows\System32\drivers\etc\hosts; on macOS and Linux, at /etc/hosts.
• VPNs and blocking extensions. Turn them off for a minute and test again.
• A different network. Try mobile data. If it loads, your router's or ISP's DNS is the culprit.
• Changing the DNS server. In your network settings, use Google's public resolvers (8.8.8.8 and 8.8.4.4, documented on the Google Public DNS page) or Cloudflare's (1.1.1.1 and 1.0.0.1, in the Cloudflare docs). Configure at least two addresses.

Switching resolvers only helps when your provider's DNS is faulty. If the domain truly does not exist, every resolver gives the same answer.

How do you avoid the error on your own site?#

• Turn on automatic renewal for the domain and keep the registrar's contact email current.
• Note which provider hosts the DNS zone and check with dig NS before creating records.
• Create the record before you share the address, so no resolver stores a "does not exist".
• Before changing the IP or provider, lower the TTL to 300 seconds well ahead of time.
• Test the exact subdomain (www and the bare domain are different names and need their own records).

For a step-by-step guide to connecting a domain to an application, see how to point a domain to your app. For a refresher on the basics, read what DNS is.

How to do this on Square Cloud#

Every web application on Square Cloud gets a *.squareweb.app subdomain with HTTPS, on every plan. If that address loads and your own domain returns NXDOMAIN, the problem is the domain's DNS, not the application.

Custom domains are available starting with the Standard plan. In the dashboard you see the DNS records you need and create them at your registrar or DNS provider. The dashboard shows the validation status in real time, so you can tell when the records have been found. TLS is issued automatically.

The domain stays registered in your name at your registrar. Square Cloud is neither a registrar nor a DNS provider, so an NXDOMAIN usually means the record is missing, was created at the wrong provider, or a cache still holds the old answer. See the full flow in domains on Square Cloud.