DNS con VPN senza problemi: come bloccare le perdite, risolvere i problemi di risoluzione e configurare la cache

Cosa succede davvero al DNS quando usi una VPN: spiegato semplice e senza magie

Come cambia il percorso del traffico quando attivi la VPN

Hai cliccato su Connetti nel tuo client VPN preferito. Sembra semplice: tutto il traffico deve passare nel tunnel. Ma il DNS non sempre si comporta così. Per impostazione predefinita, il sistema operativo decide a chi inviare le richieste di risoluzione dei domini, basandosi sulla lista dei resolver, le priorità delle interfacce e le politiche di sicurezza delle app. La VPN aggiunge un'interfaccia virtuale con una rotta dedicata. Però il browser o i servizi di sistema possono continuare ostinatamente a usare il vecchio DNS fornito dal provider. Ed è lì che nascono perdite e comportamenti strani.

Immagina un’autostrada con una corsia VIP a pagamento. I mezzi pesanti ci entrano. Ma i piccoli, come le richieste DNS, a volte continuano a sbucare dalle vecchie strade. Il motivo è la politica del resolver: alcuni si affidano a quello di sistema, altri usano il DoH integrato, altri ancora non vanno d’accordo con il tunnel. Ma la logica è semplice: se vogliamo privacy e stabilità, serve un percorso unico e prevedibile per il DNS all’interno della VPN.

Nel 2026 la maggior parte dei client WireGuard, OpenVPN e degli agenti SASE aziendali sanno già impostare DNS corretti e bloccare le "fughe" verso l’esterno. Però non esistono miracoli. Se sull’host è attivo un resolver separato con DoH, il browser può continuare a rivolgersi al suo provider cloud. Perciò le regole devono essere chiare: chi comanda, chi obbedisce e dove esattamente volano i pacchetti UDP sulla porta 53, TCP 853 per il DoT e il traffico HTTPS per il DoH.

Perché il DNS è un traffico speciale (e spesso problematico)

Il DNS lavora veloce, silenzioso e spesso. Ogni pagina web fa decine di richieste. Ogni problema o discrepanza si sente subito: il sito non si apre, il contenuto cambia, la geolocalizzazione si sposta senza motivo. Aggiungi la cache a vari livelli (browser, sistema operativo, client VPN, resolver locale, provider) e ottieni un complicato intreccio di timeout e record obsoleti. Quando usi la VPN, combatti anche per la privacy: non vuoi che il provider veda quali domini stai cercando. E la perdita DNS fa proprio questo — trapela, spesso senza che te ne accorga.

In più, il DNS non è solo porta 53. Le varianti criptate DoH e DoT sono ormai uno standard de facto. I browser adorano il DoH. I resolver di sistema su Windows e Linux cifrano sempre più spesso le richieste di default. iOS e Android supportano il Private DNS. Bello, vero? Ma nel contesto VPN si pone la domanda: chi ha il controllo, il tunnel o l’app? Senza uno schema chiaro, è facile perdersi nel labirinto di politiche che si sovrappongono, con tre resolver diversi che convivono nella configurazione finale.

Sintomi: come capire che il DNS fa i capricci a causa della VPN

Caricamenti lenti, timeout strani, a volte funziona, a volte no

Tutti conosciamo la scena. Il sito si apre, ma le immagini non si caricano. O viceversa: la homepage vola, mentre il carrello resta impallato. Attivi la VPN e va un po’ meglio. Dopo cinque minuti, torna peggio. Un classico paradosso DNS. Perché succede? Forse alcune richieste vanno al resolver di sistema, altre al DNS del tunnel. La cache del browser crea situazioni instabili. A volte aiuta un Ctrl+F5, altre no. Fastidioso? Eccome.

Un segnale chiaro: il codice errore DNS_PROBE_FINISHED_NXDOMAIN o SERVFAIL nei controlli diagnostici. Oppure ritardi ripetuti di 1-2 secondi prima di caricare un dominio, soprattutto al primo accesso. Quando il tunnel cambia l’MTU, i pacchetti DNS grandi con EDNS possono frammentarsi e perdersi. Un richiesta passa perché piccola, un’altra fallisce. Altro indicatore: siti con contenuti geolocalizzati. Se rispondono con contenuti inaspettati, probabilmente una parte delle richieste si risolve altrove rispetto a quanto pensiamo.

Non sottovalutare problemi sporadici. Quando tutto si blocca subito è evidente. Ma è ancora più fastidioso quando i malfunzionamenti sono intermittenti. È come un gioco di sterzo con un po’ di gioco: la macchina va, ti abitui, poi improvvisamente finisci fuori strada. Il DNS con VPN a volte si comporta così.

Contenuti e geolocalizzazione che “ballano”: i servizi pensano che tu sia in un altro Paese

Attivi la VPN con uscita, per esempio, nei Paesi Bassi, ma il servizio video mostra la libreria russa, turca o un mix confuso. Come mai? Perdite DNS. Il sito individua la geo non solo dall’IP, ma anche da dove viene risolto il nome CDN. Se la richiesta passa al DNS del provider fuori dal tunnel, il CDN restituirà gli indirizzi più vicini al provider. Il traffico fa una strada più lunga, il contenuto non è giusto e la velocità varia.

Verifica semplice: chiedi da terminale con dig o nslookup quale è l’indirizzo del server nella sezione Server. Se mostra il provider e non il resolver VPN o DoH/DoT scelto, c’è una perdita. Può succedere anche il contrario: sembra tutto cifrato, ma il browser forza il proprio DoH con DDR (Discovery of Designated Resolvers). Così la richiesta passa al “giusto” provider via HTTPS, ma fuori dal tunnel VPN e la geo risulta un mix strano.

Nel 2026 sono sempre più comuni schemi ibridi: le app scelgono da sole il DNS criptato, persino spostandolo su QUIC. Comodo, ma per la VPN crea scenari nuovi di perdite. Perciò è fondamentale gestire le priorità: chi comanda nella catena e a che livello forniamo cifratura e instradamento.

Perdite DNS: come scoprirle e bloccarle senza magie

Verificare le perdite: comandi manuali, utility e domini di controllo

Partiamo dal semplice. Attiva la VPN ed esegui nslookup example.com o dig example.com. Guarda qual è il server indicato nella riga Server o nella sezione SERVER. È il resolver atteso? Per esempio 10.14.0.1 per DNS aziendale dietro il tunnel, o 1.1.1.1/9.9.9.9/8.8.8.8 pubblici ma raggiunti tramite tunnel. Se vedi l’indirizzo del provider, c’è perdita. Se vedi l’indirizzo DoH dentro il browser, ma che esce da Internet bypassando la VPN, anche quella è una perdita, anche se cifrata.

Controlla vari domini: normali, con sottodomini, lunghi (per attivare EDNS e risposte grandi). Confronta le risposte con e senza VPN. Se differenze sono evidenti, probabilmente parte delle richieste va altrove. Puoi usare domini di test come resolver-test o zone inesistenti che mostrano chi risolve: molti provider VPN hanno questi domini interni, controlla la documentazione del tuo servizio o server.

Un trucco utile: attiva il logging sul resolver locale (ad esempio systemd-resolved o dnsmasq) e guarda quali domini passano davvero da lì. Se i log sono vuoti ma le richieste si risolvono, vuol dire che vanno altrove. Su Windows aiuta il pktmon integrato o tracing in PowerShell, su Linux tcpdump con filtro udp port 53 o porte 853/443 per DoT/DoH.

Come bloccare le perdite: politica cliente, regole di sistema e configurazioni app

Il cuore della battaglia è una politica unica. Per OpenVPN su Windows abilita block-outside-dns e register-dns, sul server usa push «dhcp-option DNS X.X.X.X». Per WireGuard indica DNS = 10.14.0.1 (o altro indirizzo) nel profilo client e assicurati che AllowedIPs coprano il traffico verso quel resolver. Se usi split tunneling, inserisci il resolver nella lista delle reti instradate tramite tunnel. E sì, controlla IPv6: spesso le perdite passano da lì, anche se IPv4 è ben bloccato.

Dopodiché affronta le app. Un browser con DoH attivo potrebbe ignorare il resolver di sistema. Allora imposta all’interno del browser un resolver DoH raggiungibile via VPN (ad esempio un DoH aziendale sulla porta 443 dentro il tunnel) o disattiva DoH integrato se la tua privacy si basa sul tunnel. A livello di sistema in Windows usa il DoH di sistema legato all’indirizzo del resolver e abilita Encrypted DNS solo per quel server raggiungibile via VPN. Su Linux con systemd-resolved imposta DNS e Domains per interfaccia wg0 o tun0, attiva DNSSEC e se necessario limita i registri di fallback.

Non dimenticare di bloccare l’UDP 53 in uscita all’esterno mentre la VPN è attiva. È un metodo rude ma efficace. Nessuna richiesta indesiderata potrà uscire. Lo stesso vale per DoT e DoH se vuoi che tutto passi solo dal resolver interno. Configurare è complesso, ma almeno niente sorprese.

Fallimenti di risoluzione: quando i domini non si risolvono mai o a intermittenza

Cause locali: cache, MTU, firewall, priorità interfacce

I problemi più frequenti sono locali. La cache conserva un vecchio record A o AAAA mentre la realtà è cambiata. Così vedi NXDOMAIN mentre un altro PC apre tutto. Soluzione semplice: svuota la cache del browser e la cache DNS di sistema. Su Windows usa ipconfig /flushdns, su macOS dscacheutil -flushcache e killall mDNSResponder, su Linux con systemd resolvectl flush-caches. Se usi un resolver locale (dnsmasq, Unbound), riavvialo. Non sottovalutare questo passaggio: due minuti che possono salvarti ore di nervi.

MTU e frammentazione sono insidiose. Nei tunnel VPN l’MTU è di solito più basso che nella rete fisica. Le risposte DNS grandi con EDNS (come per DNSSEC) possono non passare senza frammentazione e perdersi in un router troppo zelante. Vedi timer di timeout o SERVFAIL. Prova a ridurre l’MTU del tunnel (tipo 1280-1380 per WireGuard) o disabilita temporaneamente l’EDNS tuning per testare. Semplice? Sì, ma funziona, sia a casa che in ufficio.

La priorità delle interfacce decide quale resolver viene scelto per primo. Se l’interfaccia virtuale VPN non ha metriche più alte, il sistema continua a usare il Wi-Fi con il vecchio DNS. Controlla l’elenco degli adattatori, le metriche e l’ordine. Su Windows nelle proprietà avanzate dell’adattatore o via PowerShell, su Linux in routing table e configurazioni resolved. Il firewall? A volte regole locali bloccano l’UDP 53 sui nuovi adattatori. Controlla esplicitamente.

Cause di rete e protocollo: DoH, DoT, IPv6, DNSSEC e EDNS

La parte protocollare è più sottile. Se forzi il DoT verso un resolver esterno ma il tunnel blocca la porta TCP 853 o richiede proxy interna, le richieste falliscono. Stesso per DoH: il traffico HTTPS verso il resolver cloud può passare fuori dal tunnel se l’app non eredita le rotte correttamente. Nel 2026 molti client legano DoH all’interfaccia VPN, ma non tutti. Prova pratica: abilita solo il tunnel, disabilita l’uscita e controlla se DoH risponde ancora.

IPv6 è un capitolo a parte. Pensi a IPv4, ma il sistema risolve e naviga silenziosamente su v6. Se la VPN non instrada IPv6 o non assegna indirizzo resolver v6, alcune richieste falliscono. Due soluzioni: o disattivi IPv6 in fase di test, o lo configuri bene nel tunnel con resolver e prefissi. Occhio a DNSSEC: con frammentazioni errate e MTU sbagliato la validazione si rompe. Con EDNS a volte serve ridurre bufsize o attivare meccanismi anti-frammentazione per far arrivare le risposte senza perdita.

C’è anche ECH: encryption del ClientHello in TLS che nasconde SNI. Non influisce direttamente sul DNS, ma combinato con DoH e politiche di intercettazione può modificare l’instradamento delle richieste HTTPS del resolver. Morale: controlla tutta la catena — dal resolver di sistema all’interfaccia tunnel. Così riduci le sorprese.

Cache DNS: qual è la trappola e come domarla

Dove vive la cache: browser, sistema, resolver locale, client VPN

La cache è a più livelli. Il browser tiene la sua cache. Il sistema ha la propria. Il resolver locale (dnsmasq, Unbound, systemd-resolved) è un altro strato. E il client VPN a volte ne ha uno proprio, specie agenti aziendali Zero Trust. Alla fine pulisci una cache e la risposta «sbagliata» vive in un’altra. Ironico e frustrante al tempo stesso. Quindi serviti in modo sistematico: pulisci in ordine e controlla il TTL.

Attenzione al TTL. Se il resolver dà un TTL enorme, un record obsoleto può restare per ore. Nel 2026 si trovano spesso politiche con caching aggressivo per risparmiare traffico, soprattutto su dispositivi mobili. In questi casi aiuta un resolver locale in grado di ignorare temporaneamente il TTL per domini problematici (per esempio abbassarlo a un valore breve durante il debug). Utile durante migrazioni CDN.

Un altro aspetto: split DNS. Alcuni domini interni si risolvono da una parte, altri esterni dall’altra. La cache del resolver locale deve conoscere i suffissi e non mescolare le risposte. Altrimenti un IP esterno "sostituirà" un servizio interno. Configura bene search domains e routes nel tuo profilo VPN.

Come svuotare la cache senza rompere tutto

Procedura rapida. Prima il browser: svuota la cache DNS nelle impostazioni o riavvia il browser, se è più veloce. Poi il sistema. Windows: ipconfig /flushdns, a volte netsh winsock reset per stack sovraccarichi. macOS: dscacheutil -flushcache e killall mDNSResponder (sì, un classico). Linux: resolvectl flush-caches o riavvio del resolver locale. Se c’è dnsmasq, fai service dnsmasq restart. Se usi AdGuard Home o Pi-hole, svuota la cache da interfaccia o via comando.

Dopo pulisci, ripeti test con dig e nslookup e vedi se gli indirizzi o la velocità migliorano. Non dimenticare la cache nel client VPN: agenti aziendali a volte richiedono reset manuale tramite console integrata. Raro, ma capita. L’importante: non cancellare tutto a caso. Con un approccio step-by-step risparmi tempo, pulisci strato per strato, controlli e annoti.

Architettura DNS corretta con VPN nel 2026: da casa all’ufficio

Split DNS e Split Tunneling: come farli funzionare senza rompere tutto

Lo split tunneling risparmia traffico e riduce latenza. Ma con il DNS diventa un campo minato se non metti regole chiare. Regola uno: i suffissi dei domini interni si risolvono solo tramite il resolver nel tunnel. Configura domains o search domains nel profilo VPN, e route-only per le subnet giuste. Regola due: per i domini pubblici scegli dove risolverli — dentro o fuori dal tunnel — e fissa la scelta. La soluzione semplice: un solo resolver di sistema, sempre accessibile attraverso il tunnel. Così le perdite sono minori.

Per WireGuard: nel config client indica DNS e includi AllowedIPs per gli indirizzi del resolver. Per OpenVPN: usa push «dhcp-option DOMAIN-SEARCH corp.local» e push «dhcp-option DNS 10.14.0.1». Su Windows abilita block-outside-dns per evitare che qualcuno sovrascriva le priorità. Nei SASE e Zero Trust aziendali assegna politiche per gruppi utenti e dispositivi, definendo quali domini risolvere dove. Aggiungi monitoring, senza rischi split DNS diventano una lotteria.

E ricorda il fallback. Se il resolver principale è giù, il sistema spesso passa silenziosamente a uno secondario. Pericoloso: così nascono perdite nascoste. Meglio un errore esplicito che un percorso alternativo invisibile. Nel 2026 molti client supportano modalità "rigida", in cui senza il resolver tunnel il DNS non va da nessuna parte.

Crittografia di default: DoH, DoT, ECH, ODoH e DDR senza sorprese

Il DNS criptato non è più un’eccezione. DoH (DNS over HTTPS) e DoT (DNS over TLS) sono presenti nei pannelli di configurazione di Windows, Android e browser moderni. DDR (Discovery of Designated Resolvers) automatizza l’abbinamento del resolver cifrato a quello non cifrato noto. Suona bene, ma con VPN bisogna gestire: chi decide qual è il resolver, l’app o la politica del tunnel?

Lo schema ideale: una sola fonte di verità. Se hai un resolver aziendale con DoH su indirizzo interno, inseriscilo nei client e blocca DoH/DoT esterni mentre la VPN è attiva. Se sei utente privato scegli un resolver affidabile (es. 1.1.1.1, 9.9.9.9, 8.8.8.8 o NextDNS) e assicurati che il percorso verso di esso passi dal tunnel. Per ECH serve solo che il traffico HTTPS del resolver fili liscio. ODoH (Oblivious DoH) aumenta la privacy separando richiesta e trasporto, ma aggiunge latenza — usalo se serve.

Il punto è chiaro: cripta il DNS, ma non moltiplicare le fonti di verità. Un resolver, una politica, rotte chiare. Così la VPN non è nemica, ma alleata. Tra l’altro nel 2026 i client standard loggano correttamente lo stato DoH/DoT. Controlla se i log sono attivi: spesso lì trovi la risposta al "perché ieri funzionava".

Configurazioni passo-passo: Windows, macOS, Linux, iOS e Android

Windows 11/10: resolver di sistema, OpenVPN e WireGuard

Partiamo da Windows. Passo 1: controlla la lista delle interfacce e le loro metriche. Dai priorità all’adattatore VPN. Passo 2: se usi OpenVPN, aggiungi nel profilo client block-outside-dns e register-dns. Sul server imposta push «dhcp-option DNS 10.14.0.1» e, se serve, push «redirect-gateway def1». Passo 3: per WireGuard nel config client indica DNS = 10.14.0.1 e verifica che AllowedIPs includano il percorso al resolver. Se usi split, aggiungi i domini necessari alla ricerca.

Passo 4: abilita il DNS criptato di sistema per il resolver scelto solo se raggiungibile nel tunnel. Inserisci il modello DoH e controlla lo stato nelle impostazioni di rete. Passo 5: svuota la cache — ipconfig /flushdns. Se ci sono stati problemi con Winsock, netsh winsock reset e riavvio. Passo 6: verifica perdite con nslookup example.com e assicurati che il server sia quello tunnel. Se serve, blocca temporaneamente UDP 53 in uscita con firewall mentre la VPN è attiva.

Ulteriori accorgimenti: su Windows 11 verifica che il browser non abbia attivato un DoH proprio che aggira quello di sistema. Se la policy è “tutto dal tunnel”, sincronizza il browser col resolver di sistema o imposta un DoH nel browser raggiungibile via VPN. Non dimenticare IPv6: o configura via tunnel o disattiva per test.

macOS e iOS: profili, Resolver e mDNSResponder

Su macOS tutto gira attorno ai profili e all’ordine dei servizi. Passo 1: verifica che il servizio VPN abbia alta priorità nelle reti. Passo 2: se usi profili aziendali, aggiungi DNS e suffissi di dominio nel profilo VPN. Passo 3: in caso di problemi nella risoluzione svuota la cache con dscacheutil -flushcache e riavvia mDNSResponder col comando killall mDNSResponder. Funziona sempre bene e velocemente.

Su iOS la chiave sono profili e policy dell’app. Molti client impostano resolver interni alla connessione e bloccano il DNS in uscita. Controlla l’opzione per evitare bypass DNS fuori dal tunnel dentro l’app VPN. Se usi Private Relay insieme alla VPN, ci possono essere conflitti di route e registrazioni DoH nei browser. Per i test disattiva Private Relay, lascia solo VPN e DNS di sistema.

In tutti i casi verifica come si risolvono domini di test e confronta con l’atteso. Su macOS è utile scutil --dns per vedere resolver e domini assegnati. Se fai split DNS, imposta Domains per l’interfaccia VPN, così le zone interne non escono all’esterno.

Linux e Android: systemd-resolved, dnsmasq e Private DNS

Su Linux nel 2026 systemd-resolved è spesso il "direttore" DNS. Passo 1: associa l’interfaccia tunnel (wg0/tun0) al resolver giusto impostando DNS e Domains per quell’interfaccia. Passo 2: verifica con resolvectl status che priorità e ordine di ricerca siano corretti. Passo 3: se c’è dnsmasq o Unbound configura forwarding e split DNS per evitare che domini interni escano all’esterno. Passo 4: controlla rotte IPv6 e MTU, e riduci l’MTU nel tunnel se serve.

Su Android vai in Impostazioni Rete e Internet e attiva Private DNS per il resolver scelto, se vuoi cifratura sul dispositivo. Ma attenzione: anche questo traffico deve passare tramite VPN. Se il client VPN non intercetta DoH/DoT, avrai perdite parziali. Molti client ora supportano la modalità Intercetta DNS. Attivala, verifica e testa con vari domini.

Linux e Android amano cache. Non dimenticare resolvectl flush-caches su Linux e riavvio app su Android quando cambi profili. Nei casi complessi installa un resolver locale sul router (ad esempio dnsmasq su OpenWrt) e passa tutto dal tunnel. Questa architettura è spesso più stabile e prevedibile.

Debug e monitoraggio: strumenti e scenari che aiutano davvero

dig, nslookup, resolvectl, pktmon, tcpdump: cosa, dove e quando

Non esiste il tasto magico, ma le domande giuste sì. Chi risponde al DNS? Dove vanno i pacchetti? Si vedono timeout? Su Windows parti con nslookup e pktmon. Con pktmon start --etw -p raccogli un tracciato base e poi vedi se i pacchetti escono dall’interfaccia giusta. Su Linux tcpdump -i wg0 udp port 53 mostra il traffico DNS dentro il tunnel. Se è silenzio ma la risoluzione c’è, qualcuno risolve fuori o con DoH.

dig è utile con le sue opzioni. Prova dig +tcp per verificare DoT e risposte grandi. Guarda la sezione SERVER e AUTHORITY. Confronta risposte con MTU differenti. Con systemd-resolved resolvectl query dominio mostra quale server ha risposto e i tempi. Su macOS scutil --dns visualizza l’ordine dei resolver e domini. Controlla anche il firewall: a volte taglia UDP 53 o TCP 853 per il tunnel senza avvisi.

Per app con DoH attiva log dettagliati. Browser e agenti aziendali nel 2026 finalmente mostrano a quale resolver integrato va il DoH, con quale interfaccia e errori. Oro puro per debug: vedi subito se è una discrasia di routing o problema del resolver.

Log, metriche e alert: casa e ufficio senza sorprese

A casa bastano metriche leggere: tempo prima risoluzione dominio, percentuale NXDOMAIN/SERVFAIL, dimensione cache, TTL. Lo puoi fare con resolver locale o router. Metti una dashboard semplice: se gli errori esplodono dopo attivazione VPN, intervieni subito. In ufficio aggiungi controlli sintetici: un robot ogni 60 secondi risolve domini chiave con e senza VPN. Qualsiasi differenza è segnale.

Non esitare a mettere alert su MTU e frammentazione se l’hardware lo consente. Semestralmente fai revisione: chi è il resolver principale, cosa fa il forwarding, status politiche DoH/DoT, possibili fallback. Piccole correzioni trimestrali mantengono la stabilità meglio di un “rimpasto” ogni tre anni. E ultima raccomandazione: documenta tutto. Tra un anno, quando ti chiederai perché qui sta 1280 e non 1420, un changelog ben fatto ridurrà il caos.

Casi pratici: situazioni reali e soluzioni efficaci

Caso 1: perdita DoH dal browser con VPN aziendale

Scenario: un dipendente si lamenta che alcuni servizi lo vedono "a casa", altri "in ufficio". La VPN è connessa, accesso ai sistemi interni ok. Diagnosi: tcpdump sul tunnel non mostra DNS, ma la risoluzione funziona. Nei log browser è attivo DoH verso resolver cloud. È cifrato ma fuori dal tunnel. Soluzione: nella policy VPN abilita intercettazione DoH e imposta un DoH interno raggiungibile via porta 443 dentro il tunnel. Nel browser disattiva auto-DDR temporaneamente. Risultato: geo stabilizzata, perdite sparite.

Lezione: cifrare senza controllare il routing non garantisce privacy. Conta dove passa il traffico, non solo come è cifrato.

Caso 2: risoluzione instabile per MTU e EDNS

Scenario: siti si aprono ma a volte cadono con SERVFAIL, specie con DNSSEC. Ripetendo la richiesta dopo un secondo va bene. Con VPN peggio, senza VPN meglio. Diagnosi: le risposte grandi si frammentano e si perdono. Il tunnel ha MTU 1420 e nel percorso c’è un dispositivo che taglia i frammenti. Soluzione: abbassato MTU a 1280 sul tunnel, limitato bufsize sul resolver locale per ridurre risposte. Risultato: più stabilità, niente timeout.

Lezione: EDNS è perfetto finché la rete regge. Se no, adattati.

Caso 3: split DNS e cache "appese"

Scenario: un dominio interno a volte si risolve in IP esterno, servizio non raggiungibile. Dopo 10 minuti si sistema da solo. Diagnosi: il resolver locale mette in cache la risposta esterna perché ha ignorato il suffisso interno durante la configurazione split. Il browser poi la cache sopra. Soluzione: configurati Domains per l’interfaccia tunnel, aggiunta regola rigida di forwarding per corp.local, cache resettate in cascata — browser, OS, resolver. Risultato: nessun problema dopo.

Lezione: lo split DNS richiede precisione. Un suffisso sbagliato significa ore di debug buttate.

Checklist quotidiana: breve e utile

Minimo sforzo, massimo risultato

- Verifica chi risolve: nslookup o dig, controlla SERVER. - Assicurati che il resolver VPN sia nel percorso e prioritario. - Pulisci cache a strati: browser, sistema, resolver locale. - Blocca UDP 53 esterno e se serve DoH/DoT esterni. - Allinea politica di cifratura: un resolver, una verità. - Testa IPv6 separatamente: o configura o spegni temporaneamente. - Controlla MTU, EDNS e DNSSEC con risposte grandi.

Questa lista è banale ma efficace. Prendi l’abitudine e ringrazieranno nervi e clienti.

Se hai fatto tutto e il problema resta

Dividi in passi. 1) Il dominio si risolve dentro tunnel con resolver locale impostato manualmente? 2) Risposta arriva in tempo ragionevole? 3) Cambia spegnendo DoH integrato nell’app? 4) Meglio abbassando l’MTU a 1280? 5) Cosa mostra tcpdump sull’interfaccia tunnel? Con risposte sì/no a ogni passo trovi prima la radice.

Non esitare a semplificare tutto in una configurazione semplice ma solida: un tunnel, un resolver, full routing, niente split, niente DoH esterni. Se così funziona stabile, riaggiungi complessità pian piano finché trovi il problema.

FAQ: le risposte rapide

Risposte veloci

Perché con VPN i siti a volte caricano più lentamente al primo accesso?

Perché la richiesta DNS fresca segue un percorso nuovo e la cache ancora non c’è. Inoltre, se il browser usa DoH proprio, aprirà una sessione TLS separata col resolver. Tutto questo aggiunge 100-300 ms di latenza. Dopo l’avvio della cache e delle sessioni i ritardi quasi spariscono. Se invece persistono, controlla MTU e timeout anomali su risposte grandi.

Perché le perdite DNS sono un problema anche se il traffico è cifrato via VPN?

Le perdite DNS rivelano quali domini visiti. Anche se il contenuto è criptato, il fatto che chiedi un dominio è visibile al provider o terzi se la richiesta esce fuori dal tunnel. Inoltre la geolocalizzazione può rompersi e i percorsi diventano più lunghi. Risultato: meno privacy, più problemi di accesso e velocità.

Devo sempre usare DoH o DoT insieme alla VPN?

Non sempre, ma è sensato quando il resolver cifrato è raggiungibile tramite tunnel e la sua policy ti va bene. La chiave è avere una sola fonte di verità. Se abiliti DoH nel browser e la VPN punta il DNS ufficiale altrove, si crea conflitto. Scegli un approccio e assicurati rotte coerenti senza discrepanze.

Casi complessi

Con VPN spariscono solo certi domini con DNSSEC. Cosa fare?

Controlla MTU e frammentazione. Le risposte grandi con DNSSEC spesso non arrivano se il tunnel taglia i frammenti. Abbassa MTU a 1280-1380, configura il resolver locale per ridurre la dimensione delle risposte (EDNS bufsize) e riprova. Se il problema passa, eri sulla buona strada.

Posso combinare split tunneling e DoH di sistema cifrato senza perdite?

Sì, se instradi il traffico DoH solo tramite tunnel e blocchi bypass. Indica in sistema un resolver DoH accessibile soltanto da VPN e blocca DoH/DoT esterni mentre la VPN è attiva. Così i domini pubblici si cifrano e vanno per la strada giusta, quelli interni passano per split DNS al resolver aziendale.

Conviene disattivare IPv6 per semplicità?

Temporaneamente sì, come misura di diagnosi se sospetti perdite o percorsi instabili. Permanentemente no, non lo consigliamo. Nel 2026 sempre più servizi e resolver usano IPv6. Meglio configurare IPv6 nel tunnel correttamente che lavorare con trucchi. Però per test rapidi disattivare IPv6 spesso accelera il troubleshooting.