Hur DNS-nivåfiltrering faktiskt fungerar — och de fyra begränsningarna leverantörerna inte annonserar

Kortversionen: när en app på din telefon försöker ansluta till analytics.facebook.com måste den först slå upp IP-adressen för det värdnamnet via DNS. En filtrerande DNS-resolver fångar upp uppslagningen, känner igen destinationen som ett spårningsverktyg och vägrar att returnera en IP-adress. Anslutningen öppnas aldrig; datan lämnar aldrig din enhet. Det är elegant och kraftfullt — men det finns fyra begränsningar som varje ärlig diskussion måste nämna: det kan inte se innehållet i krypterad trafik, det kan inte filtrera annonser som serveras från samma domän som legitimt innehåll, vissa appar kringgår systemets DNS helt, och krypterade DNS-protokoll (DoH/DoT/ECH) förändrar nätverksobservabilitetslandskapet. Nedan: mekanismen, sedan varje begränsning, sedan var DNS-filtrering fortfarande vinner.

Mekanismen i fem steg

Varje nätverksanslutning din telefon gör går igenom den här sekvensen (oavsett om du märker det eller inte):

En app vill nå en server. Instagram vill ladda en story; Facebook SDK vill skicka ett fingeravtryck hem; Safari öppnar en webbsida. Alla dessa börjar med ett värdnamn — graph.facebook.com, cdn-news.com, www.example.com.
OS:et frågar DNS om värdnamnets IP. Datorer pratar inte direkt med graph.facebook.com — de pratar med 157.240.22.174. DNS är katalogen som översätter värdnamn till IP-adresser.
DNS-frågan skickas till en resolver. Utan VPN är detta vanligtvis din internetleverantörs resolver eller vilken DNS du har konfigurerat (vanligtvis Googles 8.8.8.8 eller Cloudflares 1.1.1.1). Med Casper eller ett annat DNS-filtreringsverktyg skickas frågan istället till vår resolver via den krypterade tunneln.
Den filtrerande resolvern bedömer destinationen. Finns graph.facebook.com på spårningsblocklistan? På en ML-klassificering av nätfiskedomäner? På en anpassad tillåtelselista? Bedömningen sker på ensiffriga millisekunder.
Resolvern returnerar ett svar — eller vägrar. För legitima domäner: en riktig IP, appen ansluter, livet fortsätter. För blockerade domäner: ett "NXDOMAIN"- eller 0.0.0.0-svar, appens anslutningsförsök misslyckas och datan lämnar aldrig din enhet.

Det är hela mekanismen. Det finns inga DPI-tricks på enheten, inga kernelhookar, inga certifikatinjektioner. Det fungerar eftersom varje IP-anslutning måste börja med en värdnamnsuppslagning, och uppslagningen är okrypterad klartext som resolvern kontrollerar. Neka uppslagningen, neka anslutningen.

Varför det här tillvägagångssättet har ovanlig räckvidd

Tre strukturella egenskaper gör DNS-nivåfiltrering oproportionerligt effektiv:

Den är appoberoende. Webbläsartillägg skyddar bara den webbläsare de är installerade i. Safari-innehållsblockerare skyddar bara Safari. Caspers DNS-filter skyddar Instagram, YouTube-appen, din väderwidget, din smarta TV:s streamingapp, Mail, Slack, varje menylistsverktyg på Mac — allt som gör en DNS-uppslagning.
Den är protokolloberoende. HTTP, HTTPS, WebSockets, anpassade binärprotokoll — allt som börjar med en DNS-uppslagning filtreras. Krypteringslagret ovanför spelar ingen roll; resolvern fångar upp innan krypteringsförhandlingen börjar.
Den är central. Varje enhet på ditt konto får samma skydd från en enda konfigurationsuppdatering. Ingen hantering av webbläsartilläggsflottor.

Det är därför DNS-baserade verktyg (Pi-hole, NextDNS, AdGuard DNS och vår egen Casper) har blivit det dominerande mönstret inom konsumentintegritetsfiltreringen de senaste fem åren. Men räckvidden skär åt båda håll — när DNS-filtrering misslyckas tenderar det att misslyckas tyst och i stor skala.

Begränsning 1 — Den kan inte se vad som finns inuti krypterad trafik

DNS-filtrering opererar på värdnamn, inte URL:er och inte nyttolaster. Om en domän är helt blockerad är varje sida och varje slutpunkt på den domänen blockerad. Om en domän är helt tillåten är varje sida och varje slutpunkt på den domänen tillåten. Det finns inget mellanting på DNS-nivå — när IP-adressen är löst har resolvern ingen insyn i vad appen gör härnäst.

Det här fungerar bra för det mesta av spårningsinfrastrukturen, som använder dedikerade underdomäner: analytics.facebook.com, tag-manager.google.com, events.amplitude.com. Att blockera underdomänen låter värdplatsen fungera och dödar analysen. Men det är ett svårt problem när annonser eller spårare delar samma domän som legitimt innehåll — Instagram serverar både innehåll och sponsrade inlägg från Metas egen infrastruktur; YouTube serverar video och pre-roll-annonser från googlevideo.com; X serverar sponsrade tweets från samma värdnamn som din tidslinje. DNS-nivåfiltrering kan inte skilja dem åt.

Vad detta innebär i praktiken: Casper eliminerar ~80–90 % av annonserna och spårarna du skulle stöta på under en typisk vecka på en typisk telefon. De återstående 10–20 % är förstapartsbaserade och kräver en annan intervention — vanligtvis ett webbläsartillägg på DOM-renderingslagret (uBlock Origin i Chrome / Firefox, de inbyggda Brave Shields, AdGuards Safari-tillägg) som kan se den renderade sidan och dölja specifika element. Vi rekommenderar explicit att köra båda lagren om du vill ha högsta täckning; Casper täcker nätverkslagret som webbläsartillägg missar, webbläsartillägg täcker DOM-lagret som DNS missar.

Begränsning 2 — Vissa appar kringgår systemets DNS helt

En växande lista av appar använder inte längre systemets DNS-resolver — de levererar egna DNS-over-HTTPS (DoH)- eller DNS-over-TLS (DoT)-implementationer som pratar direkt med Cloudflare, Google eller utvecklarens egna infrastruktur och kringgår vilken DNS användaren har konfigurerat.

Firefox gör detta som standard (Mozillas Trusted Recursive Resolver-program). Chrome gör det när användarens befintliga DNS-resolver finns på Googles automatiska identifieringslista. Vissa populära Android-appar (Brave, Discord, Signal, flera streamingappar) levereras med hårdkodade DoH-slutpunkter. Motivationen är i allmänhet integritet — att förhindra DNS-övervakning på ISP-nivå — men bieffekten är att DNS-filtrering konfigurerad av användaren inte gäller för dessa appar.

Vad detta innebär i praktiken: på iOS är detta sällsynt och Apples NetworkExtension-ramverk ger Casper tillräckligt med krokar för att fånga upp de flesta DoH-försök på appnivå. På Android är situationen rörigare — vissa appar löser upp värdnamn utanför vår synlighet. Caspers svar är tvådelat: (a) vi publicerar en lista över appar med känt DoH-kringgåendebeteende så att användare vet vad som är utanför filtret, och (b) på Android använder vi per-app VPN-routing för att tvinga kritisk trafik tillbaka genom systemets DNS-sökväg för de appar där du specifikt vill ha filtrering tillämpad. Det här är ett av de få ställen där Androids mer flexibla VPN-arkitektur verkligen är en fördel jämfört med iOS.

Begränsning 3 — CDN:er och delad infrastruktur gör blockering per klient omöjlig

Många webbplatser och tjänster delar värdnamn på IP-nivå — cdn-namespace.cloudfront.net kan servera innehåll åt tusentals olika organisationer bakom samma Cloudfront-slutpunkt. Att blockera värdnamnet blockerar alla som delar det; att tillåta det tillåter alla som delar det. DNS-resolvern har inget sätt att veta vilken klient en specifik begäran är avsedd för.

Det vanligaste fallet där detta skapar problem: att blockera Googles spårningsslutpunkter medan man tillåter Googles funktionella slutpunkter. googletagmanager.com är rent spårningsrelaterat och kan blockeras säkert. Men googleapis.com hostar allt från kartrutor till Cloud Storage till Firebase Auth vid sidan av Analytics-inmatning — att blockera det skulle bryta en stor del av apparna. Caspers standardblocklista är inställd för att lämna delade funktionella slutpunkter öppna medan dedikerade spårningsslutpunkter blockeras, men det finns ett hårt tak för hur detaljerat detta kan göras utan att appar slutar fungera.

Vad detta innebär i praktiken: vissa spårningssignaler passerar igenom eftersom det underliggande värdnamnet är för sammanflätat med legitim funktionalitet för att blockeras. Vi listar de viktigaste fallen i vår supportdokumentation så att du vet vad som glider igenom. För användare som vill ha striktare blockering med förståelsen att vissa appar kan sluta fungera, finns en "aggressiv" förinställning tillgänglig.

Begränsning 4 — Encrypted Client Hello (ECH) förändrar observabiliteten

TLS-handskakningen läckte historiskt destinationsvärdnamnet via Server Name Indication (SNI)-fältet — även när DNS var krypterat kunde en observatör på nätverket se vilka webbplatser du anslöt till. IETF:s Encrypted Client Hello (ECH)-standard krypterar den sista biten, och den rullas ut brett under 2025–2026 (Cloudflare aktiverade det som standard i slutet av 2024, Firefox stöder det stabilt, Chrome är i stegvis utrullning).

För integritet är detta genuint bra — din internetleverantör kan inte längre se vilka webbplatser du besöker ens på TLS-nivå. För DNS-nivåfiltrering ändrar det inte direkt något: vi opererar på DNS-uppslagningen i sig, inte på TLS-observation. Men ECH är en del av en bredare trend mot mer krypterat DNS (DoH/DoT/ODoH/Oblivious DNS) där användare delegerar resolverfunktionen till tredje parter, ibland utan att inse det. Denna delegering kan kringgå användarkonfigurerade filtreringsverktyg.

Vad detta innebär i praktiken: konsumentintegritetsstacken fragmenteras. Apples iCloud Private Relay dirigerar krypterad trafik via Apples resolvers (kringgår användarens DNS). DoH som standard i vissa webbläsare gör detsamma. ECH är bra för integritet mot passiva observatörer men minskar användarens kontroll över sin egen trafik. Caspers svar är att ge användarna den nätverksnivåssynlighet de vill ha på den plats de faktiskt vill ha den (deras egen filtrerande resolver) och att integrera med — inte bekämpa — de bredare krypteringstrenderna.

Var DNS-nivåfiltrering fortfarande vinner

Att nämna begränsningarna innebär inte att DNS-filtrering är ett dåligt val — det innebär bara en ärlig diskussion. De fall där det fortfarande är den renaste interventionen:

Beteendespårning av inbäddade SDK:er. Facebook SDK, Mixpanel, Amplitude, Segment, AppsFlyer — alla använder dedikerade spårningsvärdnamn som DNS-filtrering blockerar rent. Det här är den största kategorin i volym och den användare mest vill stoppa. Caspers spårningsblockning täcker detta direkt.
Annonsnätverk i alla appar. DoubleClick, AdMob, de stora annonsnätverkens inmatningsslutpunkter använder alla dedikerade värdnamn. Att blockera dem tystar annonser i den långa svansen av mobilappar där webbläsartillägg inte körs. Se hur detta fungerar i praktiken.
Nätfiske- och skadliga programdomäner. Hotbedömning i realtid på DNS-nivå fångar nolldagars nätfiskedomäner innan de läggs till i offentliga blockeringslistor. Det här är lagret där AI-klassificeraren i Caspers hotskydd gör verklig nytta — behandlat i detalj i vår genomgång av tre verkliga nätfiskekampanjer.
Exfiltrering av fingeravtryck mellan appar. Även när iOS App Tracking Transparency stoppar IDFA exfiltrerar appar fortfarande fingeravtrycksdata — men de måste skicka det någonstans. DNS-lagret fångar exfiltreringen oavsett vilken identifierare appen hade använt. Se vår djupare genomgång av vad ATT inte stoppar.
OEM- och operativsystemstelemetri. Samsung Knox-analys, Xiaomis moln, Apples analysslutpunkter, Windows-telemetri — alla använder dedikerade värdnamn som DNS-filtrering blockerar utan att bryta de funktionella delarna av OS:et.
Skydd på fientliga nätverk (offentlig WiFi). VPN-tunneln som bär DNS-trafiken krypterar också allt annat som flödar över det lokala nätverket — så även när DNS-filtreringsfördelen är liten är krypteringsfördelen på kafébars WiFi verklig.

Den tvålagermodell som faktiskt fungerar

För användare som vill ha det mest grundliga skyddet är mönstret som fungerar bäst två kompletterande lager:

Nätverkslager (DNS-nivåfilter): täcker varje app på enheten, blockerar ~80–90 % av spårnings-/annons-/nätfisketrafik som använder dedikerade värdnamn. Casper finns här.
DOM-lager (webbläsarinnehållsblockerare): uBlock Origin i Chrome / Firefox, de inbyggda Brave Shields, eller AdGuards Safari-tillägg. Fångar de förstapartsbaserade annonserna på Instagram, YouTube, X och liknande som DNS inte kan skilja från legitimt innehåll.

Varje lager täcker de luckor det andra inte kan. Tillsammans ger de dig 95 %+ täckning; vart och ett för sig är närmare 80 %. De flesta integritetsfokuserade användare vi har pratat med kör exakt detta par.

Sammanfattning

DNS-nivåfiltrering är rätt plats att intervenera för den största andelen konsumentintegritetshot — inbäddad SDK-spårning, annonsnätverksexfiltrering, nätfiskedomänuppslagning, OEM-telemetri. Det är ingen magi och täcker inte varje fall. De fyra begränsningarna ovan är verkliga, och varje leverantör som döljer dem antingen säljer dåligt eller säljer något de inte borde. Para nätverkslagret med ett webbläsar-DOM-lager för resterande fall, betrakta kryptering mot fientliga nätverk som en separat vinst du får på köpet, och du har täckt det mesta av vad en konsumenthotyta 2026 ser ut.