Introduction

DNS_PROBE_FINISHED_BAD_CONFIG usually means the browser could not get a usable DNS answer because something in the local resolver path, network DNS configuration, or returned record set is broken. Sometimes the root cause is on the user's machine or router. Sometimes it is a real DNS issue on the domain. The fix is to separate local resolver problems from authoritative DNS mistakes.

Symptoms

  • Chrome reports DNS_PROBE_FINISHED_BAD_CONFIG
  • The domain fails on one device or network but works elsewhere
  • Changing networks or DNS resolvers changes the result
  • The error began after router changes, VPN use, DNS edits, or ISP issues
  • Other domains may also fail, or only one specific hostname is affected

Common Causes

  • Local or router DNS settings point to a broken resolver
  • Cached DNS data is stale or corrupted on the client network path
  • The hostname has conflicting or invalid A, AAAA, or CNAME records
  • VPN, proxy, or enterprise resolver policies return unusable answers
  • The ISP or local network injects incorrect DNS responses

Step-by-Step Fix

  1. Check whether the problem affects only one hostname or many domains so you know whether to focus on the site or the local network first.
  2. Test the hostname from another network and with another public resolver to see whether the error follows the device, the network, or the domain.
  3. Inspect the authoritative DNS records for missing, conflicting, or invalid answers that could cause bad-config behavior.
  4. Review local resolver settings on the affected device, router, VPN, or enterprise network for broken or unexpected overrides.
  5. Clear DNS cache only after you have validated what the correct answer should be, so you do not just replace one bad cached value with another.
  6. If IPv6 is enabled, confirm that the AAAA answer is valid and not sending only some clients to a dead path.
  7. Compare successful and failing resolver outputs to spot whether the issue is bad local DNS, stale cache, or a real authoritative zone problem.
  8. Retest from the original failing environment once resolver settings and authoritative records are corrected.
  9. Keep a record of intended DNS provider, resolver policy, and key hostnames so future network changes are easier to validate.