By Yair Knijn · February 23, 2025

The IT director who believed his web filter was enforced, until a browser turned on DoH and routed around it

The IT director had a clean architecture diagram and a clear conscience. Every workstation pointed at the corporate resolver, that resolver enforced web-content categories, and the firewall dropped outbound port 53 to anything else. On paper, no device could reach a disallowed domain, and the auditors heard exactly that.

Then someone in finance opened a gambling site over corporate Wi-Fi and it loaded fine. Their browser had quietly switched on DNS-over-HTTPS, pushed its lookups to a public resolver over 443, and the corporate resolver never saw a single query. The policy had not failed; it had simply stopped being asked.

How DoH and DoT moved the resolver decision into the application

For most of DNS history the resolver was a host setting handed out over DHCP, inherited by every app without a vote. DoH (RFC 8484) and DoT (RFC 7858) broke that by letting the application choose its own resolver and wrap the query in TLS. Chrome has shipped Secure DNS on by default since version 83, Edge rides the same Chromium behavior, and Firefox runs its own DoH path. The lookup now travels inside ordinary HTTPS to a provider the browser chose, indistinguishable on the wire. Your resolver policy assumes the endpoint asks your resolver, and it no longer has to.

Why blocking known DoH endpoints is a losing game of whack-a-mole

The reflex is to block the resolvers. Drop the IPs for Cloudflare's 1.1.1.1, Google's 8.8.8.8, Quad9, and call it handled. That buys you maybe a week. Public DoH providers number in the dozens, fresh ones surface constantly, and plenty sit on shared CDN address space you cannot block without breaking something unrelated. A DoH endpoint is just an HTTPS URL, so a user or a misbehaving app can point at one you have never heard of. The list grows by design.

The difference between filtering at the network and filtering at the endpoint

Network-resolver filtering inspects a request the endpoint volunteers to send, and holds right up until the endpoint declines. Endpoint enforcement flips the trust model: the device is configured so the resolver choice is not negotiable, and any application trying to pick its own is refused before a packet leaves the machine. One filters traffic you happen to see; the other governs what the machine is permitted to do. When a config flag lets an app override your network path, only the second was ever a real control.

Pinning the resolver and canary-domain control on managed devices

On managed endpoints you hold levers the network does not:

• Set DnsOverHttpsMode to off, or pin a template, through Chrome and Edge group policy so the browser cannot silently switch providers.
• Lock Firefox with network.trr.mode via an enterprise policy instead of trusting per-user settings.
• Answer the Firefox canary domain use-application-dns.net with NXDOMAIN, which signals that filtering is managed and DoH should stay off.
• Pin the OS resolver and block outbound DoT on 853 so an app cannot quietly fall back to encrypted transport.

None of these live on the network resolver. They live on the device, the only place the choice holds.

Proving enforcement holds even when the browser fights you

A policy you cannot demonstrate is a policy you are guessing about. Test from the endpoint the way a user would: flip Secure DNS on in Chrome, point Firefox at a public DoH URL, and confirm the lookup still lands on your resolver and the block still fires. The failure that bites later is enforcement that holds on a domain-joined desktop and evaporates on the contractor laptop that never got the policy, which is exactly where the gambling site loaded.

ClearScreen enforces filtering at the endpoint, where the resolver choice is pinned and a browser turning on DoH does not route around the policy it belongs to. If you want enforcement you can prove rather than assume, see how endpoint enforcement works.