How DNS-level filtering actually works — and the four limitations vendors don't advertise

The short version: when an app on your phone tries to connect to analytics.facebook.com, it first has to look up the IP address for that hostname via DNS. A filtering DNS resolver intercepts the lookup, recognizes the destination as a tracker, and refuses to return an IP. The connection never opens; the data never leaves your device. This is elegant and powerful — but it has four limitations every honest discussion has to name: it can't see encrypted traffic content, it can't filter ads served from the same domain as legitimate content, some apps bypass system DNS entirely, and encrypted-DNS protocols (DoH/DoT/ECH) are changing the network observability landscape. Below, the mechanism, then each limitation, then where DNS filtering still wins.

The mechanism, in five steps

Every network connection your phone makes goes through this sequence (whether you notice it or not):

1. An app wants to reach a server. Instagram wants to load a story; Facebook SDK wants to send a fingerprint home; Safari is opening a web page. Every one of these starts with a hostname — graph.facebook.com, cdn-news.com, www.example.com.
2. The OS asks DNS for the hostname's IP. Computers don't talk to graph.facebook.com directly — they talk to 157.240.22.174. DNS is the directory that translates hostnames to IPs.
3. The DNS query travels to a resolver. Without a VPN, this is usually your ISP's resolver or whatever DNS you've configured (typically Google's 8.8.8.8 or Cloudflare's 1.1.1.1). With Casper or another DNS-filtering tool, the query travels to our resolver instead, via the encrypted tunnel.
4. The filtering resolver scores the destination. Is graph.facebook.com on the tracker blocklist? On a phishing-domain ML classification? On a custom user allowlist? The scoring happens in single-digit milliseconds.
5. The resolver returns an answer — or refuses. For legitimate domains: a real IP, the app connects, life proceeds. For blocked domains: a "NXDOMAIN" or 0.0.0.0 response, the app's connection attempt fails, and the data never leaves your device.

That's the entire mechanism. There are no on-device DPI tricks, no kernel hooks, no certificate-injection sleight of hand. It works because every IP connection has to start with a hostname lookup, and the lookup is unencrypted plaintext that the resolver controls. Refuse the lookup, refuse the connection.

Why this approach has unusual leverage

Three structural features make DNS-level filtering disproportionately effective:

• It's app-agnostic. Browser extensions only protect the browser they're in. Safari content blockers only protect Safari. Casper's DNS filter protects Instagram, the YouTube app, your weather widget, your smart-TV streaming app, Mail, Slack, every menu-bar utility on Mac — anything that makes a DNS lookup.
• It's protocol-agnostic. HTTP, HTTPS, WebSockets, custom binary protocols, anything that starts with a DNS lookup gets filtered. The encryption layer above doesn't matter; the resolver intercepts before the encryption negotiation starts.
• It's central. Every device on your account gets the same protection from one configuration update. No browser-extension fleet management.

This is why DNS-level tools (Pi-hole, NextDNS, AdGuard DNS, and our own Casper) have become the dominant pattern in consumer privacy filtering over the past five years. But the leverage cuts both ways — when DNS filtering fails, it tends to fail silently and at scale.

Limitation 1 — It can't see what's inside the encrypted traffic

DNS filtering operates on hostnames, not URLs and not payloads. If a domain is fully blocklisted, every page and every endpoint at that domain is blocked. If a domain is fully allowed, every page and every endpoint at that domain is allowed. There is no middle ground at the DNS layer — once the IP is resolved, the resolver has no visibility into what the app does next.

This is fine for most tracking infrastructure, which uses dedicated subdomains: analytics.facebook.com, tag-manager.google.com, events.amplitude.com. Blocking the subdomain leaves the host site working and kills the analytics. But it's a hard problem when ads or trackers ride on the same domain as legitimate content — Instagram serves both content and sponsored posts from Meta's own infrastructure; YouTube serves video and pre-roll ads from googlevideo.com; X serves promoted tweets from the same hostnames as your timeline. DNS-level filtering can't distinguish them.

What this means in practice: Casper kills ~80–90% of the ads and trackers you'd encounter in a typical week on a typical phone. The remaining 10–20% are first-party-hosted and require a different intervention — usually a browser extension at the DOM-rendering layer (uBlock Origin in Chrome / Firefox, the built-in Brave Shields, AdGuard's Safari extension) that can see the rendered page and hide specific elements. We explicitly recommend running both layers if you want the highest coverage; Casper covers the network layer that browser extensions miss, browser extensions cover the DOM layer that DNS misses.

Limitation 2 — Some apps bypass system DNS entirely

A growing list of apps no longer use the system DNS resolver — they ship their own DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) implementations that talk directly to Cloudflare, Google, or the developer's own infrastructure, bypassing whatever DNS the user has configured.

Firefox does this by default (Mozilla's Trusted Recursive Resolver program). Chrome does it when the user's existing DNS resolver is on Google's auto-detection list. Some popular Android apps (Brave, Discord, Signal, several streaming apps) ship hardcoded DoH endpoints. The motivation is generally privacy — preventing ISP-level DNS surveillance — but the side effect is that user-configured DNS filtering doesn't apply to those apps.

What this means in practice: on iOS this is rare and Apple's NetworkExtension framework gives Casper enough hooks to intercept most app-level DoH attempts. On Android, the situation is messier — some apps will resolve hostnames outside our visibility. Casper's response is twofold: (a) we publish a list of apps with known DoH bypass behavior so users know what's outside the filter, and (b) on Android we use per-app VPN routing to force critical traffic back through the system DNS path for those apps where you specifically want filtering applied. This is one of the few places where Android's more flexible VPN architecture is genuinely an advantage over iOS.

Limitation 3 — CDNs and shared infrastructure make per-tenant blocking impossible

Many websites and services share hostnames at the IP level — cdn-namespace.cloudfront.net might serve content for thousands of different organizations behind the same Cloudfront endpoint. Blocking the hostname blocks everyone who shares it; allowing it allows everyone who shares it. The DNS resolver has no way to know which tenant a specific request is destined for.

The most common case where this hurts: blocking Google's tracking endpoints while allowing Google's functional endpoints. googletagmanager.com is purely tracking and can be blocked safely. But googleapis.com hosts everything from Maps tiles to Cloud Storage to Firebase Auth alongside Analytics ingestion — blocking it would break a huge fraction of apps. Casper's default blocklist is tuned to leave shared-functional endpoints open while blocking dedicated-tracker endpoints, but there's a hard ceiling on how granular this can get without breaking apps.

What this means in practice: some tracking signals get through because the underlying hostname is too entangled with legitimate functionality to block. We list the major cases in our support docs so you know what slips. For users who want stricter blocking with the understanding that some apps will break, an "aggressive" preset is available.

Limitation 4 — Encrypted Client Hello (ECH) is changing observability

The TLS handshake historically leaked the destination hostname via the Server Name Indication (SNI) field — even when DNS was encrypted, an observer on the network could see which sites you were connecting to. The IETF's Encrypted Client Hello (ECH) standard encrypts this final piece, and it's rolling out widely in 2025–2026 (Cloudflare enabled it by default in late 2024, Firefox supports it stably, Chrome is in staged rollout).

For privacy this is genuinely good — your ISP can no longer see what sites you visit even at the TLS level. For DNS-level filtering, it doesn't directly change anything: we operate on the DNS lookup itself, not on TLS observation. But ECH is part of a broader trend toward more encrypted DNS (DoH/DoT/ODoH/Oblivious DNS) where users delegate the resolver function to third parties, sometimes without realizing it. That delegation can route around user-configured filtering tools.

What this means in practice: the consumer-privacy stack is fragmenting. Apple's iCloud Private Relay route encrypted traffic through Apple's resolvers (bypassing user DNS). DoH-by-default in some browsers does the same. ECH is good for privacy from passive observers but reduces user agency over their own traffic. Casper's response is to provide the network-level visibility users want at the place they actually want it (their own filtering resolver), and to integrate with — not fight against — the broader encryption trends.

Where DNS-level filtering still wins

Naming the limitations doesn't mean DNS filtering is a bad bet — it just means honest discussion. The cases where it remains the cleanest intervention:

• Behavioral tracking by embedded SDKs. Facebook SDK, Mixpanel, Amplitude, Segment, AppsFlyer — all use dedicated tracker hostnames that DNS filtering blocks cleanly. This is the biggest category by volume and the one users most want stopped. Casper's tracker blocking covers this directly.
• Ad networks across all apps. DoubleClick, AdMob, the major ad-network ingestion endpoints all use dedicated hostnames. Blocking them silences ads inside the long tail of mobile apps where browser extensions don't run. See how this lands in practice.
• Phishing and malware domains. Real-time threat scoring at the DNS layer catches zero-day phishing domains before they're added to public blocklists. This is the layer where the AI classifier in Casper's threat protection earns its keep — covered in detail in our breakdown of three real phishing campaigns.
• Cross-app fingerprint exfiltration. Even when iOS App Tracking Transparency stops the IDFA, apps still exfiltrate fingerprint data — but they have to send it somewhere. The DNS layer catches the exfiltration regardless of which identifier the app would have used. See our deeper breakdown of what ATT doesn't stop.
• OEM and operating-system telemetry. Samsung Knox analytics, Xiaomi cloud, Apple's analytics endpoints, Windows telemetry — all use dedicated hostnames that DNS filtering blocks without breaking the functional parts of the OS.
• Hostile-network protection (public WiFi). The VPN tunnel that carries the DNS traffic also encrypts everything else flowing over the local network — so even when the DNS-filtering benefit is small, the encryption benefit on coffee-shop WiFi is real.

The two-layer model that actually works

For users who want the most thorough protection, the pattern that works best is two complementary layers:

1. Network layer (DNS-level filter): covers every app on the device, blocks the ~80–90% of tracker/ad/phishing traffic that uses dedicated hostnames. Casper sits here.
2. DOM layer (browser content blocker): uBlock Origin in Chrome / Firefox, the built-in Brave Shields, or AdGuard's Safari extension. Catches the first-party-hosted ads on Instagram, YouTube, X, and the like that DNS can't distinguish from legitimate content.

Each layer covers the gaps the other can't. Together they get you 95%+ coverage; either alone is closer to 80%. Most privacy-focused users we've talked to run exactly this pairing.

Bottom line

DNS-level filtering is the right place to intervene for the biggest share of consumer privacy threats — embedded-SDK tracking, ad-network exfiltration, phishing domain resolution, OEM telemetry. It's not magic, and it doesn't cover every case. The four limitations above are real, and any vendor that hides them is either selling poorly or selling something it shouldn't. Pair the network layer with a browser-DOM layer for the residual cases, treat hostile-network encryption as a separate win you get bundled in, and you've covered most of what a 2026 consumer threat surface looks like.