El DNS cifrado sin VPN oculta la consulta, no tu dirección

Una prueba de fuga de DNS que muestra tu red doméstica no es prueba de que el DNS cifrado haya fallado, ni es prueba de que algo haya funcionado. La prueba responde una pregunta: a qué resolutor llegó esta consulta desde esta red. Si eso es un problema depende de qué protegías y de quién.

Escribe el objetivo antes de ejecutar cualquier prueba.

Paso 1: nombra la protección que realmente quieres

Tres objetivos se mezclan. Puede que quieras que un observador en la ruta deje de leer consultas. Puede que quieras que un resolutor concreto deje de recibirlas. Puede que quieras que los sitios web que visitas dejen de ver tu dirección de casa. El DNS cifrado sirve al primero, cambia quién satisface el segundo y no hace absolutamente nada por el tercero.

Una VPN sirve al tercero y, según el proveedor, al primero. Ninguna de las dos herramientas es un superconjunto de la otra.

Paso 2: elige un resolutor y verifica su identidad

DNS over TLS envuelve la consulta en una sesión TLS con el resolutor, y DNS over HTTPS la envuelve en una petición HTTP; RFC 7858 y RFC 8484 describen ambas, y ninguna necesita un túnel. Lo importante en la práctica es que el certificado se verifique contra el nombre que configuraste, porque una sesión cifrada con la parte equivocada es peor que texto plano con la correcta. Eso significa modo estricto donde la plataforma lo ofrece, no un modo oportunista que retrocede cuando la verificación falla. Comprueba la sesión directamente antes de confiar en el ajuste: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

El handshake debería nombrar el resolutor que configuraste y devolver una cadena que puedas verificar.

Paso 3: decide el comportamiento ante fallos

Cada implementación tiene una política para un resolutor cifrado inalcanzable, y esa política es la decisión de privacidad. El modo estricto hace fallar la búsqueda, lo cual es visible e irritante. El modo oportunista reintenta en texto plano, lo cual es invisible y arruina el propósito justo el día en que importa. Elige a conciencia y luego anota la elección junto al requisito.

En systemd-resolved eso significa DNSOverTLS=yes en lugar de opportunistic; en Android significa el modo de nombre de host de Private DNS en lugar de automático.

Comprueba qué está realmente en vigor con resolvectl status | grep -i -A1 "dns over tls", porque un archivo drop-in que nunca se recargó no cambia nada.

Paso 4: comprueba que las aplicaciones siguen al resolutor del sistema

Un navegador con su propio ajuste de DNS seguro ignora por completo la configuración del sistema, y también un runtime de contenedores con un resolutor integrado o un runtime de lenguaje que lee una lista fijada en el código. O haces que sigan al sistema o los configuras explícitamente y lo anotas. Luego mira el comportamiento de repliegue de cada uno, porque no todos fallan cerrados. El inventario en la práctica es corto: navegador, runtime de contenedores y cualquier cliente VPN que también ejecutes.

Los nombres privados de la organización se quedan en el resolutor interno aprobado. Enviarlos a un servicio público para que una prueba quede ordenada crea a propósito un problema distinto.

Paso 5: lee la prueba de fuga contra el requisito

Una prueba que informa de un resolutor inesperado es una pista, no un veredicto. Puede que haya observado el resolutor cifrado que pretendías, un ajuste específico de una aplicación o un repliegue a texto plano que no conocías. Compara el resolutor informado con lo que configuró el paso 2 y compara el resultado con el objetivo del paso 1.

Si el objetivo era mantener las consultas lejos de la red local, una prueba que muestra tu resolutor habitual es un hallazgo real. Si el objetivo era el anonimato al navegar, ningún ajuste de DNS lo habría entregado nunca.

Escribe la línea de aceptación en el idioma del objetivo: estas búsquedas usan este resolutor verificado bajo estas condiciones. Cualquier cosa más amplia es una afirmación que no puedes probar.