DNS_PROBE_FINISHED_NXDOMAIN: Name Does Not Exist

The browser reports DNS_PROBE_FINISHED_NXDOMAIN when the DNS lookup for a hostname returned NXDOMAIN. NXDOMAIN is a definitive answer from a DNS resolver: the queried name does not exist in the DNS. It is not a timeout, not a refused connection, and not a failure to reach the resolver. The resolver was reached and it replied that the name is absent. The machine was trying to turn a hostname into an IP address so it could open a TCP connection; the lookup ended with a negative answer, so no connection was attempted.

That distinction determines the repair. A timeout points at the network path to the resolver. NXDOMAIN points at the name itself, at the answer the resolver is giving, or at something between the application and the resolver that is rewriting the answer. The mechanism of recursive resolution, caching, and negative answers is covered on the DNS resolution page; this page deals with the symptom and the checks that separate its causes.

What NXDOMAIN actually means

A DNS resolver returns NXDOMAIN when it has walked the delegation chain and found no record for the name. The answer is authoritative in intent: the parent zone does not delegate the name, or the zone that should hold it says it is not there. Resolvers cache that negative answer for a period set by the SOA record of the zone, so a name that was created recently can still return NXDOMAIN from a cache that stored the negative answer before the name existed.

The browser displays DNS_PROBE_FINISHED_NXDOMAIN for any lookup that ends this way. It does not distinguish between a typo, a lapsed domain, a filtering resolver, and a stale cache. Those are the cases to separate.

Causes and how to tell them apart

Confirm the answer with a second resolver

The first check is whether the name exists at all. Query a public resolver directly, bypassing whatever the machine is configured to use.

nslookup example.com 1.1.1.1

The output shows the resolver used, then a Name and Address block if the name exists. On Windows a missing name shows as a line ending in can't find example.com: Non-existent domain, which is the NXDOMAIN answer. If the name resolves here but not in the browser, the fault is local: cache, hosts file, or the configured resolver.

nslookup example.com 8.8.8.8

A second public resolver separates a single resolver’s bad cache from a name that is genuinely absent. If both public resolvers return NXDOMAIN, the name does not exist in the public DNS and nothing on the machine will change that.

nslookup example.com

With no server argument, nslookup uses the resolver configured on the adapter. Comparing this output with the public-resolver output shows whether the local resolver is the one giving the negative answer.

ipconfig /all

The output lists the DNS servers in use per adapter. A resolver address belonging to a router, a VPN, or a filtering service explains an NXDOMAIN that public resolvers do not return.

Clear the local caches

A negative answer is cached like any other. If the name was created or corrected after this machine last asked, the cache still holds the old answer until its TTL expires.

ipconfig /flushdns

The output confirms the DNS resolver cache was flushed. This clears the operating system cache only. The browser keeps its own DNS cache, and on some builds it must be cleared separately: in Chrome, the internal chrome://net-internals/#dns page has a clear-cache control. The exact location of that control changes between versions; the browser’s own documentation is the reference for the current build.

After flushing both, retry the name. If it resolves, the cause was a stale negative answer and the repair is complete. If it still returns NXDOMAIN, the cache was not the cause.

Check the hosts file and local overrides

The hosts file maps names to addresses before DNS is consulted. An entry that points a name at a dead address, or a malformed line, produces failures that look like DNS faults. The file is at C:\Windows\System32\drivers\etc\hosts. Open it in a text editor and read it; do not delete lines without knowing what put them there, because some are placed by security software or by the user deliberately. Comment out a suspect line by prefixing it with #, save, flush the DNS cache, and retry. Restore the line if it was not the cause.

Determine whether a filter is answering

A DNS filtering service, an ad-blocking resolver, or a parental-control layer can return NXDOMAIN deliberately for names in a blocked category. The answer is indistinguishable from a genuine absence at the protocol level. The test is to query a resolver that does not filter, such as 1.1.1.1 or 8.8.8.8, for the same name. If the unfiltered resolver returns an address and the configured resolver returns NXDOMAIN, a filter is the cause. The remedy is a policy change in the filtering service, not a repair on the machine. The owner of that service controls it; where the filter is supplied by an employer or a school, the machine’s user cannot override it.

VPN and corporate resolvers

A VPN client often replaces the adapter’s DNS servers with resolvers inside the corporate network. Those resolvers may be configured to answer only for internal names and to refuse or fail public ones, or to forward public queries through a path that is blocked. The symptom is that internal names resolve and public names return NXDOMAIN, or the reverse after the tunnel drops. Disconnecting the VPN and repeating the nslookup comparison identifies this case. The fix belongs to the VPN profile or the corporate DNS configuration, and where the employer owns the resolver, the user cannot change the answer.

When the site’s own DNS is broken

If public resolvers disagree with each other, or if a public resolver returns NXDOMAIN for a name that the site’s operator believes is published, the fault is in the site’s DNS. Common causes are an expired registration, a deleted record, a zone that was not saved after an edit, or a nameserver change that has not propagated. Nothing on the client changes this. The check is the public-resolver query above; the report goes to the site’s operator. A registration lapse is visible in a WHOIS lookup for the domain, which shows the expiry date and the registrar.

What people get wrong

The natural mistake is to treat DNS_PROBE_FINISHED_NXDOMAIN as a network outage and start resetting adapters, reinstalling drivers, or rebooting the router. That is understandable: the browser presents it as a connectivity failure, and the same screen appears for timeouts and unreachable hosts. But NXDOMAIN is an answer, not a silence. The network carried the query and the reply. Resetting the adapter discards a working configuration and changes nothing about the answer.

A second common error is to flush the DNS cache and stop there. Flushing helps only when a stale negative answer is the cause, and that case is identified by the name having resolved before. If the name has never resolved from this machine, the cache holds nothing relevant and the flush is wasted effort.

A third is to assume a filter is a fault. Where a resolver is configured to block a category, NXDOMAIN is the intended behaviour. The machine is doing what its policy says; the question is whether the policy is correct, and that question belongs to whoever set it.