La tua VPN crittografa il DNS o solo il salto successivo?

Attivare il DNS cifrato sul server VPN viene spesso descritto come chiudere una fuga, e quella descrizione nasconde quale connessione è cambiata. Il salto dal client al resolver e il salto dal resolver al livello superiore sono connessioni separate con proprietari separati. Cifrarne una lascia l'altra esattamente com'era.

Annota chi riceve la query a ogni stadio prima di toccare un file di configurazione.

Due disposizioni sembrano uguali in una pagina di impostazioni

Nella prima disposizione il dispositivo esegue da sé DNS over TLS, e il tunnel si limita a trasportare quella connessione verso un resolver che hai scelto. La sessione TLS termina al resolver, il che significa che il resolver vede la query e l'uscita VPN vede testo cifrato che non può leggere. Nella seconda disposizione il dispositivo invia DNS ordinario attraverso il tunnel a un inoltratore sull'host VPN, e quell'inoltratore apre la propria connessione cifrata verso un resolver superiore. Entrambe appaiono come "DNS cifrato con una VPN" in un elenco di funzioni, e collocano la query leggibile in edifici diversi.

La differenza è misurabile, non filosofica. Cerca la sessione TLS sul client o sul server, e saprai quale disposizione hai davvero.

Mappa la catena di resolver prima di cambiarla

Conta i resolver sul percorso e nomina il ruolo di ciascuno. Un componente di inoltro consegna una richiesta a un altro resolver, mentre un resolver ricorsivo svolge il lavoro di trovare una risposta e può parlare direttamente con i server autoritativi. Quei ruoli sono definiti separatamente proprio per questo motivo, e le definizioni di resolver del RFC 9076 meritano una lettura prima di dare per scontato che esista un'unica destinazione superiore. Un host che esegue il proprio resolver ricorsivo non ha un unico "livello superiore" da cifrare, il che invalida l'intero piano.

Poi chiedi quale componente è configurato per usare il client. Un indirizzo DNS inviato dal profilo VPN ti dice dove vanno le query, non quale processo risponde.

Nota anche il comportamento in caso di guasto. Se il livello superiore cifrato diventa irraggiungibile, l'inoltratore fallisce in modo chiuso, ricade sul testo in chiaro o passa a un altro resolver? Quella decisione appartiene al registro, perché cambia la garanzia di riservatezza nel momento in cui il tunnel è meno sano.

Verifica quale salto è cifrato

Parti dal client e verifica se mantiene una sessione TLS verso la porta 853. Una query che si risolve correttamente attraverso la porta 53 non dimostra nulla sulla cifratura.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Poi passa all'host VPN e cerca la connessione cifrata in uscita che l'inoltratore ha aperto. La tabella dei socket ti dice se esiste una sessione TLS superiore e quale processo la possiede:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Se il client mostra una sessione TLS e il server nessuna, sei nella prima disposizione e il server non può leggere le query che inoltra a livello IP. Se il server mostra la sessione TLS e il client mostra traffico ordinario sulla porta 53 dentro il tunnel, sei nella seconda disposizione: il salto successivo è protetto, e l'inoltratore legge ancora ogni nome che il dispositivo chiede. Quel secondo risultato non è un guasto, ma chiamarlo cifratura end-to-end è sbagliato.

Registra il proprietario e il comportamento in caso di guasto

La proprietà decide cosa puoi promettere. Il proprietario del dispositivo controlla una connessione cifrata lato client, mentre l'amministratore della VPN controlla la connessione successiva creata dal suo inoltratore. Chi non gestisce nessuna delle due può solo descrivere il percorso.

Prima di attivare qualcosa, controlla la denominazione interna. Inviare nomi dell'organizzazione a un resolver pubblico non è una progettazione equivalente, e una zona split-horizon che esiste solo dentro la rete non verrà risolta affatto a monte. Prova un nome interno e uno pubblico dopo la modifica, e conserva il risultato con la modifica di configurazione. Se il percorso cifrato rompe la risoluzione per gli host interni, la correzione è una regola di resolver con ambito limitato, non un tunnel più ampio.

Concludi scrivendo una frase per salto: quale componente ha ricevuto la query, se quel salto era cifrato, e chi può leggere il nome. Quando la frase sull'host VPN dice ancora che può leggere le query, la documentazione dovrebbe dirlo, perché un diagramma che afferma il contrario sarà creduto da qualcuno che non ha mai eseguito i comandi.