When Chrome throws DNS_PROBE_FINISHED_BAD_CONFIG, the browser is telling you it asked the resolver for an address and the resolver configuration on that machine or network was broken enough that the query never produced a usable answer. The site is probably fine. Your DNS path is not.
Work the problem in this order: confirm the domain resolves publicly, flush the local resolver cache, verify the adapter’s DNS server addresses, then rule out VPN, proxy, and security software. Most tickets close somewhere in the first two steps, and the remaining ones almost always trace back to a static DNS entry someone set months ago and forgot about.
At PacketTools we use these same diagnostics in production networks to verify VPNs and analyze routing, so the sequence below is the one that survives contact with real endpoints. You will finish with a repeatable triage path you can hand to a junior tech, plus a way to prove whether the fault sits on the device, the network, or the domain itself.
What the Error Indicates During DNS Resolution
This error fires when the stub resolver on the device cannot complete a DNS lookup because of the configuration it was handed, whether that came from DHCP, a static entry, a VPN client, or a router. The domain name may exist perfectly well in public DNS while the client still fails, which is what separates this code from a genuine missing-record failure.
How a Domain Name Becomes an IP Address
Chrome hands the domain name to the operating system’s resolver. The resolver checks its cache, then queries the configured DNS server, which walks the domain name system hierarchy until an authoritative name server returns an A record with an IPv4 address (or AAAA for IPv6).
Only after the browser holds that IP address can it open a TCP connection to the web server. Break any link in that chain, the DNS server addresses, the route to them, or the cached entry, and the URL never gets a destination.
Why a Bad Configuration Differs From NXDOMAIN
NXDOMAIN means an authoritative server answered and said the non-existent domain has no record. Bad config means the answer never came back cleanly at all.
| Signal | Bad Config | NXDOMAIN |
|---|---|---|
| Who answered | No usable reply from resolver | Authoritative server replied |
| Domain exists | Usually yes | No |
| Fault location | Device or network | DNS records |
| Fixed by changing resolver | Frequently | No |
That distinction matters when you triage. Bad config points to misconfigured settings at the device or network level, so stop editing zone files and start checking adapters.
How the Message Appears Across Browsers and Operating Systems
Chrome shows the literal string. Firefox reports “We’re having trouble finding that site,” Safari says it cannot find the server, and Opera renders the same Chromium text since it shares the engine.
The underlying failure is identical on Windows, macOS, Linux, Android, and iPhone. Only the wording changes, so never assume a browser-specific bug when a second browser on the same endpoint fails too.
Is the Failure on the Device, Network, or Domain?
Isolate the fault domain before you touch a single setting: test more than one hostname, test a second network connection, and query both the configured resolver and a public one. Three minutes of scoping saves you from resetting a network stack that was never broken.
Test Multiple Domains and a Second Network Connection
Load three unrelated domains. If every one fails, the resolver path is broken; if only one fails, look at that domain’s DNS records or a filtering policy.
Then move the endpoint to a phone hotspot. Working over cellular and failing on the office Wi-Fi or Ethernet points at the router, the VPN, or the internet service provider’s resolvers. Failing on both keeps the fault on the device.
Query the Configured Resolver and a Known Public Resolver
Open a command prompt or terminal and query directly, bypassing the browser entirely:
nslookup packettools.com
nslookup packettools.com 8.8.8.8On Linux or macOS, dig @1.1.1.1 packettools.com +short does the same job. When the second query returns an address and the first times out, the configured DNS server is the problem, not the domain. That pattern also produces the classic DNS server not responding symptom on the same box.
Keep the public DNS servers handy: Google DNS at 8.8.8.8 and 8.8.4.4, Cloudflare at 1.1.1.1 and 1.0.0.1.
Use PacketTools to Check Public DNS Records Independently
Local tools inherit local breakage. Run the lookup from outside your network with the DNS propagation checker to see what resolvers worldwide return for the domain.
If public results come back clean and consistent, the domain’s DNS records are fine and your remaining work is entirely client-side. PacketTools logs no IPs, queries, or test data, which makes it safe to run against internal-facing hostnames during a live incident.
Restore Basic Network Connectivity First
Before editing DNS settings, confirm the endpoint holds a valid lease and can reach its gateway. A device with a 169.254.x.x address or a missing default route will throw DNS errors that have nothing to do with DNS configuration.
Restart the Modem, Router, and Affected Endpoint
Power off the modem and wi-fi router, wait sixty seconds, bring the modem up first and let it sync before powering the router. Reboot the endpoint last.
This clears the router’s own DNS forwarder cache and forces a fresh DHCP lease. One recurring report on Microsoft Q&A describes the error hitting three home PCs every other day, fixed each time by a router reset, which is the signature of a failing forwarder rather than a client fault.
Confirm DHCP Has Supplied a Valid Address and Gateway
Check the assigned address, then renew it:
ipconfig /all
ipconfig /release
ipconfig /renewOn macOS, use System Settings > Network > Details > TCP/IP > Renew DHCP Lease. On Linux, sudo dhclient -r && sudo dhclient on the relevant network adapter.
Verify three things in the output: a routable IPv4 address, a default gateway on the same subnet, and DNS server entries that make sense for the network. Ping the gateway to confirm layer 3 works before blaming name resolution.
Identify Router-Wide Failures and Managed-Network Limits
When every device on the segment fails identically, stop working the endpoint. Log into the router settings and inspect the WAN DNS entries, any DNS filtering feature, and the firewall rules that might block outbound port 53.
On corporate or guest networks you often cannot change these. Document what resolves and hand it to whoever owns the network configuration, since local changes get overwritten by policy anyway.
Repair DNS Cache and Adapter Configuration
This is where the fix lands for most cases: clear the poisoned cache, put the DNS server addresses back to something known-good, and confirm the adapter bindings were not quietly changed by an installer or an old VPN client.
Flush the Local Resolver Cache on Windows, macOS, and Linux
Run these from an elevated command prompt or terminal:
- Windows:
ipconfig /flushdns - macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Ubuntu / systemd Linux:
sudo systemd-resolve --flush-caches(orresolvectl flush-cacheson newer releases)
Chrome keeps its own cache too. Visit chrome://net-internals/#dns and clear the host cache, then chrome://net-internals/#sockets and flush socket pools. Skipping the browser-level flush is why a correct fix sometimes appears not to work.
Set DNS Back to DHCP or Use a Trusted Public DNS Server
Open the adapter properties, select Internet Protocol Version 4 (TCP/IPv4), and set DNS to obtain automatically. If the network’s own resolver is the failure, hardcode a public DNS server instead:
| Provider | Primary | Secondary |
|---|---|---|
| Google DNS | 8.8.8.8 | 8.8.4.4 |
| Cloudflare | 1.1.1.1 | 1.0.0.1 |
From the command line: netsh interface ip set dns name="Ethernet" static 8.8.8.8 then netsh interface ip add dns name="Ethernet" 8.8.4.4 index=2.
A DNS misconfiguration left behind by uninstalled security software shows up here constantly, usually as a loopback or 10.x address nothing answers on.
Check TCP/IPv4, Static Addressing, and Adapter Bindings
Look for a static IPv4 address that no longer matches the subnet, a stale secondary DNS entry, or IPv6 handing back an unreachable resolver while IPv4 looks correct.
Disable any leftover virtual adapters from VPN clients or hypervisors, and confirm the physical adapter sits above them in the binding order. Two adapters supplying conflicting DNS server addresses produce intermittent failures that survive every cache flush you throw at them.
Reset the Windows Network Stack Only When Needed
Treat this as the last configuration step, because it wipes custom routes, static entries, and Winsock LSPs:
netsh winsock reset
netsh int ip reset
ipconfig /flushdnsReboot afterward. Windows 11’s Network Reset under Settings > Network & Internet > Advanced does the same thing plus reinstalls network adapters, and it removes VPN clients, so document what needs reinstalling first.
Remove Software and Browser Interference
When the adapter is clean and public lookups resolve, something running on the endpoint is intercepting or rewriting DNS. VPN clients, proxy settings, and antivirus web-filtering modules are the usual culprits, in that order.
Clear Stale Browser Data and Test Without Extensions
Open Chrome’s clear browsing data dialog (Ctrl+Shift+Delete), select cached images, files, and cookies for all time, and clear. Delete temporary files while you are there.
Then launch an incognito window, which disables browser extensions by default. Resolution working in incognito and failing in a normal window narrows it to an extension, frequently an ad blocker or a security add-on with its own DNS-over-HTTPS setting. An outdated browser build is worth ruling out too: check chrome://settings/help and let any pending update install.
Disconnect VPN and Review Proxy Settings
Disconnect the VPN completely and retest. Many clients push their own resolvers and leave them behind after an ungraceful disconnect, so verify with ipconfig /all that the DNS entries reverted.
Check Windows Settings > Network & Internet > Proxy and clear any automatic configuration script or manual proxy server the reader did not deliberately set. Malware and old corporate images both leave proxy entries that silently break name resolution.
Check Firewall and Security Software DNS Controls
Temporarily disable third-party antivirus web protection and retest, then re-enable it. Windows Defender Firewall rarely blocks outbound 53, though custom rules from a previous admin do.
Suites with DNS filtering or “secure DNS” features redirect queries to their own resolvers. When the vendor’s resolver is unreachable, every lookup fails while the rest of the connection stays up. Whitelisting or turning off that single module usually restores service without removing the product.
Update Network Drivers When the Adapter Is Unstable
Open Device Manager, expand Network adapters, and check the driver date against the vendor’s current release. Pull the driver from the NIC or laptop manufacturer, since Windows Update often ships a generic build that drops connections under load.
Flapping links produce sporadic DNS failures that look like configuration problems. If the adapter logs disconnects in Event Viewer, fix the driver before spending more time on resolver settings, and review the broader network troubleshooting path for anything physical.
A Repeatable Path to Working DNS
The sequence holds regardless of platform: scope the failure with a DNS lookup against a second resolver, confirm the public DNS records look correct, restore connectivity, flush caches, then fix the network configuration on the adapter. Software interference comes last because it is the least common cause and the most disruptive to test.
Keep a note of what you changed on each endpoint. Static DNS entries and leftover VPN adapters are the two findings that repeat most across tickets, and both are trivial to spot once you know the order to check them in.
When the endpoint is clean and the problem persists across every device on the segment, the fault sits with the router configuration or the internet service provider’s DNS server, and that is a call to make rather than a setting to change. Run the domain through the PacketTools network tools before you make that call so you have propagation and record data in hand.
Leave a Reply