Kort fortalt: når en app på telefonen din prøver å koble til analytics.facebook.com, må den først slå opp IP-adressen for det vertsnavnet via DNS. Et filtrerende DNS-oppslag fanger opp forespørselen, gjenkjenner destinasjonen som en sporing, og nekter å returnere en IP. Tilkoblingen åpnes aldri; dataene forlater aldri enheten din. Dette er elegant og kraftfullt — men det har fire begrensninger som enhver ærlig diskusjon må nevne: det kan ikke se innholdet i kryptert trafikk, det kan ikke filtrere annonser som leveres fra samme domene som legitimt innhold, noen apper omgår system-DNS fullstendig, og krypterte DNS-protokoller (DoH/DoT/ECH) endrer mulighetene for nettverksovervåking. Nedenfor forklarer vi mekanismen, deretter hver begrensning, og til slutt hvor DNS-filtrering fortsatt vinner.
Mekanismen, i fem trinn
Hver nettverkstilkobling telefonen din oppretter, går gjennom denne sekvensen (enten du legger merke til det eller ikke):
- En app vil nå en server. Instagram vil laste inn en story; Facebook SDK vil sende fingeravtrykksdata hjem; Safari åpner en nettside. Alt dette starter med et vertsnavn —
graph.facebook.com,cdn-news.com,www.example.com. - Operativsystemet spør DNS om IP-en til vertsnavnet. Datamaskiner snakker ikke direkte til
graph.facebook.com— de snakker til157.240.22.174. DNS er registeret som oversetter vertsnavn til IP-adresser. - DNS-forespørselen sendes til en resolver. Uten VPN er dette vanligvis internettleverandørens resolver eller den DNS du har konfigurert (typisk Googles
8.8.8.8eller Cloudflares1.1.1.1). Med Casper eller et annet DNS-filtreringsverktøy sendes forespørselen til vår resolver i stedet, via den krypterte tunnelen. - Den filtrerende resolveren vurderer destinasjonen. Er
graph.facebook.compå blokklistene for sporere? Klassifisert som et phishing-domene via ML? På en egendefinert tillatelsesliste? Vurderingen skjer på under ett millisekund. - Resolveren returnerer et svar — eller nekter. For legitime domener: en ekte IP, appen kobler til, livet går videre. For blokkerte domener: et «NXDOMAIN»- eller
0.0.0.0-svar, appens tilkoblingsforsøk mislykkes, og dataene forlater aldri enheten din.
Det er hele mekanismen. Det finnes ingen DPI-triks på enheten, ingen kjernekroker, ingen sertifikatinjeksjon. Det fungerer fordi enhver IP-tilkobling må starte med et vertsnavn-oppslag, og oppslaget er ukryptert klartekst som resolveren kontrollerer. Nekt oppslaget, nekt tilkoblingen.
Hvorfor denne tilnærmingen har uvanlig stor effekt
Tre strukturelle egenskaper gjør DNS-filtrering uforholdsmessig effektiv:
- Den er app-agnostisk. Nettleserutvidelser beskytter bare nettleseren de kjører i. Safari-innholdsblokkerere beskytter bare Safari. Caspers DNS-filter beskytter Instagram, YouTube-appen, værvarslings-widgeten, smart-TV-streaming-apper, Mail, Slack, alle menylinjeverkøy på Mac — alt som gjør et DNS-oppslag.
- Den er protokoll-agnostisk. HTTP, HTTPS, WebSockets, egne binære protokoller — alt som starter med et DNS-oppslag, filtreres. Krypteringslaget over spiller ingen rolle; resolveren fanger opp før krypteringsforhandlingen starter.
- Den er sentral. Alle enheter på kontoen din får den samme beskyttelsen fra én konfigurasjonsoppdatering. Ingen behov for å administrere nettleserutvidelser på tvers av enheter.
Det er derfor DNS-verktøy (Pi-hole, NextDNS, AdGuard DNS og vår egen Casper) har blitt det dominerende mønsteret innen personvernfiltrering for forbrukere de siste fem årene. Men effekten er tosidig — når DNS-filtrering feiler, pleier den å gjøre det stille og i stor skala.
Begrensning 1 — Den kan ikke se hva som er inne i den krypterte trafikken
DNS-filtrering opererer på vertsnavn, ikke på URL-er og ikke på nyttelast. Hvis et domene er fullstendig blokkert, blokkeres alle sider og alle endepunkter på det domenet. Hvis et domene er tillatt, tillates alle sider og alle endepunkter på det domenet. Det finnes ingen mellomvei på DNS-laget — når IP-en er løst opp, har resolveren ingen innsikt i hva appen gjør videre.
Dette er greit for det meste av sporingsinfrstrukturen, som bruker dedikerte underdomener: analytics.facebook.com, tag-manager.google.com, events.amplitude.com. Å blokkere underdomenet lar vertsstedet fungere og dreper analysen. Men det er et vanskelig problem når annonser eller sporere kjører på samme domene som legitimt innhold — Instagram leverer både innhold og sponsede innlegg fra Metas egen infrastruktur; YouTube leverer video og pre-roll-annonser fra googlevideo.com; X leverer betalte innlegg fra de samme vertsnavnene som tidslinjen din. DNS-filtrering kan ikke skille dem fra hverandre.
Hva dette betyr i praksis: Casper eliminerer ~80–90 % av annonsene og sporerne du ville støtt på i en typisk uke på en typisk telefon. De resterende 10–20 % er heist av første part og krever en annen tilnærming — vanligvis en nettleserutvidelse på DOM-gjengivingslaget (uBlock Origin i Chrome / Firefox, innebygde Brave Shields, AdGuards Safari-utvidelse) som kan se den gjengitte siden og skjule spesifikke elementer. Vi anbefaler eksplisitt å kjøre begge lag hvis du vil ha størst mulig dekning; Casper dekker nettverkslaget som nettleserutvidelser går glipp av, nettleserutvidelser dekker DOM-laget som DNS går glipp av.
Begrensning 2 — Noen apper omgår system-DNS fullstendig
En voksende liste over apper bruker ikke lenger systemets DNS-resolver — de leveres med egne DNS-over-HTTPS (DoH)- eller DNS-over-TLS (DoT)-implementasjoner som snakker direkte til Cloudflare, Google eller utviklerens egen infrastruktur, og omgår den DNS brukeren har konfigurert.
Firefox gjør dette som standard (Mozillas Trusted Recursive Resolver-program). Chrome gjør det når brukerens eksisterende DNS-resolver er på Googles autodeteksjonsliste. Noen populære Android-apper (Brave, Discord, Signal, flere streaming-apper) leveres med hardkodede DoH-endepunkter. Motivasjonen er generelt personvern — for å hindre DNS-overvåking fra internettleverandøren — men bivirkningen er at bruker-konfigurert DNS-filtrering ikke gjelder for disse appene.
Hva dette betyr i praksis: på iOS er dette sjeldent, og Apples NetworkExtension-rammeverk gir Casper nok kroker til å fange opp de fleste DoH-forsøk på app-nivå. På Android er situasjonen mer rotete — noen apper vil løse opp vertsnavn utenfor vår synlighet. Caspers respons er todelt: (a) vi publiserer en liste over apper med kjent DoH-omgåelsesadferd slik at brukerne vet hva som er utenfor filteret, og (b) på Android bruker vi VPN-ruting per app for å tvinge kritisk trafikk tilbake gjennom system-DNS-stien for de appene der du spesifikt ønsker filtrering. Dette er ett av de få stedene der Androids mer fleksible VPN-arkitektur genuint er en fordel fremfor iOS.
Begrensning 3 — CDN-er og delt infrastruktur gjør blokkering per leietaker umulig
Mange nettsteder og tjenester deler vertsnavn på IP-nivå — cdn-namespace.cloudfront.net kan levere innhold for tusenvis av ulike organisasjoner bak det samme Cloudfront-endepunktet. Å blokkere vertsnavnet blokkerer alle som deler det; å tillate det tillater alle som deler det. DNS-resolveren har ingen måte å vite hvilken leietaker en spesifikk forespørsel er ment for.
Det vanligste tilfellet der dette er et problem: blokkering av Googles sporingsendepunkter mens Googles funksjonelle endepunkter tillates. googletagmanager.com er rent sporing og kan blokkeres trygt. Men googleapis.com er vert for alt fra Kart-fliser til Cloud Storage til Firebase Auth ved siden av Analytics-innsamling — å blokkere det ville ødelegge en stor andel av apper. Caspers standard blokkliste er innstilt til å la delte funksjonelle endepunkter være åpne mens dedikerte sporingsendepunkter blokkeres, men det er et hardt tak på hvor granulert dette kan bli uten å ødelegge apper.
Hva dette betyr i praksis: noen sporingssignaler slipper gjennom fordi det underliggende vertsnavnet er for tett sammenvevd med legitim funksjonalitet til å blokkeres. Vi lister de viktigste tilfellene i støttedokumentasjonen slik at du vet hva som slipper gjennom. For brukere som ønsker strengere blokkering — med forståelse for at noen apper kan slutte å fungere — er et «aggressivt» forhåndsinnstilt alternativ tilgjengelig.
Begrensning 4 — Encrypted Client Hello (ECH) endrer observabiliteten
TLS-håndtrykket lekket historisk sett destinasjonsvertsnavnet via Server Name Indication (SNI)-feltet — selv når DNS var kryptert, kunne en observatør på nettverket se hvilke nettsteder du koblet til. IETFs Encrypted Client Hello (ECH)-standard krypterer denne siste biten, og den rulles ut bredt i 2025–2026 (Cloudflare aktiverte det som standard i slutten av 2024, Firefox støtter det stabilt, Chrome er i gradvis utrulling).
For personvernet er dette genuint bra — internettleverandøren kan ikke lenger se hvilke nettsteder du besøker, selv på TLS-nivå. For DNS-filtrering endrer det ingenting direkte: vi opererer på selve DNS-oppslaget, ikke på TLS-observasjon. Men ECH er del av en bredere trend mot mer kryptert DNS (DoH/DoT/ODoH/Oblivious DNS) der brukere delegerer resolver-funksjonen til tredjeparter, noen ganger uten å være klar over det. Denne delegeringen kan rute rundt bruker-konfigurerte filtreringsverktøy.
Hva dette betyr i praksis: personvern-stakken for forbrukere fragmenteres. Apples iCloud Private Relay ruter kryptert trafikk gjennom Apples resolvere (og omgår bruker-DNS). DoH som standard i noen nettlesere gjør det samme. ECH er bra for personvernet mot passive observatører, men reduserer brukerens kontroll over egen trafikk. Caspers respons er å gi den nettverksnivå-synligheten brukerne ønsker, der de faktisk ønsker den (i sin egen filtrerende resolver), og å integrere seg med — ikke kjempe mot — de bredere krypteringstrendene.
Der DNS-filtrering fortsatt vinner
Å nevne begrensningene betyr ikke at DNS-filtrering er et dårlig valg — det betyr bare en ærlig diskusjon. Tilfellene der det fortsatt er den reneste intervensjonen:
- Adferdssporing fra innebygde SDK-er. Facebook SDK, Mixpanel, Amplitude, Segment, AppsFlyer — alle bruker dedikerte sporings-vertsnavn som DNS-filtrering blokkerer rent. Dette er den største kategorien i volum og den brukerne oftest ønsker stoppet. Caspers sporerblokkering dekker dette direkte.
- Annonsenettverket på tvers av alle apper. DoubleClick, AdMob, de store annonsenettnettverks-innsamlingsendepunktene bruker alle dedikerte vertsnavn. Å blokkere dem stilner annonser inne i den lange halen av mobilapper der nettleserutvidelser ikke kjører. Se hvordan dette fungerer i praksis.
- Phishing- og skadevare-domener. Sanntids trusselvurdering på DNS-laget fanger zero-day-phishing-domener før de legges til offentlige blokklister. Dette er laget der AI-klassifisereren i Caspers trusselbeskyttelse gjør seg gjeldende — dekket i detalj i vår gjennomgang av tre virkelige phishing-kampanjer.
- Tverrapp-fingeravtrykkseksfiltrering. Selv når iOS App Tracking Transparency stopper IDFA, eksfiltrerer apper fortsatt fingeravtrykksdata — men de må sende det et sted. DNS-laget fanger eksfiltrasjonen uavhengig av hvilken identifikator appen ellers ville ha brukt. Se vår dypere gjennomgang av hva ATT ikke stopper.
- OEM- og operativsystem-telemetri. Samsung Knox-analyse, Xiaomi-sky, Apples analyseendepunkter, Windows-telemetri — alle bruker dedikerte vertsnavn som DNS-filtrering blokkerer uten å ødelegge de funksjonelle delene av operativsystemet.
- Beskyttelse mot fiendtlige nettverk (offentlig WiFi). VPN-tunnelen som bærer DNS-trafikken, krypterer også alt annet som flyter over det lokale nettverket — så selv når DNS-filtreringsfordelen er liten, er krypteringsfordelen på kaffebar-WiFi reell.
Tolagsmodellen som faktisk fungerer
For brukere som ønsker den mest grundige beskyttelsen, er mønsteret som fungerer best to komplementære lag:
- Nettverkslag (DNS-filter): dekker alle apper på enheten, blokkerer de ~80–90 % av sporer-/annonse-/phishing-trafikken som bruker dedikerte vertsnavn. Casper befinner seg her.
- DOM-lag (nettleserinnholdsblokkerer): uBlock Origin i Chrome / Firefox, innebygde Brave Shields, eller AdGuards Safari-utvidelse. Fanger de første-parts-hostede annonsene på Instagram, YouTube, X og lignende som DNS ikke kan skille fra legitimt innhold.
Hvert lag dekker hullene det andre ikke kan. Sammen gir de 95 %+ dekning; hvert for seg er det nærmere 80 %. De fleste personvernbevisste brukerne vi har snakket med kjører nøyaktig dette paret.
Konklusjon
DNS-filtrering er rett sted å intervenere for den største andelen av personverntrusler mot forbrukere — innebygd SDK-sporing, eksfiltrering via annonsenettverk, phishing-domeneoppslag, OEM-telemetri. Det er ikke magi, og det dekker ikke alle tilfeller. De fire begrensningene ovenfor er reelle, og enhver leverandør som skjuler dem, selger enten dårlig eller selger noe de ikke burde. Par nettverkslaget med et nettleser-DOM-lag for de gjenværende tilfellene, behandle kryptering mot fiendtlige nettverk som en separat gevinst du får med på kjøpet, og du har dekket det meste av det en 2026-forbruker-trusselflate ser ut som.