DNSSEC o VPN: quale nasconde le tue query DNS?

Due meccanismi ricevono lo stesso compito e nessuno dei due lo svolge. DNSSEC risponde se i dati che hai ricevuto provengono davvero dalla zona che li pubblica, e una VPN decide quale percorso prendono i tuoi pacchetti. Nessuno dei due nasconde in ogni caso il nome che hai chiesto, e le impostazioni che sembrano doverlo fare riguardano di solito il trasporto o l’instradamento e non la convalida. Dare un nome al livello per primo trasforma una domanda vaga sulla privacy in una domanda precisa.

Tre affermazioni fuse in una

L’autenticità è l’affermazione che la risposta è quella pubblicata dalla zona e non è stata alterata lungo il percorso. La riservatezza è l’affermazione che nessuno sul percorso può leggere la query o la risposta. L’instradamento è l’affermazione che i pacchetti seguono un percorso che hai scelto, ed è proprio ciò che offre un tunnel.

DNSSEC affronta la prima e non dice nulla delle altre due. DoT e DoH affrontano la seconda per il salto fino al resolver. Una VPN affronta la terza e può influire anche sulla seconda, ma solo come effetto collaterale di dove va il traffico.

Il traffico delle applicazioni è un quarto caso: HTTPS protegge e autentica lo scambio web tra il tuo client e il sito, e nessun livello DNS lo sostituisce.

Cosa può e cosa non può fare la convalida delle firme

Un resolver che convalida controlla la catena di firme dalla zona fino a un’ancora di fiducia configurata, poi restituisce una risposta con il flag dei dati autenticati attivo quando il controllo riesce. Quel flag è una prova sui dati, non sulla connessione né sulle intenzioni della destinazione.

Non può impedire a un legittimo proprietario di una zona di pubblicare record autentici per un servizio di cui non dovresti fidarti. Una risposta correttamente firmata da un dominio compromesso resta correttamente firmata, e DNSSEC non ha un’opinione sul fatto che quel dominio meriti le tue credenziali.

Non nasconde nemmeno nulla. La query e la risposta attraversano la rete in una forma che un resolver e qualsiasi osservatore su quel percorso possono leggere, a meno che un altro livello protegga il trasporto. Una risposta firmata e una risposta privata sono proprietà diverse, e una distribuzione può averne solo una. Prova entrambe se una delle due ti importa.

Da dove viene davvero la riservatezza

Il trasporto cifrato verso il resolver avvolge lo scambio DNS in TLS, così il resolver vede ancora la domanda ma il percorso tra te e lui no. Questo sposta la fiducia invece di eliminarla: ti fidi di più del resolver e meno della rete locale.

Una VPN può portare le query a un resolver dall’altra parte, il che cambia sia il percorso sia il resolver che le vede. È una decisione di instradamento con una conseguenza sulla privacy, e in una rete gestita il resolver interno può essere l’unico in grado di rispondere ai nomi interni.

La combinazione che le persone vogliono davvero è di solito tre cose insieme: convalida attiva, trasporto cifrato verso un resolver che hanno scelto e TLS dell’applicazione sulla destinazione. Ognuna è indipendente, e saltarne una lascia un vuoto diverso.

Controlla convalida e trasporto separatamente

Due test risolvono gran parte della confusione. Il primo chiede se il resolver ha convalidato la risposta; il secondo chiede se il trasporto era protetto. Falliscono in modi diversi e nessuno dei due implica l’altro.

Questi comandi stampano i flag di una query che convalida, ripetono la query con il controllo disattivato ed eseguono la convalida locale con delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Una risposta con il flag dei dati autenticati e una firma presente mostra la convalida su quel resolver. Un errore di convalida con delv mostra una catena spezzata da qualche parte tra la zona e l’ancora di fiducia, che è un problema di pubblicazione e non un problema di tunnel. Un timeout senza alcun flag è un problema di trasporto o di raggiungibilità, e trattarlo come un errore di firma ti porta al livello sbagliato.

Cosa fare quando una VPN rompe le risoluzioni

Se le risoluzioni funzionavano prima del tunnel e si fermano dopo, confronta il resolver che usa ogni percorso. Il tunnel diviso, un resolver interno raggiungibile solo attraverso il tunnel e un client che riscrive le impostazioni del resolver cambiano tutti la risposta senza toccare DNSSEC.

Disattivare la convalida a livello globale è la prima mossa sbagliata, perché elimina l’unico meccanismo che segnala le manomissioni e non risolve un resolver irraggiungibile. Restringi prima il guasto: risoluzione, trasporto, convalida e poi politica. Solo la terza appartiene a DNSSEC, e solo la seconda al trasporto cifrato.