DNS della VPN contro DoH del browser: cosa non può dirti un test di perdita

La pagina del test di perdita dice che il tuo DNS va bene, il badge del browser dice sicuro, e il wiki interno ancora non si carica. Le tre cose possono essere vere insieme, perché l'indirizzo di un resolver non è la stessa cosa della politica che lo ha scelto o del percorso seguito dalla query. Quello che le persone chiamano fuga di DNS è in realtà una sola domanda: quale resolver ha ricevuto il nome, e quella scelta era intenzionale? Per chiarirlo servono tre controlli, e solo l'ultimo comporta la modifica di un'impostazione.

Mito uno: il badge nomina il tuo resolver

Un test di perdita risolve un nome di prova e riporta l'indirizzo che ha risposto. Non riporta la politica che ha scelto quel resolver, e quando la query è avvolta in DNS su HTTPS, un intermediario sul percorso non può vedere affatto il nome. Due macchine molto diverse producono lo stesso badge rassicurante: una in cui la VPN ha spinto 10.8.0.1 e il browser lo usa, e una in cui il browser ha ignorato l'elenco di sistema e ha inviato il nome al proprio provider cifrato attraverso il tunnel.

La distinzione conta nel momento in cui un nome privato fallisce. Nella prima configurazione il resolver della VPN risponde per la zona aziendale; nella seconda il browser non glielo ha mai chiesto, quindi il nome host corto non si risolve e il guasto sembra una VPN rotta. Il controllo non è un altro test di perdita, è una ricerca su un nome che solo un resolver conosce.

Mito due: il browser esce dal tunnel

Il DNS sceglie un indirizzo, l'instradamento trasporta la connessione, e sono due livelli separati. Una query inviata a un provider DoH pubblico è ancora TCP porta 443 verso un indirizzo instradabile. Se la tabella di routing invia la rotta predefinita nel tunnel, anche quella query passa dal tunnel. Il marchio del resolver non decide il percorso.

Ciò che il DoH del browser cambia è il destinatario dei nomi. È una vera decisione sulla privacy e una vera decisione politica, ma non è un aggiramento dell'instradamento. Se il tuo requisito è che i nomi restino presso l'operatore della VPN, una query cifrata a qualcun altro non soddisfa quel requisito pur usando ancora il tunnel per la connessione reale.

Mito tre: ogni VPN sovrascrive ogni browser

Il DNS sicuro in un browser ha modalità, non un interruttore: disattivato, un provider predefinito con fallback, un modello personalizzato o una politica imposta dal sistema operativo o dall'organizzazione. È il caso di fallback quello che produce rapporti intermittenti. Quando l'endpoint cifrato non è raggiungibile, il browser può tornare al resolver di sistema, quindi lo stesso portatile risolve correttamente un nome privato il lunedì e il martedì no.

Allo stesso tempo, la maggior parte dei client VPN imposta il resolver di sistema quando la connessione sale e ripristina il precedente quando cade. Un browser che mantiene un resolver cifrato personalizzato non osserva affatto quel ripristino. Per questo lo stesso profilo si comporta diversamente su due portatili e per questo resolv.conf sembra corretto mentre il browser chiede ancora a qualcun altro.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Esegui quei comandi mentre sei connesso, annota quali domini rivendica ogni resolver e confronta con ciò che il browser riporta sul proprio modo. La documentazione DoH di Mozilla è una descrizione ragionevole di come dovrebbero funzionare il comportamento predefinito e quello di fallback di un browser.

La decisione ha tre ingressi, non uno

I nomi privati, la fiducia nell'operatore e la raggiungibilità decidono la disposizione corretta. I nomi che solo il resolver della VPN conosce impongono un DNS diviso: il suffisso privato va al resolver spinto, tutto il resto segue la politica scelta per i nomi pubblici. La fiducia nell'operatore decide se anche i nomi pubblici debbano andare a quel resolver o a un servizio separato. La raggiungibilità decide se il resolver cifrato scelto è persino utilizzabile su questa rete.

Nessuna di queste righe è una raccomandazione universale. Un resolver gestito dalla VPN concentra le osservazioni presso quell'operatore; un servizio separato aggiunge un altro destinatario dei nomi interrogati. Nessuna delle due disposizioni dimostra nulla sulla conservazione, a meno che tu non legga la politica.

Annota la decisione per profilo, perché queste impostazioni derivano. Un profilo che ha spinto un resolver il mese scorso oggi potrebbe non spingerne nessuno, e il browser manterrà volentieri un vecchio endpoint personalizzato che risponde ancora. Nella nota devono esserci l'indirizzo del resolver, i suffissi che possiede e il modo del browser, non il marchio del servizio.

Prova la politica che credi di aver configurato

Prova per nome, non per badge. Risolvi un nome pubblico e un nome privato tramite il resolver di sistema, poi ripeti dentro il browser con la sua impostazione di DNS sicuro nel modo che intendi usare. Se il nome privato fallisce solo nel browser, hai trovato la discordanza del destinatario senza toccare una sola impostazione della VPN.

Poi riconnettiti e controlla il ripristino, perché è lì che vivono i bug di passaggio: disconnetti, conferma che il resolver precedente è tornato, riconnettiti, conferma che quello spinto è tornato. Infine, prova un browser con una politica gestita se ne hai uno, perché quella modalità può rifiutare del tutto la tua modifica e mantenere silenziosamente il resolver precedente.

Parti dalla domanda sullo spazio dei nomi e ne eviterai la maggior parte. Se la macchina deve raggiungere nomi interni, il resolver cifrato del browser è una decisione solo sulla metà pubblica, e la metà privata resta con ciò che la VPN ha spinto.