Su respaldo de DNS del VPN: adónde va realmente la consulta

Un ajuste del resolutor pasa de la dirección privada a una pública y la conclusión llega de inmediato: el túnel tiene una fuga. A veces es así. A menudo la consulta de respaldo siguió viajando dentro del túnel hacia un resolutor que eligió el administrador, lo que la convierte en una decisión de política y no en un defecto. Separar esos casos exige tres datos en lugar de uno, y el primero es quién respondió. Averigüe quién recibió la consulta, qué ruta la llevó y qué nombres se solicitaron.

El respaldo es una política, no un único comportamiento

Todo cliente tiene que decidir qué hacer cuando el resolutor preferido deja de responder. Puede bloquear la resolución, reintentar, usar una alternativa configurada o delegar en el sistema operativo, y desde el punto de vista de la privacidad esos son cuatro productos distintos. Leer la pantalla de ajustes indica qué comportamiento está configurado; no indica cuál ocurrió. Una pantalla que ofrece un solo interruptor no describe cuatro posibilidades.

Los navegadores añaden su propia capa. Un navegador con DNS seguro activado puede resolver un nombre mediante el proveedor que él mismo elige aunque el sistema operativo apunte a otro sitio, lo que significa que puede que la política del cliente del túnel nunca se consulte para las solicitudes que de verdad le importan. Compruebe la aplicación que hizo la solicitud, no solo el ajuste del sistema.

La identidad del resolutor sustituto es el primer dato que vale la pena establecer. Un resolutor público que pertenece a un proveedor en el que ya confía es una situación distinta de una dirección proporcionada por la red en la que se encuentra. La dirección por sí sola rara vez indica ante cuál de las dos está.

Quién recibe la consulta después del cambio

El destinatario y la ruta son independientes, y solo su combinación describe la exposición. Un resolutor público alcanzado a través del túnel nunca ve la dirección de su red de acceso, mientras que el mismo resolutor alcanzado directamente sí la ve. Ambos casos producen una respuesta, y una prueba de fuga que solo informa de la dirección del resolutor los describirá de forma idéntica. Pida la interfaz además de la dirección cuando lea el resultado.

Los nombres internos hacen concreta la distinción. Un resolutor público normalmente no puede responder un nombre de horizonte dividido, así que la consulta falla mientras el nombre ya se ha revelado a una parte que no tenía por qué verlo. Disponibilidad y privacidad van juntas aquí en lugar de intercambiarse.

Un túnel también puede llevar la consulta a un resolutor que no opera el proveedor de VPN, porque el túnel reenvía en lugar de resolver. El host que reenvía ve la consulta en texto claro y luego abre su propia conexión hacia delante, lo que protege el siguiente salto sin proteger el primero.

Compruebe la ruta y el destinatario a la vez

Observe los paquetes en lugar de la configuración. Pregunte al sistema qué resolutor se usaría y luego confirme que la consulta salió realmente de la interfaz esperada hacia la dirección esperada.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Si la captura muestra la consulta saliendo de la interfaz física mientras el túnel está activo, el respaldo se saltó el túnel independientemente de lo que diga la lista de resolutores. Si aparece en la interfaz del túnel, la pregunta pasa a ser quién opera el extremo remoto y qué conserva.

Repita la comprobación con un nombre interno y un nombre público. La consulta interna es donde una configuración de respaldo suele revelarse, porque un resolutor que no puede responder recibe igualmente la pregunta.

Decida si debe permitirse el respaldo

Si el requisito es que la resolución se detenga cuando el resolutor preferido no esté disponible, configure una política de aplicación que falle cerrada y acepte la consecuencia: los nombres no se resolverán durante una interrupción. Es un intercambio deliberado de disponibilidad y no un mal funcionamiento, y el diseño debería decirlo antes de que ocurra la interrupción.

Si el requisito es solo que las consultas no viajen fuera del túnel, un resolutor público alcanzado a través del túnel puede ser aceptable siempre que se entiendan el operador y su política de retención. Esa aceptación es un juicio sobre un tercero y no una afirmación sobre criptografía, y corresponde a quien sostiene la afirmación de privacidad. Si los nombres internos deben seguir funcionando, el respaldo tiene que ser un resolutor que contenga las zonas internas, lo que normalmente significa que el objetivo de respaldo es un servidor distinto y no una familia de direcciones distinta.

Documente el resultado como una frase sobre el comportamiento: qué resolutor recibe las consultas en funcionamiento normal, cuál las recibe tras un fallo y si los nombres internos se resuelven en el segundo caso. Una prueba de fuga que acaba cargando una página demuestra menos que esa frase, porque una página puede cargarse a través de un resolutor que nunca debió consultarse.