De korte versie: wanneer een app op je telefoon verbinding probeert te maken met analytics.facebook.com, moet die eerst het IP-adres van die hostnaam opvragen via DNS. Een filterend DNS-resolver onderschept die zoekopdracht, herkent de bestemming als een tracker en weigert een IP-adres terug te geven. De verbinding wordt nooit opgezet; de data verlaat je apparaat nooit. Dit is elegant en krachtig — maar het heeft vier beperkingen die elke eerlijke bespreking moet benoemen: het kan de inhoud van versleuteld verkeer niet zien, het kan geen advertenties filteren die van hetzelfde domein worden geserveerd als legitieme content, sommige apps omzeilen het systeem-DNS volledig, en versleutelde DNS-protocollen (DoH/DoT/ECH) veranderen het landschap van netwerkobservabiliteit. Hieronder volgt eerst het mechanisme, dan elke beperking, en ten slotte waar DNS-filtering nog steeds wint.
Het mechanisme, in vijf stappen
Elke netwerkverbinding die je telefoon maakt, verloopt via deze reeks (of je het nu merkt of niet):
- Een app wil een server bereiken. Instagram wil een story laden; de Facebook SDK wil een vingerafdruk terugsturen; Safari opent een webpagina. Al deze acties beginnen met een hostnaam —
graph.facebook.com,cdn-news.com,www.example.com. - Het OS vraagt DNS om het IP van de hostnaam. Computers communiceren niet rechtstreeks met
graph.facebook.com— ze communiceren met157.240.22.174. DNS is het telefoonboek dat hostnamen naar IP-adressen vertaalt. - De DNS-query gaat naar een resolver. Zonder VPN is dit doorgaans de resolver van je internetprovider, of een DNS die je zelf hebt ingesteld (meestal Google's
8.8.8.8of Cloudflare's1.1.1.1). Met Casper of een ander DNS-filtertool gaat de query via de versleutelde tunnel naar onze resolver. - De filterende resolver beoordeelt de bestemming. Staat
graph.facebook.comop de tracker-blokkeerlijs? Op een ML-classificatie voor phishingdomeinen? Op een aangepaste gebruikerstoestemmingslijst? De beoordeling gebeurt in enkele milliseconden. - De resolver geeft een antwoord — of weigert. Voor legitieme domeinen: een echt IP-adres, de app maakt verbinding, alles gaat door. Voor geblokkeerde domeinen: een "NXDOMAIN"- of
0.0.0.0-antwoord, de verbindingspoging van de app mislukt en de data verlaat je apparaat nooit.
Dat is het hele mechanisme. Er zijn geen DPI-trucs op het apparaat, geen kernelhooks, geen certificaatinjectie. Het werkt omdat elke IP-verbinding moet beginnen met een hostnaamopzoeking, en die opzoeking is onversleutelde, leesbare tekst die de resolver beheert. Weiger de opzoeking, weiger de verbinding.
Waarom deze aanpak een buitengewone hefboomwerking heeft
Drie structurele kenmerken maken DNS-filtering onevenredig effectief:
- Het is app-agnostisch. Browser-extensies beschermen alleen de browser waarin ze zijn geïnstalleerd. Safari-contentblockers beschermen alleen Safari. Casper's DNS-filter beschermt Instagram, de YouTube-app, je weerwidget, je smart-tv-streamingapp, Mail, Slack, elke menubalk-utility op de Mac — alles wat een DNS-opzoeking doet.
- Het is protocol-agnostisch. HTTP, HTTPS, WebSockets, aangepaste binaire protocollen — alles wat begint met een DNS-opzoeking wordt gefilterd. De versleutelingslaag daarboven maakt niet uit; de resolver onderschept voordat de versleutelingsonderhandeling begint.
- Het is centraal. Elk apparaat op je account krijgt dezelfde bescherming vanuit één configuratie-update. Geen beheer van browser-extensies op meerdere apparaten.
Dit is de reden waarom DNS-tools (Pi-hole, NextDNS, AdGuard DNS, en onze eigen Casper) de afgelopen vijf jaar het dominante patroon zijn geworden in consumentenprivacyfiltering. Maar de hefboomwerking werkt ook andersom — als DNS-filtering faalt, doet het dat doorgaans stilletjes en op grote schaal.
Beperking 1 — Het kan de inhoud van versleuteld verkeer niet zien
DNS-filtering werkt op hostnamen, niet op URL's en niet op payloads. Als een domein volledig geblokkeerd is, zijn alle pagina's en eindpunten op dat domein geblokkeerd. Als een domein volledig is toegestaan, zijn alle pagina's en eindpunten op dat domein toegestaan. Er is geen tussenweg op de DNS-laag — zodra het IP is omgezet, heeft de resolver geen zichtbaarheid meer in wat de app daarna doet.
Dit is prima voor de meeste trackerinfrastructuur, die gebruikmaakt van speciale subdomeinen: analytics.facebook.com, tag-manager.google.com, events.amplitude.com. Het blokkeren van het subdomein laat de hoofdsite intact en schakelt de analytics uit. Maar het is een hardnekkig probleem wanneer advertenties of trackers op hetzelfde domein rijden als legitieme content — Instagram serveert zowel content als gesponsorde berichten vanuit de eigen infrastructuur van Meta; YouTube serveert video's en pre-roll-advertenties vanaf googlevideo.com; X serveert gepromote tweets via dezelfde hostnamen als je tijdlijn. DNS-filtering kan ze niet van elkaar onderscheiden.
Wat dit in de praktijk betekent: Casper elimineert zo'n 80–90% van de advertenties en trackers die je in een gemiddelde week op een gemiddelde telefoon tegenkomt. De resterende 10–20% zijn first-party gehost en vereisen een andere ingreep — doorgaans een browserextensie op de DOM-renderlaag (uBlock Origin in Chrome / Firefox, de ingebouwde Brave Shields, de AdGuard-Safari-extensie) die de gerenderde pagina kan zien en specifieke elementen kan verbergen. We raden expliciet aan beide lagen te combineren als je de hoogste dekking wilt; Casper dekt de netwerklaag die browserextensies missen, browserextensies dekken de DOM-laag die DNS mist.
Beperking 2 — Sommige apps omzeilen het systeem-DNS volledig
Een groeiend aantal apps maakt geen gebruik meer van de systeem-DNS-resolver — ze bevatten hun eigen DNS-over-HTTPS (DoH)- of DNS-over-TLS (DoT)-implementaties die rechtstreeks communiceren met Cloudflare, Google of de infrastructuur van de ontwikkelaar, en daarmee omzeilen ze de DNS die de gebruiker heeft ingesteld.
Firefox doet dit standaard (Mozilla's Trusted Recursive Resolver-programma). Chrome doet het wanneer de bestaande DNS-resolver van de gebruiker op de auto-detectielijst van Google staat. Sommige populaire Android-apps (Brave, Discord, Signal, diverse streaming-apps) bevatten vaste DoH-eindpunten. De motivatie is doorgaans privacy — om DNS-surveillance door internetproviders te voorkomen — maar het neveneffect is dat de door de gebruiker geconfigureerde DNS-filtering niet van toepassing is op die apps.
Wat dit in de praktijk betekent: op iOS is dit zeldzaam en biedt Apple's NetworkExtension-framework Casper voldoende hooks om de meeste DoH-pogingen op app-niveau te onderscheppen. Op Android is de situatie rommeliger — sommige apps lossen hostnamen op buiten onze zichtbaarheid. Casper's aanpak is tweeledig: (a) we publiceren een lijst van apps met bekend DoH-omleidingsgedrag, zodat gebruikers weten wat buiten het filter valt, en (b) op Android gebruiken we VPN-routering per app om kritiek verkeer terug door het systeem-DNS-pad te leiden voor die apps waarbij je filtering specifiek wilt toepassen. Dit is een van de weinige gevallen waarbij de flexibelere VPN-architectuur van Android een echte meerwaarde heeft ten opzichte van iOS.
Beperking 3 — CDN's en gedeelde infrastructuur maken blokkering per tenant onmogelijk
Veel websites en diensten delen hostnamen op IP-niveau — cdn-namespace.cloudfront.net kan content serveren voor duizenden verschillende organisaties achter hetzelfde Cloudfront-eindpunt. De hostnaam blokkeren treft iedereen die die deelt; hem toestaan staat iedereen toe die hem deelt. De DNS-resolver heeft geen manier om te weten voor welke tenant een specifiek verzoek bestemd is.
Het meest voorkomende geval waar dit pijn doet: de tracking-eindpunten van Google blokkeren terwijl de functionele eindpunten van Google worden toegestaan. googletagmanager.com is puur voor tracking en kan veilig worden geblokkeerd. Maar googleapis.com host alles van Maps-tegels tot Cloud Storage tot Firebase Auth, naast Analytics-ingestion — het blokkeren ervan zou een enorm deel van de apps stuk maken. Casper's standaardblokkeerlijst is afgesteld om gedeelde-functionele eindpunten open te laten terwijl toegewijde tracker-eindpunten worden geblokkeerd, maar er is een harde grens aan de granulariteit die haalbaar is zonder apps stuk te maken.
Wat dit in de praktijk betekent: sommige trackingsignalen komen erdoor omdat de onderliggende hostnaam te verweven is met legitieme functionaliteit om te blokkeren. We vermelden de belangrijkste gevallen in onze supportdocumentatie zodat je weet wat er doorheen glipt. Voor gebruikers die strengere blokkering willen — met het begrip dat sommige apps dan stuk gaan — is een "agressieve" instelling beschikbaar.
Beperking 4 — Encrypted Client Hello (ECH) verandert de observeerbaarheid
De TLS-handshake lekte historisch gezien de doelhostnaam via het Server Name Indication (SNI)-veld — zelfs wanneer DNS versleuteld was, kon een waarnemer op het netwerk zien met welke sites je verbinding maakte. De Encrypted Client Hello (ECH)-standaard van de IETF versleutelt dit laatste stukje, en het wordt breed uitgerold in 2025–2026 (Cloudflare schakelde het standaard in eind 2024, Firefox ondersteunt het stabiel, Chrome is bezig met gefaseerde uitrol).
Voor privacy is dit ronduit goed — je internetprovider kan niet langer zien welke sites je bezoekt, zelfs niet op TLS-niveau. Voor DNS-filtering verandert het niets direct: we werken op de DNS-opzoeking zelf, niet op TLS-observatie. Maar ECH maakt deel uit van een bredere trend naar meer versleuteld DNS (DoH/DoT/ODoH/Oblivious DNS), waarbij gebruikers de resolverfunctie delegeren aan derden, soms zonder het te beseffen. Die delegatie kan door de gebruiker geconfigureerde filtertools omzeilen.
Wat dit in de praktijk betekent: de stack voor consumentenprivacy fragmenteert. Apple's iCloud Private Relay routeert versleuteld verkeer via Apple's resolvers (waarbij gebruikers-DNS wordt omzeild). DoH-als-standaard in sommige browsers doet hetzelfde. ECH is goed voor privacy ten opzichte van passieve waarnemers, maar vermindert de eigen controle van gebruikers over hun verkeer. Casper's reactie hierop is om de netwerkzichtbaarheid die gebruikers willen te bieden op de plek waar ze die daadwerkelijk willen (hun eigen filterende resolver), en om te integreren met — in plaats van te vechten tegen — de bredere versleutelingstrends.
Waar DNS-filtering nog steeds wint
De beperkingen benoemen betekent niet dat DNS-filtering een slechte keuze is — het betekent gewoon een eerlijk gesprek. De gevallen waar het de schoonste ingreep blijft:
- Gedragsmatige tracking door ingebedde SDK's. Facebook SDK, Mixpanel, Amplitude, Segment, AppsFlyer — allemaal gebruiken ze toegewijde trackerhostnamen die DNS-filtering netjes blokkeert. Dit is de grootste categorie qua volume en de categorie die gebruikers het meest willen stoppen. Casper's trackerblokkering dekt dit direct.
- Advertentienetwerken in alle apps. DoubleClick, AdMob, de grote ingestion-eindpunten van advertentienetwerken — allemaal gebruiken ze toegewijde hostnamen. Ze blokkeren stopt advertenties in de lange staart van mobiele apps waar browserextensies niet draaien. Zie hoe dit in de praktijk uitpakt.
- Phishing- en malwaredomeinen. Real-time dreigingsbeoordeling op de DNS-laag onderschept zero-day-phishingdomeinen voordat ze aan publieke blokeerlijsten worden toegevoegd. Dit is de laag waar de AI-classifier in Casper's dreigingsbescherming zijn waarde bewijst — uitgebreid besproken in onze analyse van drie echte phishingcampagnes.
- Cross-app vingerafdruk-exfiltratie. Zelfs wanneer iOS App Tracking Transparency de IDFA tegenhoudt, sturen apps nog steeds vingerafdrukgegevens door — maar die moeten ergens naartoe. De DNS-laag onderschept de exfiltratie, ongeacht welke identifier de app had willen gebruiken. Zie onze diepere analyse van wat ATT niet tegenhoudt.
- OEM- en besturingssysteemtelemetrie. Samsung Knox Analytics, Xiaomi-cloud, Apple's analytics-eindpunten, Windows-telemetrie — allemaal gebruiken ze toegewijde hostnamen die DNS-filtering blokkeert zonder de functionele delen van het besturingssysteem te breken.
- Bescherming op vijandige netwerken (openbare wifi). De VPN-tunnel die het DNS-verkeer draagt, versleutelt ook alles wat over het lokale netwerk stroomt — dus zelfs wanneer het DNS-filtervoordeel klein is, is het versleutelingsvoordeel op café-wifi reëel.
Het twee-lagen-model dat echt werkt
Voor gebruikers die de meest grondige bescherming willen, is het patroon dat het beste werkt een combinatie van twee complementaire lagen:
- Netwerklaag (DNS-filter): dekt elke app op het apparaat, blokkeert de ~80–90% van tracker/advertentie/phishing-verkeer dat gebruikmaakt van toegewijde hostnamen. Casper zit hier.
- DOM-laag (browser-contentblocker): uBlock Origin in Chrome / Firefox, de ingebouwde Brave Shields, of de AdGuard-Safari-extensie. Onderschept de first-party gehoste advertenties op Instagram, YouTube, X en dergelijke, die DNS niet kan onderscheiden van legitieme content.
Elke laag dekt de gaten die de andere niet kan. Samen bereiken ze 95%+ dekking; elke laag afzonderlijk zit dichter bij 80%. De meeste privacybewuste gebruikers die we hebben gesproken, draaien precies deze combinatie.
Conclusie
DNS-filtering is de juiste plek om in te grijpen voor het grootste deel van de consumentenprivacydreigingen — tracking door ingebedde SDK's, exfiltratie via advertentienetwerken, resolutie van phishingdomeinen, OEM-telemetrie. Het is geen wondermiddel en het dekt niet elk geval. De vier beperkingen hierboven zijn reëel, en elke leverancier die ze verbergt, verkoopt of slecht door of verkoopt iets wat hij niet zou moeten verkopen. Combineer de netwerklaag met een browser-DOM-laag voor de resterende gevallen, beschouw netwerkkwetsbaarheidversleuteling als een extra voordeel dat je er gratis bij krijgt, en je hebt het grootste deel van het dreigingslandschap voor de consument in 2026 afgedekt.