DNS su TLS più una VPN: quale parte è protetta

DNS su TLS cifra lo scambio tra un client e il resolver che ha scelto, e il resolver legge comunque il nome. Questa frase risolve gran parte della confusione attorno a DoT più una VPN. Il tunnel decide quale percorso prende la query cifrata, mentre il resolver continua a sapere cosa è stato chiesto. Nessuno dei due meccanismi sostituisce l'altro, e nessuno rende l'altro superfluo.

Quattro verifiche stabiliscono se la disposizione che avete è quella che pensate di avere.

Verifica 1: cosa copre la cifratura

DoT avvolge lo scambio DNS in TLS, quindi un osservatore sul percorso vede una connessione verso un indirizzo e una porta invece di un nome in una query. Il resolver stesso decifra e risponde. Confrontatelo con DNS su HTTPS: entrambi cifrano, e usano trasporti diversi, quindi una rete che consente il traffico web non consente automaticamente una connessione DoT.

Questa distinzione conta quando un portale captive o un intermediario di filtraggio consente la 443 e blocca la 853. Lo strumento che funzionava lì non è prova che l'altro funzionerà.

Verifica 2: quale rotta prende la query

La rotta è una questione di politica del client. Un resolver DoT può essere raggiunto attraverso il tunnel, fuori da esso, o per un percorso che cambia con la rete. Quale accada dipende dalle rotte e dal fatto che il client protegga il proprio socket DNS. Un tunnel che cattura tutto il traffico di solito porta con sé la query, qualunque cosa dica l'indirizzo del resolver.

Vedere un indirizzo di resolver di terze parti in un test non dimostra un aggiramento, e vedere cifratura non dimostra il destinatario voluto. Leggete il resolver e il percorso separatamente, poi decidete se la coppia è quella che avete progettato.

Verifica 3: nomi interni

Un'organizzazione che pubblica nomi interni ha bisogno di un resolver che conservi quei record. Un servizio DoT pubblico non conosce il vostro spazio dei nomi privato, e puntare il client a uno di essi garantisce che quei nomi falliscano. È la regressione pratica più comune quando qualcuno abilita il DNS cifrato su un dispositivo gestito.

Mantenete il resolver interno per i suffissi interni e cifrate quel salto se la politica lo richiede, invece di sostituirlo con un fornitore pubblico.

Verifica 4: comportamento in caso di errore

Un'impostazione rigorosa del resolver senza un resolver raggiungibile produce un errore di risoluzione dei nomi mentre il tunnel resta attivo. Guardate la modalità della piattaforma e il suo ripiego documentato invece di toccare chiavi o certificati.

Un ripiego che usa silenziosamente DNS in chiaro è una decisione di politica, non una comodità. Decidete se l'errore debba essere visibile o debba degradare a qualcosa di più debole, e scrivete la risposta.

Fidatevi del certificato, non della risposta

Usate il nome host del fornitore e la configurazione di verifica documentati per il servizio. Disattivare i controlli TLS perché un resolver sconosciuto risponda vi dà un canale cifrato verso un endpoint non verificato, che è peggio della query in chiaro che ha sostituito in un aspetto preciso: sembra sicuro. La specifica di DNS su TLS espone l'attesa di autenticazione dietro quel controllo.

Una risposta da un resolver che non potete autenticare è un'affermazione, non un risultato.

Cosa lascia questo non spiegato

DoT non nasconde il nome al resolver, non nasconde l'indirizzo di destinazione della connessione alla rete e non decide se la query ha viaggiato nel tunnel. Sono tre domande separate con tre risposte separate.

Scrivete l'identità del resolver, il percorso di transito e la politica dei nomi interni su tre righe. La prossima domanda DNS che riceverete sarà una di queste.