DNS_PROBE_FINISHED_NXDOMAIN: what it means and how to fix it

What the error means

NXDOMAIN is a DNS response code, short for non-existent domain. A resolver returns it after walking the chain from the root down to the zone that should hold your hostname and finding nothing there. Chrome prints DNS_PROBE_FINISHED_NXDOMAIN. Firefox says it cannot connect to the server. Safari says it cannot find the server. All three are reporting the same answer.

NXDOMAIN is not the same as a resolver failure, and the difference decides where you look. If your resolver is unreachable or times out, you get a "DNS server not responding" message instead. If the zone answers but is broken, for example a DNSSEC chain that does not validate, you usually get SERVFAIL. NXDOMAIN is a definite answer: the name is not published.

One property of NXDOMAIN matters more than any other during troubleshooting. Negative answers are cached. Under RFC 2308 a resolver caches the "no such name" result for the interval in the zone's SOA record, commonly between 5 and 60 minutes. A domain that started working two minutes ago can still fail on your machine, and no amount of reloading will change that until the cache entry expires or you clear it.

Why it happens

• A typo in the hostname. The most common cause by a wide margin, and the one everyone checks last.
• The domain is not registered, or it expired. An expired domain is usually pulled from the zone within hours of the grace period ending.
• 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 renamed. A missing A or CNAME for www produces NXDOMAIN for www.example.com while the bare domain still works.
• A change has not reached your resolver yet. New records take up to the previous record's TTL to appear everywhere.
• A cached negative answer on your device, in your browser, or on your ISP's resolver.
• A hosts file entry pointing the name somewhere that no longer exists, or a leftover line from an old test.
• VPN, proxy or filtering software answering DNS itself and blocking or failing to resolve the name.
• A hostname that only exists on a private network you are not currently connected to, such as an internal .local or company domain.

How to fix it

Retype the address first, then work outward from your browser to your network. Test after each step rather than doing all of them.

Browser

1. Open the same URL in a private window. If it loads there, an extension or a cookie is involved, not DNS.
2. Clear Chrome's own resolver cache at chrome://net-internals/#dns, then flush the socket pools at chrome://net-internals/#sockets. Chrome keeps a cache separate from the operating system, so an OS flush alone often changes nothing.

Windows

1. Flush the resolver cache: ipconfig /flushdns
2. Renew the network lease, which also picks up DNS servers handed out by DHCP:

   ipconfig /release
   ipconfig /renew

3. Restart the caching service if a flush does not stick:

   net stop dnscache
   net start dnscache

4. Check C:\Windows\System32\drivers\etc\hosts for a line naming the domain and delete it if it is stale.
5. Set a public resolver: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
6. Reset the network stack as a last resort, then reboot: netsh winsock reset

macOS

1. Flush the cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. See which servers are in use: scutil --dns | grep nameserver
3. Point the interface at a public resolver: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Inspect /etc/hosts and remove any line for the domain.

Linux

1. On systemd-resolved: sudo resolvectl flush-caches, then confirm the servers in use with resolvectl status.
2. On dnsmasq: sudo systemctl restart dnsmasq. On nscd: sudo systemctl restart nscd.
3. Read /etc/resolv.conf to see which resolver you are querying, and /etc/hosts for a stale override.
4. 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 consumer routers run a small forwarding resolver with its own cache, and a restart clears it.
2. In the router's admin page, look at the WAN or DHCP DNS servers. If they point at an old internal server or a filtering service, replace them.
3. Test with a phone on mobile data instead of Wi-Fi. If the name resolves there, the fault is inside your network.

If you own the domain

NXDOMAIN on your own site is a publishing problem, and there are only a few places it can come from. Check the registration status and expiry date first. Then confirm the delegation, which is the step people skip:

dig NS example.com +short
dig example.com +trace

An empty NS answer means the parent zone has no delegation, so no resolver can reach your DNS provider no matter what records you have created there. The +trace output shows the referral chain and the exact step where it stops. If the delegation is fine, query your provider's nameserver directly to confirm the record exists in the zone you are editing:

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

When you add a missing record, the old negative answer stays cached elsewhere for as long as the SOA minimum allows, so give it that long before concluding the fix did not work.

Check it from outside

Every fix above changes your own machine. None of them tells you whether the name resolves for anyone else, and that is what you want to know first. Run the query against two public resolvers and compare:

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

nslookup example.com 8.8.8.8

If your default resolver returns nothing and 1.1.1.1 returns an address, the record exists and your resolver is holding a stale negative answer or filtering the name. If every resolver returns nothing, the record is genuinely missing.

Two resolvers still only cover one vantage point, and DNS answers differ by region more often than people expect. Run the DNS query check to resolve the name from checkpoints in several countries at once and read what each one returned. A split result, some locations answering and some not, points at a change still spreading or at one provider's nameserver being unreachable from part of the internet. That reading 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 side. Nothing logs it, because no request ever arrives, and the only sign is a traffic graph that drops. The fix in every case is a lookup that runs on a schedule from somewhere other than your office. HostTracker has been monitoring websites since 2004 and now 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. The other guides in this section are in the fix cluster, and the two closest to this one are DNS server not responding, for when the resolver never answers at all, and how to fix a slow DNS lookup, for when it answers but takes too long about it.