DNS_PROBE_FINISHED_NXDOMAIN: Find the Cause and Fix It

By Rahul S., SEO Strategist at Search Counsel Co. Last updated September 2026.

What DNS_PROBE_FINISHED_NXDOMAIN actually means

DNS translates a hostname such as www.example.com into an address that a device can use. Cloudflare documents DNS_PROBE_FINISHED_NXDOMAIN as a completed DNS lookup whose result says the requested domain does not exist. RFC 2308 calls NXDOMAIN the DNS “Name Error” response.

The browser message does not identify the faulty layer by itself. The negative answer might be correct because the hostname is wrong. It might be stale in a local or recursive cache. It might also reveal a missing record, expired registration or broken nameserver delegation controlled by the website owner.

If this affects Google crawling rather than only a browser, use the wider crawl-error diagnostic workflow. A DNS failure is an access problem. It is not the same as a page that loads but remains outside the index, which belongs in the indexing-problems workflow.

Run this 90-second diagnosis before changing settings

Preserve the evidence first. Record the exact hostname, time, network and browser message. Then run the checks below in order.

1. Check the exact hostname

Confirm the spelling, top-level domain and subdomain. Test both the apex, such as example.com, and the intended host, such as www.example.com. A working apex does not prove that www, shop or another host has a record.

2. Change one variable at a time

Open the same hostname on another device using the same network. Then test on a different network, such as mobile data. This creates a useful split:

• Only one browser fails. Inspect that browser’s secure DNS, extensions and cached state.
• All browsers on one device fail. Inspect the operating system cache, hosts file, VPN and local security controls.
• Every device on one network fails. Inspect the router, configured resolver or network policy.
• Independent networks fail. Move to authoritative DNS and registration checks.

3. Compare resolver answers

Use nslookup on Windows or dig on macOS and Linux. Replace www.example.com with the exact failing hostname.

nslookup www.example.com
nslookup www.example.com 1.1.1.1

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

If the default resolver returns NXDOMAIN but independent resolvers return the expected address, the domain may be healthy while one resolver still holds a negative answer. If all independent resolvers return NXDOMAIN, the website owner should inspect the domain and authoritative DNS.

4. Use a safe control query

RFC 2606 reserves .invalid for names that are guaranteed to be invalid. This makes it useful as a control without inventing a real person’s domain:

dig @1.1.1.1 does-not-exist.invalid A

The expected result is NXDOMAIN. If the control behaves as expected but the real hostname returns an address, DNS resolution is working. If the real hostname also returns NXDOMAIN across independent resolvers, the evidence points toward the domain’s public DNS rather than Chrome alone.

Fix DNS_PROBE_FINISHED_NXDOMAIN on your device

Use this section only when the evidence is local to your browser, device or network. Retest the hostname after each change so you know which action mattered.

Correct the URL and retry outside the original browser

Copy the hostname rather than retyping a long URL. Test in another browser. A browser-only failure points toward browser configuration, an extension or secure DNS behavior rather than the website’s public record.

Flush the Windows DNS client cache

Open Command Prompt and run:

ipconfig /flushdns

Microsoft documents that /flushdns resets the DNS client resolver cache and discards negative cache entries. It does not repair a missing authoritative record. If several independent resolvers still return NXDOMAIN, repeating this command will not fix the domain.

Test a different resolver without assuming it is the permanent fix

Temporarily compare your current resolver with a documented public resolver such as Cloudflare’s 1.1.1.1. Apple documents the path for changing DNS servers under System Settings, Network, the relevant service, Details and DNS. Record the original configuration before editing it.

If a resolver change fixes only your device, investigate the original resolver or network. If the result does not change, restore the original setting and continue. A resolver swap should be a controlled test, not a ritual.

Check the hosts file, VPN and security policy

A local hosts entry can override public DNS. A VPN, managed-device policy, filtering resolver or security product can also change which names resolve. Disconnect a VPN only when your organization permits it, and re-enable protection after the test. Do not disable a firewall or antivirus as a generic first step.

Fix the error when you own the website

If the failure is reproducible across independent networks and resolvers, stop changing browser settings. Work from the registration and authoritative DNS layers downward.

1. Confirm registration and nameserver delegation

Check that the domain is active and that the registrar delegates it to the nameservers you currently manage. A DNS zone can contain perfect records while the parent zone points visitors somewhere else. During a migration, compare the registrar’s nameservers with the DNS provider’s assigned values exactly.

2. Check the precise hostname and record type

Inspect the apex and each active subdomain separately. Cloudflare advises checking expected apex and subdomain records, then confirming that the records point to the correct origin. Typical website records are A, AAAA or CNAME, but the correct value depends on the hosting platform. Do not copy an address from a generic tutorial.

3. Distinguish NXDOMAIN from DNSSEC failure

If diagnostic tools return SERVFAIL rather than NXDOMAIN, inspect delegation, nameserver availability and DNSSEC. Cloudflare documents that stale parent DS records during a nameserver change can make validating resolvers return SERVFAIL. That is a different failure and should not be “fixed” by adding random A records.

4. Account for negative caching

RFC 2308 allows resolvers to cache negative answers. After correcting the record, one resolver may continue returning the earlier NXDOMAIN until its negative-cache TTL expires. Capture the SOA and TTL evidence when possible. Avoid promising that every DNS change takes a fixed 24 or 48 hours.

Verify DNS recovery and protect search visibility

A browser refresh is one useful check, but it does not prove broad recovery. Verify the exact hostname from more than one resolver and network. Confirm that the answer contains the intended record and that the website then reaches its correct HTTPS destination. If HTTPS fails after DNS starts resolving, move to the separate HTTPS and site-security checks.

Use this post-fix checklist

1. Query the apex and required subdomains from the default resolver and at least one independent resolver.
2. Confirm the response is no longer NXDOMAIN and contains the expected A, AAAA or CNAME path.
3. Open the site on a second network and complete one important user action.
4. Check uptime monitoring from more than one region. HTTP-only monitoring cannot run when DNS resolution fails, so enable DNS or domain monitoring where available.
5. For Google crawling, open Search Console’s Crawl Stats report and inspect Host status, DNS resolution and recent crawl responses.
6. Use URL Inspection on an important canonical URL after the host is stable. A successful fetch restores access, but it does not guarantee indexing or rankings.

Google’s Crawl Stats documentation separates DNS resolution, robots.txt availability and server connectivity within Host status. That makes the report useful when the incident may have affected Googlebot, while the Search Console guide provides the wider reporting workflow. For the relationship between crawl, render, index and ranking, use the technical SEO guide.

Record an evidence packet before closing the incident

Save the failing hostname, first observed time, affected networks, resolver outputs, registrar nameservers, changed DNS record, change time, negative-cache TTL if known and the successful retest. This makes the next outage faster to diagnose and prevents a cache flush from receiving credit for an unrelated authoritative fix.

FAQ

The one thing to do next

Run the same hostname through your default resolver and two independent public resolvers. If all three return NXDOMAIN, send the outputs and timestamp to the person who controls the registrar and DNS zone. If DNS or crawl availability failures keep returning, request a technical SEO diagnosis that includes post-fix verification.