DNS sobre TLS más una VPN: qué parte queda protegida

DNS sobre TLS cifra el intercambio entre un cliente y el resolutor que eligió, y el resolutor sigue leyendo el nombre. Esa frase resuelve la mayor parte de la confusión en torno a DoT más una VPN. El túnel decide qué camino toma la consulta cifrada, mientras que el resolutor sigue enterándose de qué se preguntó. Ninguno de los dos mecanismos sustituye al otro, y ninguno hace superfluo al otro.

Cuatro comprobaciones deciden si la disposición que tiene es la que cree que tiene.

Comprobación 1: qué cubre el cifrado

DoT envuelve el intercambio DNS en TLS, así que un observador en el camino ve una conexión a una dirección y un puerto en lugar de un nombre en una consulta. El propio resolutor descifra y responde. Compárelo con DNS sobre HTTPS: ambos cifran y usan transportes distintos, así que una red que permite tráfico web no permite automáticamente una conexión DoT.

Esa distinción importa cuando un portal cautivo o un intermediario de filtrado permite el 443 y bloquea el 853. La herramienta que funcionó allí no es prueba de que la otra vaya a hacerlo.

Comprobación 2: qué ruta toma la consulta

La ruta es una cuestión de política del cliente. Se puede llegar a un resolutor DoT a través del túnel, fuera de él o por un camino que cambia con la red. Cuál ocurra depende de las rutas y de si el cliente protege su propio socket DNS. Un túnel que captura todo el tráfico normalmente se llevará la consulta consigo, diga lo que diga la dirección del resolutor.

Ver una dirección de resolutor de terceros en una prueba no demuestra una elusión, y ver cifrado no demuestra el destinatario previsto. Lea el resolutor y el camino por separado y luego decida si el par es el que diseñó.

Comprobación 3: nombres internos

Una organización que publica nombres internos necesita un resolutor que guarde esos registros. Un servicio DoT público no conoce su espacio de nombres privado, y apuntar el cliente a uno garantiza que esos nombres fallen. Esta es la regresión práctica más habitual cuando alguien activa DNS cifrado en un dispositivo gestionado.

Conserve el resolutor interno para los sufijos internos y cifre ese salto si la política lo exige, en lugar de sustituirlo por un proveedor público.

Comprobación 4: comportamiento ante fallos

Un ajuste estricto de resolutor sin un resolutor accesible produce un fallo de resolución de nombres mientras el túnel sigue levantado. Mire el modo de la plataforma y su alternativa documentada en vez de tocar claves o certificados.

Una alternativa que usa DNS en claro en silencio es una decisión de política, no una comodidad. Decida si el fallo debe ser visible o debe degradarse a algo más débil, y escriba la respuesta.

Confíe en el certificado, no en la respuesta

Use el nombre de host del proveedor y la configuración de verificación documentados para el servicio. Desactivar las comprobaciones TLS para que responda un resolutor desconocido le da un canal cifrado hacia un extremo no verificado, lo que es peor que la consulta en claro a la que sustituyó en un aspecto concreto: parece seguro. La especificación de DNS sobre TLS expone la expectativa de autenticación que hay detrás de esa comprobación.

Una respuesta de un resolutor que no puede autenticar es una afirmación, no un resultado.

Qué deja esto sin explicar

DoT no oculta el nombre al resolutor, no oculta la dirección de destino de la conexión a la red y no decide si la consulta viajó por el túnel. Son tres preguntas separadas con tres respuestas separadas.

Escriba la identidad del resolutor, el camino de tránsito y la política de nombres internos como tres líneas. La próxima pregunta sobre DNS que reciba será una de ellas.