Browser Secure DNS Can Bypass NextDNS and Pi-hole: How to Check and Fix It

The feature is DNS-over-HTTPS (DoH), which Chrome and Edge call "Secure DNS." It isn't a bug or a hidden exploit. It does what it was built to do. But for anyone running NextDNS, Pi-hole-style blocking, parental controls or an enterprise DNS filter, it matters.

The experiment: one toggle, two outcomes​

MakeUseOf writer Afam Onyimadu added a soccer site, goal.com, to his NextDNS deny list. After that, Windows resolved the domain to 0.0.0.0, and the NextDNS logs showed the blocked requests as expected.

Next he opened Chrome's security settings, set Secure DNS to use an external provider (Google Public DNS) and reloaded the page. It loaded normally. NextDNS had no record of the request: no blocked entry and no allowed entry.

He repeated the test in Edge and Firefox and got the same result:

When he turned Secure DNS off, or set the provider back to the operating system default, the block returned immediately.

Two caveats before anyone panics:

• This is one person's test. The report doesn't give browser versions, the Windows build or detailed NextDNS settings. Treat it as a clear demonstration of how DoH works, not a formal audit.
• Only three browsers were tested. The headline says "every major browser," but the evidence covers Chrome, Edge and Firefox. Brave uses the same Chromium engine and also calls the feature Secure DNS, but it wasn't tested, and sharing an engine doesn't prove it behaves the same way.

In short: if a browser uses its own external DoH resolver, a filter that only watches the system DNS path never sees the lookup.

Why it happens​

With Secure DNS off, the path is simple: browser → Windows DNS client → your configured resolver (NextDNS in this case) → blocked.

With Secure DNS pointed at an outside provider, the path becomes: browser → encrypted HTTPS connection to the external resolver → answer. Windows' resolver never gets the question, so your filter never gets to apply its rules.

Mozilla says this openly. Its Firefox support documentation notes that some people and organizations rely on DNS to block malware or enforce parental controls, and that "when enabled, DoH bypasses your local DNS resolver and defeats these special policies."

The reason for the design is privacy. Encrypted DNS stops your ISP, or whoever runs the coffee-shop Wi-Fi, from reading your lookups in plain text. The trade-off is that someone else still sees them. Mozilla notes that when DoH is enabled, Firefox by default sends queries to DNS servers that are operated by a trusted partner, which has the ability to see users' queries. You're choosing who gets to see your lookups, not making them invisible.

Security vendors have noticed. CleanBrowsing, a DNS filtering provider, warns that when DoH is active, DNS queries are encrypted and sent directly to a public resolver — circumventing the organization's filtered DNS and rendering content controls ineffective. Sophos goes further in a knowledge base article, saying application-level DoH attempts to bypass many security features. Keep in mind that both companies sell filtering, so this problem directly affects their products.

It's also worth being clear about what this doesn't bypass. It gets around DNS-layer filtering only. Firewall rules, proxies, endpoint protection and IP-based blocks can still stop the connection, as Onyimadu also points out.

How each browser handles it​

Chrome​

Google's help documentation says "By default, Secure DNS in Chrome is turned on in automatic mode." If a secure lookup fails in automatic mode, Chrome retries without encryption. Choosing a custom provider changes that: When you select a custom provider, Chrome won't default to unencrypted mode.

This distinction matters. Onyimadu's bypass came from manually choosing Google Public DNS, not from Chrome's default. Sophos, for example, says Chrome uses the Operating System information for DNS in the setups it supports. That fits a default configuration better than one where someone has picked an outside provider.

Google also notes that Chrome's Secure DNS can't be used on managed devices or when parental controls are on. Hold on to that for the enterprise section below.

Microsoft Edge​

Edge works much like Chrome: automatic mode tries DoH first and falls back to regular DNS if something goes wrong, while choosing a specific provider removes that fallback. Microsoft's DnsOverHttpsMode policy documentation lists three modes. "Off" disables DoH. "Automatic" tries DoH first and falls back to insecure queries on error. "Secure" sends only DoH queries and fails to resolve if the secure resolver can't be reached. The policy is supported on Edge 83 and later for Windows and macOS.

Firefox​

Firefox is the most careful of the three. Mozilla documents several protection levels. In the default mode, Firefox checks the network for signs that DoH would cause problems, and when those checks flag something, it will disable DoH for the remainder of the network session, unless the user has enabled the "DoH always" preference. One of those checks looks for filtering: Firefox will resolve canary domains of certain known DNS providers to detect content filtering.

There's a catch. Mozilla states that if a user has chosen to manually enable DoH, the signal from the network will be ignored and the user's preference will be honored. Onyimadu kept DoH active by choosing his own resolver, and he says Max Protection goes further by refusing to fall back silently to system DNS when the secure connection fails. Default Protection is careful around filtered networks. Once a user deliberately picks a stricter level and a specific provider, those safeguards largely stop applying.

The two-minute check: who answered your browser?​

You don't need the exact same setup to test this:

1. Open your filter's live query log. NextDNS, AdGuard Home, Pi-hole and most enterprise filters have one.
2. Pick a domain you haven't visited recently in that browser. This step matters, because a cached answer won't create a new query and can make a working setup look broken.
3. Load it and watch the log:
   • Shows up as blocked: the filter saw the lookup and applied the rule.
   • Shows up as allowed: the filter saw the lookup and let it through.
   • Never shows up while the page loads: strong evidence that the browser used a different resolver. It isn't absolute proof, since caching can cause the same thing.
4. Check that browser's Secure DNS / DoH setting. In Chrome and Edge it's under Privacy and security → Security, under "Advanced" → Use secure DNS. In Firefox, look for DNS over HTTPS in the Privacy & Security settings.
5. Decide what you actually want:
   • You want filtering: turn Secure DNS off, or choose the OS default / "current service provider" option.
   • You want filtering and encryption: point the browser's Secure DNS at your filter's own DoH endpoint, if it has one. CleanBrowsing says using a filter's own DoH endpoint maintains filtering, and that the problem only appears with unfiltered resolvers.
   • You care more about privacy than filtering: leave it as it is, knowing your blocklist doesn't cover that browser.

For IT admins: don't rely on users noticing a toggle​

In managed environments, per-user settings aren't a control you can count on. Some practical options:

• Edge: set DnsOverHttpsMode through Group Policy under Administrative Templates/Microsoft Edge (MSEdge.admx), or through the registry at SOFTWARE\Policies\Microsoft\Edge with the REG_SZ value DnsOverHttpsMode set to off. Microsoft notes that on managed devices where the policy isn't configured, DoH queries aren't sent. Setting the policy explicitly still removes any doubt.
• Firefox: Mozilla lets organizations turn off default DoH via enterprise policies and a canary domain lookup. Having your resolver return NXDOMAIN for the canary domain is a common approach. DNSFilter, for example, says it answers Firefox's detection domain, use-application-dns.net, that way. Remember that the canary signal only affects Firefox's default mode.
• Defense in depth: for browsers or apps you can't manage centrally, DNSFilter suggests you block access to known DoH providers at the firewall, using community-maintained lists of DoH servers.

In short: for Edge and Firefox, use policy (Group Policy or Firefox enterprise policies) to control DoH, and add firewall blocks for anything you can't manage.

Bottom line​

A DNS filter only controls lookups that actually reach it. Browser DoH was built to protect privacy, and it does, but it can also route lookups around the filter you set up. The fix isn't to rebuild your network. Check the query log to find out which resolver is answering your browser, then set its DoH option to match what you want: privacy, filtering, or encrypted lookups through your filter's own DoH endpoint.