Ferrite.The DNS you chose isn’t always the DNS you get.
Your browser can silently ignore your DNS settings — including parental controls, ad-blocking resolvers, and your VPN’s DNS. This is by design, it’s been true for years, and almost nobody notices it happening.
What’s actually happening
When you set a DNS server — in Windows, your router, or a VPN client — every application is supposed to use it to turn domain names into IP addresses. That’s the whole point of choosing a resolver: a parental-control DNS blocks the sites you configured it to block, an ad-blocking DNS strips trackers before your browser ever loads them, and a VPN’s DNS keeps your lookups inside the tunnel.
Chrome, Firefox, and Edge don’t reliably respect that. All three ship with DNS-over-HTTPS (DoH) — encrypted DNS carried inside a normal-looking HTTPS connection — turned on by default for most users. Instead of asking the resolver you configured, the browser asks its own hardcoded DoH provider (Cloudflare, Google, or another built-in default) directly. The lookup still happens, your page still loads, and nothing in the UI tells you the DNS you set was skipped.
DoH itself is a genuinely good privacy technology — it stops your ISP from seeing your DNS queries in plaintext. The problem is narrower and more specific: it also stops you from being able to enforce a DNS choice you already made, because the browser quietly picks a different resolver than the one you configured.
Why it matters
- Parental controls that filter at the DNS layer (many router-based and family-safety products) stop working for any browser doing its own DoH — the filtering resolver is never consulted.
- Ad- and tracker-blocking DNS (Pi-hole, NextDNS, and similar) loses coverage the same way — DoH traffic goes around it, not through it.
- VPN split-DNS can leak: some VPN clients push a DNS server for the tunnel, but a browser doing its own DoH may bypass it, sending lookups outside the tunnel even while the rest of your traffic stays inside it.
- Corporate and school network policy that relies on DNS-layer filtering has the identical gap, at a different scale.
None of this requires malware or a misconfigured device. It happens on a fresh browser install, with default settings, on a network doing everything right.
How Ferrite catches it
Ferrite runs two complementary checks, and — unlike the examples above — it doesn’t rely on being the DNS server itself:
- Known-resolver blocking, every edition, on by default. Ferrite maintains a curated list of public DoH/DoT resolver addresses (Cloudflare, Google, Quad9, OpenDNS, and others) and watches for connections to them on the ports encrypted DNS actually uses — port 853 for DoT/DoQ (that port has no other legitimate use), and port 443 to those specific resolver addresses for DoH. This runs at the system-filtering level, so it doesn’t need to read packet contents to work.
- TLS-aware detection, with deep inspection (Pro). Some DoH traffic shares an IP address with ordinary web traffic, which a plain address-based check can’t safely distinguish. Ferrite’s deep-inspection tier reads the TLS handshake itself and recognizes DoH by the resolver hostname it names — catching cases the address list alone would miss, without decrypting anything.
Every attempt is attributed to the actual application that made it and shown in the dashboard — not just “something on port 443,” but which process, and where it tried to go.
What this doesn’t claim
Two honest limits, stated plainly rather than glossed over. First, detection is tied to a specific process — a connection Ferrite can’t attribute to an application is never flagged as a bypass, which is under-detection by design, not a bug: it’s the same discipline that keeps Ferrite from misclassifying its own DNS traffic. Second, the known-resolver list is curated, not exhaustive — a DoH provider we haven’t added yet, reached over an address not on the list, won’t be caught by the address check alone (deep inspection’s TLS-name check covers more of that gap, but not all of it).
See it yourself
The dashboard shows this live: every caught attempt, the process that made it, and the resolver it was headed to. If you’ve ever wondered whether your parental controls or ad-blocking DNS were really being respected by every app on the machine, this is the place that answers it — with a real event, not a claim.