DNS privato contro VPN: cosa copre davvero ogni livello

Il tuo telefono ha il DNS privato impostato su un nome host di un provider e un’app VPN in esecuzione nello stesso momento. È ragionevole supporre che uno dei due ora gestisca le risoluzioni dei nomi. Nessuno dei due lo fa, nel senso che quella frase suggerisce, e il modo più rapido per capire perché è seguire una singola richiesta dal momento in cui tocchi un link.

Queste due funzioni si trovano in punti diversi dello stesso percorso. Il DNS privato cifra la domanda che poni a un resolver. Una VPN cambia la rotta che prende la connessione della risposta.

Quindi percorrilo in ordine, su un dispositivo dove entrambe sono attive, e annota cosa può ancora vedere ogni livello.

Passo uno: la risoluzione lascia l’app

Tocchi un link. Prima che qualsiasi cosa si connetta, l’app ha bisogno di un indirizzo per quel nome host. Su Android la schermata pertinente è Impostazioni, Rete e Internet, DNS privato. Scegliendo Nome host del provider di DNS privato, il dispositivo passa in modalità strict: esegue DNS su TLS verso quel nome host sulla porta 853, e se lo scambio cifrato fallisce, la risoluzione fallisce invece di ripiegare silenziosamente in chiaro sulla porta 53.

Questa è una differenza significativa rispetto ad Automatico, che usa la cifratura opportunistica e userà volentieri un resolver non cifrato quando la rete interferisce. Se il tuo obiettivo è che le risoluzioni non avvengano mai in chiaro, la modalità strict con un nome host di provider è l’impostazione che vi corrisponde.

Ecco la prima cosa che il percorso mette in luce: la risoluzione è protetta dalla rete locale, e il resolver scopre comunque il nome. La cifratura copre il salto. L’operatore di quel resolver vede la query perché risponderle è il suo lavoro.

Passo due: la connessione prende un’altra rotta

Il resolver restituisce un indirizzo e l’app si connette. Questo passo non è influenzato da come è stata cifrata la risoluzione. Senza tunnel, la connessione esce dal tuo normale indirizzo pubblico, e l’IP di destinazione e la stretta di mano TLS rendono comunque il nome host visibile alla rete, con o senza DNS cifrato.

Attiva la VPN e questo è il passo che cambia. Il traffico che corrisponde alla politica di routing del client passa attraverso il tunnel, la rete locale vede una connessione verso l’endpoint VPN, e il sito di solito vede l’indirizzo di uscita. Anche la risoluzione dei nomi può viaggiare dentro il tunnel, a seconda di cosa spinge il client.

Questa separazione è l’intero confronto in una frase. La cifratura DNS risponde a chi può leggere la domanda. Una VPN risponde a dove va la conversazione.

Passo tre: dentro il tunnel, il DNS diventa una questione di politica

Ora le due funzioni interagiscono, e il browser è la solita fonte di sorprese. Un browser con la propria impostazione di DNS sicuro può inviare le risoluzioni al resolver scelto via HTTPS invece di chiedere al sistema operativo. L’impostazione DNS privato di Android non arriva a quella decisione.

In Firefox l’interruttore è sotto Impostazioni, Privacy e sicurezza, Attiva DNS sicuro. In Chrome è sotto Impostazioni, Privacy e sicurezza, Usa DNS sicuro. Entrambi possono essere impostati su un provider specifico o lasciati disattivati, e quando sono attivi, la configurazione DNS del tunnel viene aggirata per quelle risoluzioni anche se il traffico della pagina usa ancora il tunnel.

Se la VPN spinge il proprio resolver e il browser insiste sul suo, ottieni una divisione: i nomi si risolvono, le pagine si caricano, e le risoluzioni che dovevano passare dal tunnel sono uscite direttamente. Un indirizzo di resolver diverso dall’endpoint VPN non è di per sé prova di una fuga, ma un percorso di risoluzione che contraddice l’intento dichiarato vale la pena di essere corretto.

Passo quattro: i nomi interni sono il punto in cui si rompe

Connettiti a una VPN aziendale e apri un host intranet. Se il DNS sicuro del browser è attivo e punta a un resolver pubblico, quel nome non esiste per il browser. Il tunnel è attivo, tutto il resto funziona, e un nome host fallisce con un errore che sembra che il sito sia giù.

Lo stesso guasto si presenta al contrario su Android. Il DNS privato strict con un provider pubblico non risolverà i nomi che solo il resolver interno conosce, e la modalità strict non ha ripiego. Dividere il DNS di un telefono tra un resolver pubblico cifrato e un resolver aziendale non è un’impostazione; è una questione di politica di routing a cui deve rispondere chi gestisce la VPN.

Verifica questo prima di dare la colpa al tunnel: interroga il nome interno, poi lo stesso nome con il DNS sicuro del browser disattivato. Se si risolve, il problema era la scelta del resolver, non la connessione.

Cosa ti dice il percorso di cambiare

Quattro schermate portano quasi tutto. Guardale in questo ordine e annota cosa dice ciascuna, perché la risposta di solito è visibile nella combinazione:

1. Impostazioni Android, Rete e Internet, DNS privato: Automatico o un nome host di provider, e quale nome host.
2. L’impostazione di DNS sicuro del browser: disattivata, o fissata a un resolver specifico.
3. La politica DNS del client VPN: spinge un resolver, e il tunnel diviso esclude qualcosa che ha ancora bisogno di nomi?
4. Un test di un nome host interno con il tunnel attivo, eseguito due volte, una con il DNS del browser attivo e una con esso disattivato.

Poi adatta la correzione al requisito, non il contrario. Se il requisito è che le risoluzioni escano cifrate e vadano a un resolver che hai scelto, imposta il DNS privato strict e fai in modo che il browser sia d’accordo. Se il requisito è che il traffico esca altrove, configura il tunnel e smetti di aspettarti che un’impostazione DNS sposti il tuo indirizzo.

E tieni presente i limiti. Nessuna delle due funzioni rende sicura una destinazione ostile, e nessuna rimuove un’identità con cui hai effettuato l’accesso. La cifratura cambia chi può leggere la domanda; il tunnel cambia dove va la connessione; nulla di tutto ciò rende anonimo l’account.