DNS sobre TLS máis unha VPN: que parte queda protexida

DNS sobre TLS cifra o intercambio entre un cliente e o resolutor que elixiu, e o resolutor segue lendo o nome. Esa frase resolve a maior parte da confusión arredor de DoT máis unha VPN. O túnel decide que camiño toma a consulta cifrada, mentres que o resolutor segue sabendo que se preguntou. Ningún dos dous mecanismos substitúe o outro, e ningún fai superfluo o outro.

Catro comprobacións deciden se a disposición que ten é a que cre que ten.

Comprobación 1: que cobre o cifrado

DoT envolve o intercambio DNS en TLS, así que un observador no camiño ve unha conexión a un enderezo e un porto en lugar dun nome nunha consulta. O propio resolutor descifra e responde. Compáreo con DNS sobre HTTPS: ambos cifran e usan transportes distintos, así que unha rede que permite tráfico web non permite automaticamente unha conexión DoT.

Esa distinción importa cando un portal cautivo ou un intermediario de filtrado permite o 443 e bloquea o 853. A ferramenta que funcionou alí non é proba de que a outra vaia facelo.

Comprobación 2: que ruta toma a consulta

A ruta é unha cuestión de política do cliente. Pódese chegar a un resolutor DoT a través do túnel, fóra del ou por un camiño que cambia coa rede. Cal ocorre depende das rutas e de se o cliente protexe o seu propio socket DNS. Un túnel que captura todo o tráfico normalmente levará a consulta consigo, diga o que diga o enderezo do resolutor.

Ver un enderezo de resolutor de terceiros nunha proba non demostra unha elusión, e ver cifrado non demostra o destinatario previsto. Lea o resolutor e o camiño por separado e logo decida se o par é o que deseñou.

Comprobación 3: nomes internos

Unha organización que publica nomes internos necesita un resolutor que garde eses rexistros. Un servizo DoT público non coñece o seu espazo de nomes privado, e apuntar o cliente a un garante que eses nomes fallen. Esta é a regresión práctica máis habitual cando alguén activa DNS cifrado nun dispositivo xestionado.

Manteña o resolutor interno para os sufixos internos e cifre ese salto se a política o esixe, en lugar de substituílo por un provedor público.

Comprobación 4: comportamento ante fallos

Un axuste estrito de resolutor sen un resolutor accesible produce un fallo de resolución de nomes mentres o túnel segue en pé. Mire o modo da plataforma e a súa alternativa documentada en vez de tocar claves ou certificados.

Unha alternativa que usa DNS en claro en silencio é unha decisión de política, non unha comodidade. Decida se o fallo debe ser visible ou debe degradarse a algo máis feble, e escriba a resposta.

Confíe no certificado, non na resposta

Use o nome de host do provedor e a configuración de verificación documentados para o servizo. Desactivar as comprobacións TLS para que responda un resolutor descoñecido dálle unha canle cifrada cara a un extremo non verificado, o que é peor que a consulta en claro que substituíu nun aspecto concreto: parece seguro. A especificación de DNS sobre TLS expón a expectativa de autenticación que hai detrás desa comprobación.

Unha resposta dun resolutor que non pode autenticar é unha afirmación, non un resultado.

Que deixa isto sen explicar

DoT non oculta o nome ao resolutor, non oculta o enderezo de destino da conexión á rede e non decide se a consulta viaxou polo túnel. Son tres preguntas separadas con tres respostas separadas.

Escriba a identidade do resolutor, o camiño de tránsito e a política de nomes internos como tres liñas. A próxima pregunta sobre DNS que reciba será unha delas.