Cos'è un DNS leak — e come testarlo in modo efficace

In breve: un tunnel VPN cifra i pacchetti IP che il tuo dispositivo invia agli altri server. DNS è la risoluzione che avviene prima che il pacchetto venga inviato — il tuo dispositivo chiede "qual è l'indirizzo IP di example.com?" Se questa richiesta va al resolver del tuo ISP invece di passare attraverso il VPN, allora il tuo ISP vede il dominio anche se non vede mai il traffico cifrato che segue. Questo è un leak. Vanifica la principale promessa di privacy di un VPN per il motivo più semplice possibile: è stato interrogato il resolver DNS sbagliato. La buona notizia è che i leak sono facili da rilevare, di solito facili da correggere, e la maggior parte delle app VPN ben costruite li previene per impostazione predefinita. La cattiva notizia è che "la maggior parte" non significa "tutte", e alcune configurazioni comuni causano leak anche su configurazioni VPN altrimenti corrette.

Cosa fa realmente il DNS e perché si verifica il leak

DNS — il Domain Name System — è la rubrica di indirizzi di internet. Ogni volta che il tuo dispositivo si connette a un sito web, deve prima tradurre il nome host leggibile dall'uomo (example.com) in un indirizzo IP numerico (qualcosa come 93.184.216.34) che i router possono effettivamente instradare. Questa fase di traduzione è una query DNS, ed è un'operazione di rete separata dalla richiesta web vera e propria che segue.

Con una tipica connessione domestica, il tuo resolver DNS viene assegnato dal tuo ISP tramite DHCP — lo stesso meccanismo che distribuisce il tuo indirizzo IP. Quando ti connetti al Wi-Fi, il router dice al tuo dispositivo "il tuo server DNS è 192.168.1.1, che inoltra al resolver ricorsivo del tuo ISP". Ogni dominio che cerchi passa attraverso quel resolver. L'ISP può registrarlo, venderlo a un data broker (negli Stati Uniti questo è legale), o consegnarlo alle forze dell'ordine.

Quando connetti un VPN, dovrebbero accadere due cose. Prima, il traffico di rete viene cifrato e instradato attraverso il tunnel VPN. Seconda, il tuo resolver DNS dovrebbe cambiare — dal resolver dell'ISP a uno gestito dal provider VPN (o da un resolver pubblico orientato alla privacy), raggiungibile solo attraverso il tunnel cifrato. Se avviene solo la prima metà, hai un DNS leak. Il traffico è cifrato ma le richieste che precedono il traffico fluiscono comunque all'ISP, informandolo di ogni sito che stai per visitare.

Dal punto di vista della privacy, la query DNS è quasi altrettanto rivelatrice del traffico stesso. La query rivela il dominio esatto (fino al sottodominio — mail.example.com è distinguibile da www.example.com) e i tempi. Combinato con il volume del traffico cifrato immediatamente successivo, un VPN con DNS leak fornisce a un osservatore metadati sufficienti per ricostruire la tua sessione di navigazione in quasi tutti i modi significativi.

I quattro modi in cui si verifica un DNS leak

I DNS leak non sono un singolo bug. Sono una famiglia di configurazioni errate correlate, ognuna con una causa radice diversa e una correzione diversa. In ordine approssimativo di frequenza:

1. Bypass del sistema operativo — Windows split DNS / Smart Multi-Homed Name Resolution

Windows ha una funzionalità chiamata Smart Multi-Homed Name Resolution che, quando abilitata, invia query DNS in parallelo a tutti i resolver DNS disponibili — incluso il resolver dell'ISP sull'interfaccia fisica, anche quando è attivo un VPN. Vince il resolver che risponde più velocemente, e gli altri vengono ignorati, ma le query stesse sono già state inviate. Sulla maggior parte delle macchine Windows questa funzionalità è attiva per impostazione predefinita. La correzione consiste nel disabilitare la funzionalità tramite Criteri di gruppo o configurando il client VPN in modo che lo faccia alla connessione. Linux ha un problema simile con systemd-resolved se non configurato correttamente; macOS e iOS gestiscono questo meglio ma non perfettamente.

2. Configurazione errata dello split tunneling

Lo split tunneling consente di instradare alcune app attraverso il VPN e altre attraverso la connessione normale. Un errore di configurazione comune consiste nel configurare lo split tunneling basato su app senza configurare anche il DNS per app — il che significa che un'app instradata fuori dal tunnel VPN cerca comunque di usare il resolver DNS del VPN, o viceversa, e finisce per fare leak attraverso qualsiasi percorso fornito dal sistema operativo. Una variante peggiore: il split tunnel instrada correttamente il traffico TCP dell'app fuori dal tunnel, ma il resolver DNS a livello di sistema operativo è ancora quello dell'ISP, quindi ogni app — con o senza tunnel — fa leak delle proprie query DNS all'ISP. Approfondiamo l'argomento nel nostro articolo su cosa fa effettivamente lo split tunneling.

3. Fallback IPv6

Molti client VPN sono stati progettati quando IPv4 era l'unica preoccupazione di routing. Installano regole firewall e di routing IPv4 che instradano correttamente il DNS attraverso il tunnel, ma non installano le corrispondenti regole IPv6. Se la tua rete ha connettività IPv6, il sistema operativo a volte preferisce IPv6 per le query DNS — e quelle query escono sull'interfaccia non protetta, bypassando completamente il VPN. Questa è una delle modalità di leak più comuni nel 2026 ed è particolarmente comune sulle connessioni a banda larga residenziale con dual-stack IPv4/IPv6 dell'ISP. La correzione consiste nel disabilitare IPv6 globalmente (drastico ma affidabile), oppure nell'usare un client VPN che gestisce esplicitamente le route IPv6.

4. WebRTC e DNS risolto dal browser

I browser moderni — Chrome, Edge, Firefox, Safari — possono eseguire ricerche DNS autonomamente invece di usare il resolver del sistema operativo. Il caso più noto è WebRTC, il protocollo peer-to-peer usato per le videochiamate. WebRTC usa server STUN per scoprire i tuoi indirizzi IP locali e pubblici reali, e storicamente trasmetteva entrambi anche quando un VPN era attivo. L'IP "reale" esposto tramite WebRTC è stato a lungo un leak lato browser che richiede una mitigazione esplicita. Separatamente, i browser che usano DNS-over-HTTPS (DoH) possono instradare le query DNS direttamente a Cloudflare, Google o NextDNS indipendentemente dall'impostazione del resolver di sistema — il che a volte aiuta (DoH verso un resolver pubblico è più privato del testo in chiaro verso l'ISP) e a volte è controproducente (il resolver pubblico vede comunque le tue query, e il browser sta bypassando le regole DNS del VPN).

Come testare un DNS leak in meno di un minuto

Testare un DNS leak richiede più tempo per descriverlo che per farlo. Connetti il tuo VPN, quindi visita uno di questi tre strumenti. Ognuno rivela aspetti leggermente diversi della superficie di leak.

dnsleaktest.com

Il classico. Visita dnsleaktest.com, clicca su "Extended test" e attendi circa 20 secondi. Lo strumento emette una serie di query DNS per hostname univoci che controlla, poi mostra quali resolver hanno effettivamente eseguito quelle ricerche. Se vedi il nome del tuo ISP (Comcast, Verizon, BT, ecc.) nell'elenco dei resolver, stai subendo un leak. Se vedi solo il resolver del provider VPN (o un resolver pubblico orientato alla privacy come Quad9 o 1.1.1.1 di Cloudflare), il percorso DNS del sistema operativo è corretto.

browserleaks.com/dns

Più dettagliato di dnsleaktest. Mostra non solo quali resolver hanno gestito la query, ma anche la loro posizione geografica, l'ASN (l'operatore di rete) e se supportano DNS-over-HTTPS o DNS-over-TLS. Utile per individuare leak sottili in cui viene usato il tipo corretto di resolver ma si trova nel paese sbagliato, o per confermare che è effettivamente in uso un protocollo DNS cifrato.

ipleak.net

Il più completo — testa i DNS leak, i WebRTC leak, la visibilità IPv4 e IPv6, e mostra come appare la tua geolocalizzazione. La sezione WebRTC è fondamentale: se vedi un indirizzo IP "locale" nell'intervallo 192.168.x.x o 10.x.x.x esposto insieme a un IP "pubblico" che corrisponde all'endpoint del tuo VPN, il tuo VPN sta facendo il suo lavoro ma il browser sta subendo un leak tramite WebRTC. La sezione IPv6 individua i leak da fallback IPv6 che dnsleaktest a volte non rileva.

Come appare un risultato pulito rispetto a uno con leak

Nel test esteso di dnsleaktest.com con un VPN correttamente configurato, dovresti vedere qualcosa del genere:

Test results (clean): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 1.2.3.5 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Conclusion: No DNS leak detected. All queries went to the VPN's resolver.

Ed ecco come appare un leak:

Test results (leaking): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 75.75.75.75 Hostname: cdns01.comcast.net ISP: Comcast Country: United States Server: 75.75.76.76 Hostname: cdns02.comcast.net ISP: Comcast Country: United States Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.

Il segnale chiave è la colonna ISP. Se appare qualcosa di diverso dal tuo provider VPN (o da un resolver pubblico scelto intenzionalmente), il tuo DNS sta subendo un leak. Se la colonna paese mostra il tuo paese reale insieme al paese di uscita del VPN, stai subendo un leak. Se appare solo il paese dell'endpoint del VPN, sei al sicuro.

Confronto tra i tipi di leak

Ognuno dei quattro tipi di leak ha un'impronta digitale distinta nei risultati del test, un insieme distinto di osservatori che possono sfruttarlo e una correzione distinta:

Correggere le quattro cause comuni

Correggere i leak da bypass del sistema operativo (Windows)

Su Windows 10 e 11, disabilita Smart Multi-Homed Name Resolution tramite Criteri di gruppo (Configurazione computer → Modelli amministrativi → Rete → Client DNS → "Disattiva la risoluzione dei nomi multihomed smart" → Abilitato) oppure tramite PowerShell: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Riavvia. Alcuni client VPN ben mantenuti lo fanno automaticamente alla connessione — se il tuo non lo fa, fallo manualmente.

Correggere i leak da split tunnel

Verifica il tuo insieme di regole per lo split tunnel. Per ogni app che dovrebbe essere protetta, verifica che sia il traffico TCP che le sue query DNS vengano instradate attraverso il tunnel. Alcuni client VPN consentono di configurare il DNS per app; la maggior parte no. Se il tuo non lo consente, l'impostazione predefinita più sicura è disabilitare completamente lo split tunneling e usare un tunnel completo — che instrada tutto (incluso tutto il DNS) attraverso il VPN. Per la maggior parte degli utenti, il vantaggio in termini di comodità dello split tunneling non vale il rischio di leak.

Correggere i leak IPv6

La correzione più affidabile consiste nell'usare un client VPN che supporta IPv6 all'interno del tunnel (o che come minimo installa regole firewall IPv6 corrispondenti che bloccano il traffico IPv6 quando il tunnel è attivo). Se non puoi cambiare client, disabilita IPv6 sull'interfaccia di rete fisica: su Windows, nelle proprietà dell'adattatore; su macOS, in Impostazioni di Sistema → Rete → Avanzate → TCP/IP. È una misura drastica (perdi completamente la connettività IPv6) ma elimina il vettore di leak.

Correggere i leak WebRTC

In Firefox, imposta media.peerconnection.enabled su false in about:config. In Chrome e Edge, installa un'estensione come WebRTC Network Limiter o l'opzione di blocco WebRTC di uBlock Origin. Safari gestisce WebRTC in modo più conservativo per impostazione predefinita, ma puoi comunque subire leak di IP locali in alcune configurazioni; Safari 17+ ha migliorato significativamente questo aspetto. Esegui il test dopo la modifica con ipleak.net.

Perché "usare un VPN" da solo non garantisce l'assenza di leak

C'è un'assunzione comune che la connessione a un VPN prevenga automaticamente i DNS leak. Non è così — la prevenzione dipende dal fatto che il client VPN faccia una serie di cose correttamente: cambiare il resolver DNS di sistema, installare regole firewall per bloccare il DNS diretto all'ISP, gestire IPv6, disabilitare Windows SMHNR (o funzionalità di bypass equivalenti a livello di sistema operativo) e sopravvivere ai cambiamenti di rete (roaming Wi-Fi, cicli di sospensione/riattivazione) senza reintrodurre il leak.

Un client VPN ben costruito fa tutto questo automaticamente e non devi mai preoccuparcene. Uno mal costruito — o un VPN "gratuito" che usa il profilo VPN integrato del sistema operativo senza alcuna protezione aggiuntiva contro i leak — fa solo un sottoinsieme di queste cose, lasciando aperti vettori di leak. L'unico modo per sapere in quale categoria ti trovi è eseguire effettivamente un test di leak dopo la connessione. Se il test risulta pulito, puoi smettere di preoccupartene; se mostra leak, hai problemi specifici da correggere e ora sai quali sono.

Prevenzione dei DNS leak su iOS, Android, Mac e Windows

iOS

iOS gestisce il DNS attraverso il framework NetworkExtension. Un'app VPN correttamente costruita usa l'oggetto NEDNSSettings per specificare un resolver personalizzato che viene usato mentre il tunnel è attivo. iOS lo applica a livello di sistema operativo — le app non possono bypassare il DNS configurato senza autorizzazione esplicita. Il principale vettore di leak su iOS è iCloud Private Relay, che (se abilitato insieme a un VPN) può instradare il DNS attraverso il resolver di Apple invece di quello del VPN. Se usi un VPN per la privacy, disabilita iCloud Private Relay per evitare conflitti tra i due. iOS 14 ha aggiunto il flag includeAllNetworks (spesso usato insieme al comportamento kill switch) che assicura che anche il DNS a livello di sistema passi attraverso il tunnel.

Android

L'API VpnService di Android consente al client VPN di specificare server DNS che si applicano a tutto il traffico nel tunnel. L'impostazione di sistema "VPN sempre attiva" con "Blocca connessioni senza VPN" abilitato offre la garanzia più forte — nessuna app può risolvere il DNS senza che il tunnel sia attivo. Android supporta anche il DNS privato a livello di sistema (Impostazioni → Rete e internet → DNS privato), che forza tutto il DNS a usare DNS-over-TLS verso un provider scelto. Combinare VPN sempre attiva con DNS privato offre una protezione doppia contro i DNS leak.

macOS

macOS usa scutil e il framework System Configuration per gestire le impostazioni DNS. Un client VPN che funziona attraverso il framework NetworkExtension può installare impostazioni DNS che hanno la precedenza mentre il tunnel è attivo. Il principale vettore di leak su macOS è il DNS-over-HTTPS a livello di browser, che bypassa completamente il resolver di sistema — disabilita il DoH a livello di browser o configuralo in modo che punti allo stesso resolver del VPN. Esegui il test con scutil --dns nel Terminale per vedere i resolver attivi; solo il resolver del VPN dovrebbe apparire nella sezione a priorità più alta.

Windows

Windows ha la maggiore superficie di leak di qualsiasi sistema operativo principale, principalmente a causa di Smart Multi-Homed Name Resolution. Oltre a disabilitare SMHNR (illustrato sopra), verifica che l'adattatore virtuale del VPN abbia una priorità metrica più alta rispetto all'adattatore fisico, che IPv6 sia disabilitato o correttamente nel tunnel, e che nessuna app sia configurata con le proprie sostituzioni DNS. Windows 11 ha aggiunto un'interfaccia utente migliorata per le impostazioni DNS, ma il comportamento sottostante è simile a Windows 10. Il comando ipconfig /all mostra i resolver attivi per interfaccia.

Cosa fanno i buoni client VPN per prevenire i leak

Un client VPN ben progettato non ti chiede di preoccuparti dei DNS leak. Li gestisce come parte fondamentale del processo di connessione. In particolare:

• Configura un resolver personalizzato alla connessione. Il client dice al sistema operativo "mentre sono connesso, tutte le query DNS vanno a questo indirizzo IP specifico" — tipicamente il resolver del provider VPN, raggiungibile solo attraverso il tunnel. Il client ripristina anche le impostazioni DNS precedenti alla disconnessione.
• Installa regole firewall per bloccare il DNS diretto. Anche se qualche app tenta di interrogare un server DNS autonomamente (ad es. una query con destinazione hardcoded 8.8.8.8), la regola del firewall blocca il pacchetto in uscita sulla porta UDP 53. L'unico DNS che può lasciare il dispositivo è quello che scorre attraverso il tunnel.
• Usa DNS cifrato (DoT o DoH) all'interno del tunnel. Anche dopo che la query è dentro il tunnel, il collegamento resolver-server è cifrato con DNS-over-TLS (RFC 7858) o DNS-over-HTTPS, in modo che l'operatore upstream non possa vedere il contenuto della query. Il nostro articolo su DNS-over-HTTPS vs DNS-over-TLS illustra i compromessi tra i due protocolli.
• Gestisce IPv6 esplicitamente. Le route IPv6 vengono instradate attraverso il VPN (preferibile) o bloccate dal firewall per prevenire il fallback IPv6. Il client non lascia mai il routing IPv6 non configurato.
• Si abbina a un kill switch. Se il tunnel cade momentaneamente, il kill switch blocca tutto il traffico — incluso il DNS — finché il tunnel non si ristabilisce. Questo previene la race condition "tunnel caduto, DNS in leak, tunnel ripristinato". Lo approfondiamo in dettaglio in cos'è un VPN kill switch.
• Esegue test ad ogni connessione. Alcuni client eseguono un test di leak integrato dopo ogni connessione, segnalando eventuali anomalie all'utente. È raro ma è il modello più robusto possibile.

Casper's Cloak usa un resolver DNS personalizzato raggiungibile solo all'interno del tunnel WireGuard, cifrato end-to-end tramite DNS-over-TLS, con route IPv6 esplicitamente nel tunnel e Windows SMHNR disabilitato al momento dell'installazione. La funzionalità di protezione dalle minacce esegue il filtraggio a livello DNS contro i domini noti come malevoli sullo stesso resolver, quindi lo stesso DNS protetto dai leak filtra attivamente anche il phishing e il malware. Il meccanismo è documentato nel nostro articolo su come funziona il filtraggio a livello DNS. L'effetto combinato: configurato correttamente per impostazione predefinita, nessun leak sotto nessuna delle quattro modalità di errore comuni, e filtraggio attivo come strato aggiuntivo.

Per il contesto sul protocollo sottostante, la specifica IETF di DNS-over-TLS è documentata in RFC 7858, che copre i requisiti crittografici e a livello di trasporto per l'invio di DNS su un canale protetto da TLS. Lo stesso framework è quello usato dai resolver pubblici orientati alla privacy (Cloudflare, Quad9, NextDNS) per i loro endpoint DNS sicuri.

In sintesi: un DNS leak è il modo più comune in cui la promessa di privacy di un VPN viene silenziosamente tradita. È facile da testare, di solito facile da correggere, e qualsiasi VPN di cui ti fidi dovrebbe superare un test di leak senza intervento manuale. Se il tuo VPN non lo fa, è un segnale — o c'è una configurazione errata, o è il momento di cambiare.