DNS_PROBE_FINISHED_NXDOMAIN means Chrome asked a DNS server “what’s the IP address for this domain?” and got back NXDOMAIN — “no such domain exists.” Either the domain genuinely doesn’t exist, or something in the DNS resolution chain is broken. Since you’re presumably visiting a site that does exist, it’s the latter. We go deeper on the whole subject in our Complete Guide to Fixing Windows, Browser, and Software Errors.
The good news: this is almost always fixable in a few minutes. Three causes cover the majority of cases:
- Stale DNS cache — Windows remembered a bad or outdated DNS result. Run
ipconfig /flushdnsin Command Prompt and try again. - ISP’s DNS server has an issue — Switch to Cloudflare (1.1.1.1) or Google (8.8.8.8) as your DNS resolver.
- The site actually is unreachable — Try it on a phone or different network to confirm the site is up.
Try these three before reading any further. They resolve most NXDOMAIN errors without needing anything else.
What the Error Actually Means
Every website you visit requires a DNS lookup — Chrome asks “what IP address should I send this request to?” When this lookup returns NXDOMAIN, Chrome gets a definitive answer that the domain doesn’t exist according to the queried DNS server. It doesn’t mean the website is down; it means the domain couldn’t be resolved.
This distinction is important: a DNS failure produces NXDOMAIN even for domains that absolutely exist. google.com, microsoft.com, any real website — they can all show NXDOMAIN if the DNS resolution chain is broken locally.
Fix 1: Flush the DNS Cache
Windows caches DNS responses to speed up repeat visits. When a cached response becomes wrong — because the site changed its DNS records, because the ISP’s DNS returned incorrect data, or because the cache itself became corrupted — subsequent visits use the wrong cached data. Flushing the cache forces fresh lookups for every domain.
Open Command Prompt (search “cmd” → right-click → Run as administrator) and run:
ipconfig /flushdnsYou’ll see “Successfully flushed the DNS Resolver Cache.” Close and reopen Chrome, then test. This takes 30 seconds and is the most common fix for sudden NXDOMAIN errors on sites that were working recently.
Fix 2: Switch DNS Servers
Your ISP’s DNS server is the one queried by default. ISP DNS servers occasionally have outages, return incorrect data for specific domains, or are deliberately configured to block certain content. Switching to a public DNS resolver bypasses your ISP’s DNS entirely.
Settings → Network and internet → your active connection type → DNS server assignment → Edit → Manual → enable IPv4:
- Preferred DNS: 1.1.1.1 (Cloudflare)
- Alternate DNS: 8.8.8.8 (Google)
Save and test immediately. If NXDOMAIN errors disappear, the ISP’s DNS was the problem. Many people leave these settings in place permanently — public DNS servers are reliable, fast, and don’t inject search redirects when domains fail to resolve.
Fix 3: Chrome’s Own DNS Configuration
Chrome has a built-in DNS-over-HTTPS (DoH) resolver that operates independently from Windows’ DNS configuration. When Chrome’s DoH provider is misconfigured, has an outage, or returns incorrect results for specific domains, NXDOMAIN errors appear even if Windows’ DNS is working correctly.
Check Chrome’s DNS settings: chrome://settings/security → scroll to “Use secure DNS” → if a specific provider is set, try switching to a different one or disabling it (“With your current service provider” uses Windows’ DNS configuration). If errors stop after switching Chrome’s DoH provider, Chrome’s independent DNS was returning incorrect results.
Also: chrome://net-internals/#dns → click “Clear host cache” → this clears Chrome’s own internal DNS cache separately from Windows’ cache. Chrome maintains its own cache, and flushing Windows’ cache (Fix 1) doesn’t clear Chrome’s. Both may need flushing for complete resolution.
Fix 4: Check the Hosts File
Windows maintains a hosts file that can override DNS for specific domains by mapping them to specific IP addresses — or to 0.0.0.0, which effectively blocks them. Some privacy tools, ad blockers, parental controls, and VPN clients modify the hosts file. If the domain you’re trying to reach is in the hosts file pointing to 0.0.0.0, NXDOMAIN appears even though DNS is working correctly for everything else.
Open Notepad as administrator → File → Open → navigate to C:WindowsSystem32driversetchosts → change the file filter to “All Files” → open. Any non-comment line (lines not starting with #) containing the domain you’re trying to reach is blocking it. Delete that line → save → test. You can also run type C:WindowsSystem32driversetchosts in Command Prompt to view the file quickly without opening Notepad.
Fix 5: Restart the DNS Client Service
The Windows DNS Client service (dnscache) manages DNS resolution and caching. When it stops or gets stuck — which happens occasionally after crashes or system events — DNS resolution fails for all domains. Restarting the service is faster than a full system restart and often resolves persistent NXDOMAIN errors.
net stop dnscache
net start dnscacheRun from an administrator Command Prompt. After restarting the service, flush the DNS cache (Fix 1) and test. Also check that the service is configured to start automatically: Win + R → services.msc → find “DNS Client” → Properties → Startup type should be “Automatic (Trigger Start).” If it’s set to Manual or Disabled, changing it prevents the service from stopping and causing persistent NXDOMAIN errors.
Fix 6: Network Stack Reset
When the DNS-specific fixes don’t resolve it, a full network stack reset clears the TCP/IP and Winsock configuration that all DNS communication relies on:
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renewRun from an administrator Command Prompt and restart the machine. This resolves NXDOMAIN errors caused by corrupted network stack state left by VPN clients, firewall tools, or previous network changes.
The VPN and DNS Connection
VPN clients often change the DNS server to route queries through the VPN. When the VPN disconnects without properly restoring the original DNS settings, the DNS configuration points to a VPN DNS server that’s no longer reachable — producing NXDOMAIN for all domains because the DNS server can’t be contacted.
Check: disconnect any VPN completely (not just pause — fully disconnect and quit the VPN application) → test whether DNS resolution works. If it does, the VPN was misconfiguring DNS on disconnect. Most VPN applications have a setting for “restore original DNS on disconnect” — check that it’s enabled. For immediate recovery after a VPN disconnect, switching DNS to 1.1.1.1 (Fix 2) bypasses whatever the VPN left behind.
Site-Specific NXDOMAIN vs Universal
NXDOMAIN on just one specific domain while everything else works suggests either: that specific domain genuinely has DNS issues on the provider’s end (check downdetector.com or isitdownrightnow.com to confirm), the domain is blocked by a DNS filter or parental control, or it’s in the hosts file (Fix 4).
NXDOMAIN on all or most domains points at the local DNS configuration — the DNS server is unreachable, DNS client service is stopped, or the DNS cache is corrupted. Fix 1, 2, and 5 address universal failures.
Quick diagnostic: run nslookup google.com in Command Prompt. If it returns Google’s IP addresses, DNS is working and the problem is specific to the site you’re trying to reach. If it returns “can’t find server” or a similar error, DNS resolution itself is broken. If it returns Google’s addresses but from an unexpected DNS server (one you didn’t configure), another application changed your DNS settings.
Our guide on DNS server not responding covers the related scenario where DNS itself is failing rather than returning NXDOMAIN — slightly different symptoms but overlapping fixes. For connection errors in Chrome beyond DNS, our ERR_CONNECTION_RESET guide covers the TCP-layer failures that follow successful DNS resolution. Google’s Chrome network error documentation covers chrome://net-internals/#dns in detail — the DNS event log shows every lookup attempt, the result code, and which server was queried, making it possible to trace exactly what’s happening with problematic domains.
ISP DNS Hijacking
Some ISPs intercept NXDOMAIN responses and redirect them to a search or advertising page rather than returning the genuine “domain not found” result. From Chrome’s perspective, this substituted response doesn’t match expected DNS behaviour, which can trigger NXDOMAIN errors even though the ISP’s servers technically responded. Other ISPs have misconfigured infrastructure that returns NXDOMAIN for valid domains intermittently.
Switching to Cloudflare or Google DNS (Fix 2) bypasses the ISP’s DNS infrastructure entirely and resolves both ISP hijacking and intermittent ISP DNS failures. After switching, if NXDOMAIN errors on specific domains disappear, the ISP’s DNS was the source of the incorrect responses.
DNSSEC Validation Failures
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records so resolvers can verify the authenticity of responses. Some DNS resolvers perform DNSSEC validation and return NXDOMAIN when validation fails — even if the domain exists — because they can’t confirm the DNS record is authentic. This is rare but produces NXDOMAIN for legitimate sites when DNSSEC records are misconfigured at the domain’s DNS provider.
The tell: NXDOMAIN on a specific domain while nslookup domain.com 1.1.1.1 succeeds but nslookup domain.com (using the current configured resolver) fails. This means your configured resolver validates DNSSEC and the domain’s DNSSEC configuration has an error. Temporarily switching to a non-validating resolver confirms this. From a user perspective: switching DNS to 1.1.1.1 (which does DNSSEC validation but handles some misconfigured domains more gracefully) or to 8.8.8.8 (which also validates) may work differently. If switching resolvers makes a specific domain consistently work, report the DNSSEC issue to the site’s administrator — it’s their DNS configuration that needs fixing.
Corporate Network DNS Filtering
On corporate networks, DNS filtering is commonly used to block access to sites categorised as non-work-related, security threats, or policy violations. The corporate DNS server returns NXDOMAIN for blocked domains rather than an IP address. From the user’s perspective, this looks identical to a DNS failure — Chrome shows DNS_PROBE_FINISHED_NXDOMAIN for blocked sites.
The diagnostic: does the same site work on your phone using mobile data (bypassing the corporate network)? If yes, corporate DNS filtering is blocking it. Switching DNS to 1.1.1.1 on a corporate machine typically doesn’t bypass corporate filtering because many corporate networks route all DNS traffic through their own resolvers regardless of what the device is configured to use. This is an IT policy matter rather than a technical failure.
Checking Chrome-Specific DNS Issues
Chrome’s built-in DNS debugging tools provide more information than any external diagnostic:
chrome://net-internals/#dns: shows Chrome’s internal DNS cache. Look up the failing domain in the search box — if a cached NXDOMAIN entry appears, Chrome is serving the failed result from cache rather than trying again. Click “Clear host cache” to force fresh lookups.
chrome://net-internals/#events: click Record → reproduce the NXDOMAIN error → Stop recording → filter for the failing domain. The DNS events show exactly which DNS server was queried, when, and what response was returned. “DNS_TRANSACTION” events with a NXDOMAIN result code confirm DNS is the failure point; events showing no response at all indicate the DNS server is unreachable rather than returning NXDOMAIN.
Antivirus DNS Interception
Some antivirus products install their own DNS resolver that intercepts all DNS queries for malware domain filtering. When this component malfunctions — due to a corrupt definition update, a conflict with another application, or a service crash — all DNS lookups fail with NXDOMAIN-like errors.
The test: temporarily disable the antivirus’s DNS filtering or network protection component (not the full antivirus — specifically any “web filter,” “DNS protection,” “Safe Browsing,” or similar network component). If DNS resolves correctly with that component disabled, the antivirus DNS interceptor is the problem. Updating the antivirus definitions, reinstalling the antivirus, or checking for a Windows 11 compatibility update for the antivirus product typically resolves the DNS interception failure.
TTY and Localhost Misconfiguration
The Windows hosts file includes default entries for localhost (127.0.0.1) and local IPv6 addresses. When these entries are accidentally modified or the file becomes corrupted — sometimes during malware cleanup or manual editing — local DNS resolution can break in ways that cause unexpected NXDOMAIN errors.
The default hosts file on Windows 11 should contain these entries uncommented:
127.0.0.1 localhost
::1 localhostOpen the hosts file as described in Fix 4 and confirm these entries are present and correct. Any other uncommented entries (lines not starting with #) are additions that may be blocking domains. A fresh default hosts file is available from Microsoft’s documentation if the file has been significantly modified — replacing it with the clean default version removes all custom blocks while restoring proper localhost resolution.
One final diagnostic worth knowing: if DNS_PROBE_FINISHED_NXDOMAIN appears for a domain you just registered or for a domain that just had its DNS records changed, the error may be correct — the DNS change hasn’t propagated globally yet. DNS propagation typically takes anywhere from a few minutes to 48 hours depending on the domain’s TTL (Time to Live) settings. During this window, different DNS servers return different results — some showing the old records, some showing the new ones, some returning NXDOMAIN if the old records expired before new ones propagated. Checking the domain’s DNS status through an online propagation checker (dnschecker.org shows results from multiple global DNS servers simultaneously) confirms whether the error is a propagation issue rather than a local configuration problem. Related: How to Fix DNS_PROBE_FINISHED_NXDOMAIN in Chrome.
