Il fallback DNS della VPN: dove va davvero la query

Un'impostazione del resolver passa dall'indirizzo privato a uno pubblico e la conclusione arriva subito: il tunnel perde. A volte è vero. Spesso la query di riserva ha comunque viaggiato dentro il tunnel verso un resolver scelto dall'amministratore, il che la rende una decisione di politica e non un difetto. Separare questi casi richiede tre fatti invece di uno, e il primo è chi ha risposto. Scopri chi ha ricevuto la query, quale rotta l'ha portata e quali nomi sono stati richiesti.

Il fallback è una politica, non un singolo comportamento

Ogni client deve decidere cosa fare quando il resolver preferito smette di rispondere. Può bloccare la risoluzione, riprovare, usare un'alternativa configurata o delegare al sistema operativo, e dal punto di vista della privacy sono quattro prodotti diversi. Leggere la schermata delle impostazioni dice quale comportamento è configurato; non dice quale si è verificato. Una schermata con un solo interruttore non descrive quattro possibilità.

I browser aggiungono il proprio livello. Un browser con DNS sicuro attivo può risolvere un nome tramite il provider che ha scelto lui stesso anche quando il sistema operativo punta altrove, il che significa che la politica del client del tunnel potrebbe non essere mai interrogata per le richieste che ti interessano davvero. Controlla l'applicazione che ha effettuato la richiesta, non solo l'impostazione di sistema.

L'identità del resolver sostitutivo è il primo fatto che vale la pena stabilire. Un resolver pubblico appartenente a un provider di cui ti fidi già è una situazione diversa da un indirizzo fornito dalla rete su cui ti trovi. L'indirizzo da solo raramente dice quale dei due stai guardando.

Chi riceve la query dopo il cambio

Il destinatario e la rotta sono indipendenti, e solo la loro combinazione descrive l'esposizione. Un resolver pubblico raggiunto attraverso il tunnel non vede mai l'indirizzo della tua rete di accesso, mentre lo stesso resolver raggiunto direttamente lo vede. Entrambi i casi producono una risposta, e un test di fuga che riporta solo l'indirizzo del resolver li descriverà allo stesso modo. Chiedi l'interfaccia oltre all'indirizzo quando leggi il risultato.

I nomi interni rendono concreta la distinzione. Un resolver pubblico di solito non può rispondere a un nome in split-horizon, quindi la query fallisce mentre il nome è comunque stato rivelato a una parte che non aveva motivo di vederlo. Disponibilità e privacy qui vanno insieme invece di scambiarsi.

Un tunnel può anche portare la query a un resolver non gestito dal provider VPN, perché il tunnel inoltra invece di risolvere. L'host che inoltra vede la query in chiaro e poi apre la propria connessione più avanti, il che protegge il salto successivo senza proteggere il primo.

Controlla insieme la rotta e il destinatario

Osserva i pacchetti invece della configurazione. Chiedi al sistema quale resolver verrebbe usato, poi conferma che la query è davvero partita dall'interfaccia prevista verso l'indirizzo previsto.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Se la cattura mostra la query che lascia l'interfaccia fisica mentre il tunnel è attivo, il fallback ha aggirato il tunnel indipendentemente da ciò che dice l'elenco dei resolver. Se compare sull'interfaccia del tunnel, la domanda diventa chi gestisce l'estremità remota e cosa conserva.

Ripeti il controllo per un nome interno e un nome pubblico. La query interna è dove una configurazione di fallback di solito si rivela, perché un resolver che non può rispondere riceve comunque la domanda.

Decidi se il fallback debba essere consentito

Se il requisito è che la risoluzione si fermi quando il resolver preferito non è disponibile, configura una politica di applicazione che fallisca in modo chiuso e accetta la conseguenza: i nomi non verranno risolti durante un'interruzione. È uno scambio deliberato di disponibilità e non un malfunzionamento, e la progettazione dovrebbe dirlo prima che l'interruzione avvenga.

Se il requisito è solo che le query non viaggino fuori dal tunnel, un resolver pubblico raggiunto attraverso il tunnel può essere accettabile purché si comprendano l'operatore e la sua politica di conservazione. Tale accettazione è un giudizio su una terza parte e non un'affermazione sulla crittografia, e appartiene a chi detiene la dichiarazione sulla privacy. Se i nomi interni devono continuare a funzionare, il fallback deve essere un resolver che detiene le zone interne, il che di solito significa che il bersaglio del fallback è un altro server e non un'altra famiglia di indirizzi.

Documenta l'esito come una frase sul comportamento: quale resolver riceve le query in funzionamento normale, quale le riceve dopo un guasto e se i nomi interni si risolvono nel secondo caso. Un test di fuga che alla fine carica una pagina dimostra meno di quella frase, perché una pagina può caricarsi attraverso un resolver che non si sarebbe mai dovuto consultare.