Test di fuga DNS: un nome di resolver non è la rotta

Tre disposizioni contano come DNS corretto per un utente VPN: query al resolver dell'operatore, query a un resolver cifrato che hai scelto, e split DNS che invia i nomi di lavoro all'organizzazione. Un test di fuga segnala un resolver, e quella singola etichetta non può dirti quale disposizione hai davvero. Decidi prima la politica desiderata, poi verifica rispetto a essa. Altrimenti stai confrontando un numero con una sensazione.

Decidi cosa volevi prima di leggere il risultato

Nomina la politica in una frase: tutti i nomi al resolver VPN, tutti i nomi a un resolver cifrato scelto, oppure split DNS con i nomi interni che vanno all'organizzazione. Ognuna è difendibile per un utente diverso, e ognuna produce una risposta attesa diversa. Senza quella frase, qualsiasi risultato diverso da uno screenshot in un post di un forum sembra allarmante. Scrivi la politica prima del primo test.

Un test eseguito prima che la politica sia definita non misura nulla. Produce un nome di resolver senza alcun punto di riferimento.

Un nome di resolver non prova né il percorso né il destinatario

Due domande contano: chi ha ricevuto la query e quale rotta l'ha trasportata. Un resolver di terze parti può essere raggiunto attraverso il tunnel mentre una schermata delle impostazioni mostra l'indirizzo del fornitore. L'etichetta su una pagina di test di fuga descrive la vista dell'osservatore, non la tua tabella di routing.

Un browser può usare il proprio DNS cifrato mentre il traffico del sito passa nel tunnel, e le risposte in cache possono far caricare una pagina senza una nuova ricerca. Ecco perché un risultato di IP pubblico non dice nulla sul DNS. DoH e DoT proteggono la query in transito verso il resolver, e quel resolver vede comunque i nomi.

resolvectl status
resolvectl query example.com
dig +short example.com

Lo split DNS rende corretti più resolver

Un'organizzazione può inviare i nomi interni al proprio DNS e tutto il resto altrove. Un test che elenca diversi resolver può quindi descrivere la politica desiderata anziché un guasto. Confronta l'insieme osservato con le regole split DNS documentate prima di disattivare qualcosa. Spegnere il resolver interno per far sembrare più pulita una pagina di test rompe i nomi privati.

Split tunneling e split DNS sono scelte diverse: uno instrada i pacchetti, l'altro instrada le domande. Cambiare una rotta del tunnel non sposta una ricerca di nome, e cambiare il resolver non corregge il percorso di un sito. IPv6 è una terza domanda, poiché una connessione IPv6 indesiderata non è automaticamente una fuga DNS.

Trasforma il risultato in un'indagine

Registra la politica desiderata e l'impostazione DNS sicuro del browser prima del test. Esegui il test con il tunnel attivo, annota ogni resolver che nomina e confronta l'insieme con la politica anziché con un unico indirizzo atteso.

Ripeti dopo una riconnessione se è allora che compare il sintomo, perché una politica applicata al momento della connessione può andare persa in seguito. Usa la documentazione del client per le eccezioni DNS interne invece di indovinare le impostazioni.

Correggi la discrepanza che hai trovato: una scelta del browser, un'impostazione DNS del VPN o una regola split DNS. Se le query devono fermarsi quando il tunnel fallisce, il kill switch è un'impostazione separata, e la sola configurazione DNS non la fornisce. La specifica RFC 8484 è utile quando devi spiegare cosa un resolver cifrato nasconde e cosa non nasconde.