¿Tu VPN cifra el DNS o solo el siguiente salto?

Activar DNS cifrado en el servidor VPN se describe a menudo como cerrar una fuga, y esa descripción oculta qué conexión cambió. El salto del cliente al resolutor y el salto del resolutor al nivel superior son conexiones separadas con propietarios separados. Cifrar una deja la otra exactamente como estaba.

Anota quién recibe la consulta en cada etapa antes de tocar ningún archivo de configuración.

Dos disposiciones se parecen en una página de ajustes

En la primera disposición el dispositivo ejecuta DNS over TLS por sí mismo, y el túnel solo transporta esa conexión hasta un resolutor que elegiste. La sesión TLS termina en el resolutor, lo que significa que el resolutor ve la consulta y la salida de la VPN ve texto cifrado que no puede leer. En la segunda disposición el dispositivo envía DNS normal por el túnel hasta un reenviador en el host de la VPN, y ese reenviador abre su propia conexión cifrada con un resolutor superior. Ambas aparecen como "DNS cifrado con VPN" en una lista de funciones, y colocan la consulta legible en edificios distintos.

La diferencia es medible, no filosófica. Busca la sesión TLS en el cliente o en el servidor y sabrás qué disposición tienes en realidad.

Mapea la cadena de resolutores antes de cambiarla

Cuenta los resolutores de la ruta y nombra el papel de cada uno. Un componente de reenvío entrega una solicitud a otro resolutor, mientras que un resolutor recursivo hace el trabajo de encontrar una respuesta y puede hablar directamente con servidores autoritativos. Esos papeles se definen por separado precisamente por eso, y las definiciones de resolutor del RFC 9076 merecen lectura antes de dar por hecho que existe un único destino superior. Un host que ejecuta su propio resolutor recursivo no tiene un único "superior" que cifrar, lo que invalida todo el plan.

Luego pregunta qué componente tiene configurado el cliente. Una dirección DNS enviada por el perfil de VPN te dice adónde van las consultas, no qué proceso las responde.

Fíjate también en el comportamiento ante fallos. Si el nivel superior cifrado deja de ser accesible, ¿el reenviador falla cerrado, recurre a texto plano o pasa a otro resolutor? Esa decisión pertenece al registro, porque cambia la garantía de privacidad en el momento en que el túnel está menos sano.

Verifica qué salto está cifrado

Empieza en el cliente y confirma si mantiene una sesión TLS hacia el puerto 853. Una consulta que se resuelve correctamente por el puerto 53 no demuestra nada sobre el cifrado.

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

Después pasa al host de la VPN y busca la conexión cifrada saliente que abrió el reenviador. La tabla de sockets te dice si existe una sesión TLS superior y qué proceso la posee:

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

Si el cliente muestra una sesión TLS y el servidor ninguna, estás en la primera disposición y el servidor no puede leer las consultas que reenvía en la capa IP. Si el servidor muestra la sesión TLS y el cliente muestra tráfico normal por el puerto 53 dentro del túnel, estás en la segunda disposición: el siguiente salto está protegido y el reenviador sigue leyendo cada nombre que pide el dispositivo. Ese segundo resultado no es un fallo, pero llamarlo cifrado de extremo a extremo es incorrecto.

Registra el propietario y el comportamiento ante fallos

La propiedad decide qué puedes prometer. El propietario del dispositivo controla una conexión cifrada en el lado del cliente, mientras que el administrador de la VPN controla la conexión siguiente que crea su reenviador. Quien no opera ninguna de las dos solo puede describir la ruta.

Antes de activar nada, revisa el nombrado interno. Enviar nombres de la organización a un resolutor público no es un diseño equivalente, y una zona de split-horizon que solo existe dentro de la red no se resolverá en absoluto en el nivel superior. Prueba un nombre interno y uno público después del cambio y guarda el resultado junto con el cambio de configuración. Si la ruta cifrada rompe la resolución de los hosts internos, la solución es una regla de resolutor con alcance limitado y no un túnel más ancho.

Termina escribiendo una frase por salto: qué componente recibió la consulta, si ese salto estaba cifrado y quién puede leer el nombre. Cuando la frase del host de la VPN sigue diciendo que puede leer las consultas, la documentación debería decirlo, porque un diagrama que afirme lo contrario será creído por alguien que nunca ejecutó los comandos.