July 3, 2026

Web filtering on Windows without a proxy: the local-resolver model

Enterprise web filtering on Windows has long defaulted to TLS-terminating proxies or PAC files redirecting to gateways. Both approaches impose hidden costs: certificate trust changes, latency on every request, works-council review in Europe, and fragile coverage when remote workers leave the VPN. DNS-layer filtering on the endpoint offers a simpler alternative — with honest trade-offs about what it cannot do.

Why proxies hurt more than they solve

TLS interception requires installing a corporate root certificate in the device's trust store. Browsers and many applications then transparently use it for HTTPS inspection. This sounds transparent; it is not. Certificate pinning (apps that validate they are talking to the real server) breaks. VPN clients, banking apps, and APIs that pin certificates refuse to connect. Developers have to whitelist the proxy certificate, creating tech-debt and support burden.

PAC files route traffic to a proxy, which adds latency: every DNS lookup and every HTTPS handshake goes through a remote system. For remote workers off the corporate VPN (BYOD, work-from-home), proxy-based filtering often fails entirely because the device cannot reach the gateway reliably.

Works-council involvement is another proxy cost. In Germany, Netherlands, and parts of France, employee representatives must review and approve any system that monitors or intercepts traffic. TLS interception triggers that review automatically; DNS filtering often does not, because it blocks at resolution time without accessing plaintext traffic. When your works council asks "does this tool see what employees are typing?" DNS filtering says no; a proxy says yes — and your approval becomes conditional, delayed, or denied.

The local-resolver model

DNS filtering on Windows runs an agent that binds 127.0.0.1:53 and intercepts DNS queries before they leave the device. When a browser or application asks for a domain, the agent applies policy rules (UT1 categories, StevenBlack blocklists, threat feeds), and either resolves the domain or sinkholes it to a branded block page served locally. No central gateway needed, no latency penalty, no certificate manipulation, no remote-worker coverage gaps.

The agent can run on Windows, Linux, and macOS (macOS on-demand), so your fleet control is consistent across operating systems. When the endpoint is offline (no internet, no VPN), the signed threat-feed bundles remain active, and the agent continues blocking based on local policy. That resilience matters for executives traveling without reliable connectivity.

What DNS filtering cannot do

Be clear about scope. DNS filtering sees domain names, not content. A proxy or advanced web gateway can inspect HTTPS payloads (with TLS termination), detect sensitive data in POST bodies, and enforce DLP rules. DNS filtering blocks the domain before a connection is made; it never sees request bodies, file uploads, or exfiltration attempts within HTTPS tunnels. If your compliance policy requires POST-body inspection or file-transfer controls, you need a proxy or gateway in addition to DNS filtering, not instead of it.

Similarly, browsers can bypass system DNS entirely with DNS-over-HTTPS. If a user configures Firefox or Brave to resolve through Cloudflare or Quad9 DoH, a resolver-level filter loses visibility — we wrote up how that plays out. The counter-measure is managed browser policy: disable or pin DoH through your enterprise browser configuration so resolution stays on the device resolver. DNS filtering blocks threats and policy categories at resolution time; it is not a silver bullet.

Endpoint beats network-level

Network-level DNS filtering (sinkhole at the gateway) fails when users switch networks or use personal devices. Endpoint-level DNS filtering travels with the device and applies the same policy everywhere. When your BYOD policy says "filtered regardless of location," endpoint DNS is the architecture that delivers it without requiring VPN always-on or proxy bypass configuration.

Deploy DNS-layer filtering for baseline threat and category control on Windows and Linux fleets. When you need POST-body inspection, add a gateway control with clear documentation of its role and separate works-council approval if required.

See ClearScreen's endpoint filtering features and how local-resolver architecture eliminates proxy costs while maintaining audit trails your security team can rely on.