Come funziona davvero il filtraggio DNS — e i quattro limiti che i vendor non pubblicizzano

La versione breve: quando un'app sul tuo telefono cerca di connettersi a analytics.facebook.com, deve prima risolvere l'indirizzo IP di quel hostname tramite DNS. Un resolver DNS con filtraggio intercetta la richiesta, riconosce la destinazione come un tracker e rifiuta di restituire un IP. La connessione non si apre mai; i dati non lasciano mai il tuo dispositivo. È un meccanismo elegante e potente — ma ha quattro limiti che ogni discussione onesta deve citare: non può vedere il contenuto del traffico cifrato, non può filtrare gli annunci serviti dallo stesso dominio dei contenuti legittimi, alcune app aggirano completamente il DNS di sistema, e i protocolli DNS cifrati (DoH/DoT/ECH) stanno cambiando il panorama dell'osservabilità di rete. Di seguito: il meccanismo, poi ogni singolo limite, poi dove il filtraggio DNS rimane vincente.

Il meccanismo, in cinque passaggi

Ogni connessione di rete che il tuo telefono effettua passa attraverso questa sequenza (che tu lo noti o meno):

1. Un'app vuole raggiungere un server. Instagram vuole caricare una storia; Facebook SDK vuole inviare un'impronta digitale; Safari sta aprendo una pagina web. Ognuno di questi inizia con un hostname — graph.facebook.com, cdn-news.com, www.example.com.
2. Il sistema operativo chiede al DNS l'IP dell'hostname. I computer non parlano direttamente con graph.facebook.com — parlano con 157.240.22.174. Il DNS è la rubrica che traduce gli hostname in IP.
3. La query DNS viaggia verso un resolver. Senza VPN, di solito è il resolver del tuo ISP o qualunque DNS tu abbia configurato (tipicamente 8.8.8.8 di Google o 1.1.1.1 di Cloudflare). Con Casper o un altro strumento di filtraggio DNS, la query viaggia verso il nostro resolver, tramite il tunnel cifrato.
4. Il resolver con filtraggio valuta la destinazione. graph.facebook.com è nella blocklist dei tracker? Ha una classificazione ML come dominio di phishing? È in una allowlist personalizzata dell'utente? La valutazione avviene in pochi millisecondi.
5. Il resolver restituisce una risposta — o si rifiuta. Per i domini legittimi: un IP reale, l'app si connette, tutto procede. Per i domini bloccati: una risposta "NXDOMAIN" o 0.0.0.0, il tentativo di connessione dell'app fallisce e i dati non lasciano mai il dispositivo.

Questo è l'intero meccanismo. Non ci sono trucchi DPI sul dispositivo, non ci sono hook kernel, nessun gioco di prestigio con l'iniezione di certificati. Funziona perché ogni connessione IP deve iniziare con una risoluzione di hostname, e la risoluzione è testo in chiaro non cifrato che il resolver controlla. Rifiuta la risoluzione, rifiuta la connessione.

Perché questo approccio ha una leva insolita

Tre caratteristiche strutturali rendono il filtraggio DNS sproporzionatamente efficace:

• È indipendente dall'app. Le estensioni del browser proteggono solo il browser in cui sono installate. I content blocker di Safari proteggono solo Safari. Il filtro DNS di Casper protegge Instagram, l'app YouTube, il widget meteo, l'app di streaming sulla smart TV, Mail, Slack, ogni utility nella barra dei menu su Mac — qualsiasi cosa effettui una risoluzione DNS.
• È indipendente dal protocollo. HTTP, HTTPS, WebSocket, protocolli binari personalizzati — qualsiasi cosa inizi con una risoluzione DNS viene filtrata. Il livello di cifratura superiore non ha importanza; il resolver intercetta prima che inizi la negoziazione della cifratura.
• È centralizzato. Ogni dispositivo sul tuo account riceve la stessa protezione da un unico aggiornamento di configurazione. Nessuna gestione distribuita di estensioni browser.

È per questo che gli strumenti DNS (Pi-hole, NextDNS, AdGuard DNS e il nostro Casper) sono diventati il modello dominante nel filtraggio della privacy dei consumatori negli ultimi cinque anni. Ma la leva taglia in entrambe le direzioni — quando il filtraggio DNS fallisce, tende a farlo in silenzio e su larga scala.

Limite 1 — Non può vedere il contenuto del traffico cifrato

Il filtraggio DNS opera sugli hostname, non sugli URL né sui payload. Se un dominio è completamente bloccato, ogni pagina e ogni endpoint su quel dominio è bloccato. Se un dominio è completamente permesso, ogni pagina e ogni endpoint su quel dominio è permesso. Non c'è una via di mezzo a livello DNS — una volta risolto l'IP, il resolver non ha visibilità su ciò che l'app fa in seguito.

Questo va bene per la maggior parte dell'infrastruttura di tracciamento, che usa sottodomini dedicati: analytics.facebook.com, tag-manager.google.com, events.amplitude.com. Bloccare il sottodominio lascia funzionante il sito host e uccide gli analytics. Ma è un problema difficile quando annunci o tracker condividono lo stesso dominio dei contenuti legittimi — Instagram serve sia contenuti che post sponsorizzati dall'infrastruttura di Meta; YouTube serve video e annunci pre-roll da googlevideo.com; X serve tweet promossi dagli stessi hostname della tua timeline. Il filtraggio DNS non riesce a distinguerli.

Cosa significa in pratica: Casper blocca circa l'80–90% degli annunci e dei tracker che incontreresti in una settimana tipica su un telefono tipico. Il restante 10–20% è ospitato in first-party e richiede un intervento diverso — di solito un'estensione browser a livello di rendering DOM (uBlock Origin in Chrome/Firefox, Brave Shields integrato, l'estensione Safari di AdGuard) che può vedere la pagina renderizzata e nascondere elementi specifici. Raccomandiamo esplicitamente di usare entrambi i livelli se vuoi la massima copertura; Casper copre il livello di rete che le estensioni browser non raggiungono, le estensioni browser coprono il livello DOM che il DNS non raggiunge.

Limite 2 — Alcune app aggirano completamente il DNS di sistema

Un numero crescente di app non usa più il resolver DNS di sistema — implementano il proprio DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT) che comunica direttamente con Cloudflare, Google o l'infrastruttura dello sviluppatore, aggirando qualunque DNS l'utente abbia configurato.

Firefox lo fa per impostazione predefinita (il programma Trusted Recursive Resolver di Mozilla). Chrome lo fa quando il resolver DNS esistente dell'utente è nella lista di rilevamento automatico di Google. Alcune app Android popolari (Brave, Discord, Signal, diverse app di streaming) includono endpoint DoH hardcoded. La motivazione è generalmente la privacy — impedire la sorveglianza DNS a livello ISP — ma l'effetto collaterale è che il filtraggio DNS configurato dall'utente non si applica a quelle app.

Cosa significa in pratica: su iOS questo è raro e il framework NetworkExtension di Apple offre a Casper abbastanza hook per intercettare la maggior parte dei tentativi DoH a livello di app. Su Android la situazione è più complessa — alcune app risolvono gli hostname al di fuori della nostra visibilità. La risposta di Casper è duplice: (a) pubblichiamo un elenco delle app con comportamento DoH bypass noto, così gli utenti sanno cosa è fuori dal filtro, e (b) su Android usiamo il routing VPN per-app per forzare il traffico critico di ritorno attraverso il percorso DNS di sistema per quelle app su cui vuoi specificamente il filtraggio applicato. Questo è uno dei pochi casi in cui l'architettura VPN più flessibile di Android è genuinamente un vantaggio rispetto a iOS.

Limite 3 — CDN e infrastrutture condivise rendono impossibile il blocco per tenant

Molti siti web e servizi condividono hostname a livello IP — cdn-namespace.cloudfront.net potrebbe servire contenuti per migliaia di organizzazioni diverse dietro lo stesso endpoint Cloudfront. Bloccare l'hostname blocca tutti coloro che lo condividono; permetterlo permette a tutti coloro che lo condividono. Il resolver DNS non ha modo di sapere a quale tenant è destinata una specifica richiesta.

Il caso più comune in cui questo è un problema: bloccare gli endpoint di tracciamento di Google mantenendo funzionanti gli endpoint funzionali di Google. googletagmanager.com è puramente tracking e può essere bloccato in sicurezza. Ma googleapis.com ospita di tutto, dai tile di Maps allo Cloud Storage a Firebase Auth, insieme all'ingestion di Analytics — bloccarlo romperebbe una grande frazione di app. La blocklist predefinita di Casper è calibrata per lasciare aperti gli endpoint condivisi funzionali bloccando gli endpoint dedicati al tracking, ma c'è un limite massimo a quanto può diventare granulare senza rompere le app.

Cosa significa in pratica: alcuni segnali di tracciamento passano perché l'hostname sottostante è troppo intrecciato con funzionalità legittime per essere bloccato. Elenchiamo i casi principali nella nostra documentazione di supporto così sai cosa sfugge. Per gli utenti che vogliono un blocco più restrittivo con la consapevolezza che alcune app potrebbero smettere di funzionare, è disponibile un preset "aggressivo".

Limite 4 — Encrypted Client Hello (ECH) sta cambiando l'osservabilità

L'handshake TLS storicamente rivelava l'hostname di destinazione tramite il campo Server Name Indication (SNI) — anche quando il DNS era cifrato, un osservatore sulla rete poteva vedere a quali siti ti stavi connettendo. Lo standard Encrypted Client Hello (ECH) dell'IETF cifra quest'ultimo pezzo ed è in fase di diffusione capillare nel 2025–2026 (Cloudflare lo ha abilitato per impostazione predefinita alla fine del 2024, Firefox lo supporta stabilmente, Chrome è in fase di rollout graduale).

Per la privacy questo è genuinamente positivo — il tuo ISP non può più vedere quali siti visiti nemmeno a livello TLS. Per il filtraggio DNS, non cambia nulla direttamente: operiamo sulla risoluzione DNS stessa, non sull'osservazione TLS. Ma ECH fa parte di una tendenza più ampia verso un DNS più cifrato (DoH/DoT/ODoH/Oblivious DNS) in cui gli utenti delegano la funzione di resolver a terze parti, a volte senza rendersene conto. Questa delega può aggirare gli strumenti di filtraggio configurati dall'utente.

Cosa significa in pratica: lo stack della privacy dei consumatori si sta frammentando. iCloud Private Relay di Apple instrada il traffico cifrato attraverso i resolver di Apple (aggirando il DNS dell'utente). Il DoH predefinito in alcuni browser fa lo stesso. ECH è utile per la privacy dagli osservatori passivi ma riduce il controllo dell'utente sul proprio traffico. La risposta di Casper è fornire la visibilità a livello di rete che gli utenti desiderano nel posto in cui la vogliono davvero (il loro resolver di filtraggio personale) e integrarsi — non combattere — con le tendenze di cifratura più ampie.

Dove il filtraggio DNS vince ancora

Nominare i limiti non significa che il filtraggio DNS sia una cattiva scommessa — significa solo una discussione onesta. I casi in cui rimane l'intervento più pulito:

• Tracciamento comportamentale da SDK incorporati. Facebook SDK, Mixpanel, Amplitude, Segment, AppsFlyer — tutti usano hostname dedicati ai tracker che il filtraggio DNS blocca in modo pulito. Questa è la categoria più grande per volume ed è quella che gli utenti vogliono bloccare di più. Il blocco dei tracker di Casper copre questo direttamente.
• Reti pubblicitarie su tutte le app. DoubleClick, AdMob, i principali endpoint di ingestion delle reti pubblicitarie usano tutti hostname dedicati. Bloccarli silenzia gli annunci nella lunga coda delle app mobile dove le estensioni browser non operano. Scopri come funziona nella pratica.
• Domini di phishing e malware. Il punteggio delle minacce in tempo reale a livello DNS intercetta i domini di phishing zero-day prima che vengano aggiunti alle blocklist pubbliche. Questo è il livello in cui il classificatore AI della protezione dalle minacce di Casper si guadagna il suo posto — descritto in dettaglio nella nostra analisi di tre vere campagne di phishing.
• Esfiltrazione di impronte digitali tra app. Anche quando iOS App Tracking Transparency blocca l'IDFA, le app continuano a esfiltrare dati di impronta digitale — ma devono inviarli da qualche parte. Il livello DNS intercetta l'esfiltrazione indipendentemente dall'identificatore che l'app avrebbe utilizzato. Scopri la nostra analisi approfondita su cosa ATT non ferma.
• Telemetria OEM e del sistema operativo. Samsung Knox analytics, Xiaomi cloud, gli endpoint di analytics di Apple, la telemetria di Windows — tutti usano hostname dedicati che il filtraggio DNS blocca senza rompere le parti funzionali del sistema operativo.
• Protezione su reti ostili (WiFi pubblico). Il tunnel VPN che trasporta il traffico DNS cifra anche tutto il resto che scorre sulla rete locale — quindi anche quando il beneficio del filtraggio DNS è ridotto, il beneficio della cifratura sul WiFi di un bar è reale.

Il modello a due livelli che funziona davvero

Per gli utenti che vogliono la protezione più completa, il modello che funziona meglio è costituito da due livelli complementari:

1. Livello di rete (filtro DNS): copre ogni app sul dispositivo, blocca circa l'80–90% del traffico tracker/annunci/phishing che usa hostname dedicati. Casper si trova qui.
2. Livello DOM (content blocker nel browser): uBlock Origin in Chrome/Firefox, Brave Shields integrato, o l'estensione Safari di AdGuard. Intercetta gli annunci ospitati in first-party su Instagram, YouTube, X e simili che il DNS non riesce a distinguere dai contenuti legittimi.

Ogni livello copre i gap che l'altro non può coprire. Insieme raggiungono una copertura del 95%+; separatamente ci si avvicina all'80%. La maggior parte degli utenti attenti alla privacy con cui abbiamo parlato usa esattamente questa combinazione.

In sintesi

Il filtraggio DNS è il posto giusto dove intervenire per la più grande quota di minacce alla privacy dei consumatori — tracciamento tramite SDK incorporati, esfiltrazione da reti pubblicitarie, risoluzione di domini di phishing, telemetria OEM. Non è magia e non copre ogni caso. I quattro limiti descritti sopra sono reali, e qualsiasi vendor che li nasconde sta vendendo in modo disonesto o vendendo qualcosa che non dovrebbe. Abbina il livello di rete a un livello browser-DOM per i casi residui, considera la cifratura su reti ostili come un beneficio aggiuntivo incluso, e avrai coperto la maggior parte di quello che sembra una superficie di minaccia per i consumatori nel 2026.