Tu VPN empuja tres servidores DNS: ¿cuál responde?

Abre la página de ajustes tras conectarte y verás tres direcciones DNS; la pregunta de la auditoría es cuál atendió tu última consulta. El número por sí solo no responde nada, porque un empuje del cliente, una interfaz física y una política por dominio escriben todos en la misma vista. Esas entradas tienen ámbitos distintos, y el ámbito, no la posición, decide quién responde. Empieza separando las fuentes y luego prueba la que posee el nombre que te importa.

Por qué la lista es más larga que tu perfil

Un cliente VPN empuja direcciones de resolutor para el enlace del túnel, y el sistema operativo las mantiene junto a lo que ya tenía la interfaz física. Un router, una concesión DHCP corporativa, una segunda VPN y una política por dominio aportan cada uno su propia entrada. Por eso tres direcciones en la página pueden significar tres ámbitos en lugar de tres candidatos para una tarea. Leer el número como prueba de una fuga es el primer error de esta auditoría.

Dentro de una interfaz, un cliente sí prueba sus servidores en orden, así que una lista ordenada no carece de sentido. Lo que no es una cola es la vista combinada, donde las entradas del perfil, del enlace físico y de las reglas por dominio se sientan una al lado de otra sin una única clasificación. Esa distinción decide qué pruebas: el orden explica el comportamiento dentro de un ámbito, y el ámbito explica todo lo demás.

El DNS cifrado rompe el cuadro desde dentro de una aplicación. Un navegador o un cliente de chat con su propio resolutor DNS-over-HTTPS envía consultas por completo más allá de la lista del sistema operativo, así que las direcciones de la página de ajustes describen tráfico que la aplicación nunca generó. Revisa el ajuste de resolutor de la propia aplicación antes de culpar al perfil por un nombre que salió mal.

Qué dice cada una de las tres comprobaciones

Cada fuente deja su marca en un lugar distinto, y ningún comando único las muestra todas. Este es el mapeo que conviene tener junto a la página de ajustes:

En un sistema que usa systemd-resolved, resolvectl status es la autoridad, porque informa del DNS por enlace junto con los dominios de enrutamiento. macOS responde mediante scutil --dns, que enumera los resolutores con ámbito en el orden en que se prueban. Windows divide las dos mitades: Get-DnsClientServerAddress para los servidores por interfaz y Get-DnsClientNrptPolicy para las reglas de sufijo. Ejecuta el comando que corresponda al resolutor realmente en uso, porque una máquina con un entorno de contenedores y un resolutor de escritorio puede tener más de uno instalado.

Un resolutor de respaldo que no puede responder por tu zona

Una segunda entrada suele estar ahí por disponibilidad, y la disponibilidad solo funciona si el respaldo conoce los nombres. Pide a un resolutor público un nombre de host interno y devuelve NXDOMAIN, o una respuesta comodín de un dominio de búsqueda que no tiene nada que ver contigo. Un failover que nadie comprobó produce entonces una caída justo en el momento en que se necesita.

Split DNS existe para evitarlo: los sufijos de la empresa van a un resolutor que tiene la zona, y los nombres públicos se quedan en la ruta predeterminada. El diseño es sólido, y depende de que la lista de sufijos esté completa. Microsoft documenta la política de resolutor por sufijo que impulsa esto en Windows, y la misma idea aparece como dominios de enrutamiento en systemd-resolved y como resolutores con ámbito en macOS.

Compara las zonas que el respaldo puede responder con los sufijos presentes en la política. Esa comparación encuentra el hueco antes de que un usuario informe de que un sitio interno dejó de resolverse tras un cambio de túnel.

Consulta a través de la política, no a su alrededor

Consulta a través del resolutor del sistema operativo, porque una consulta directa a un servidor evita la política e informa solo de lo que diría ese servidor. La diferencia entre las dos respuestas es todo el asunto:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Si la consulta del sistema devuelve una dirección privada mientras la consulta directa devuelve NXDOMAIN, la política funciona y el respaldo es el punto débil. Si ambas devuelven la misma respuesta pública, el nombre se está resolviendo fuera del ámbito que pretendías, y la lista de sufijos es donde hay que mirar. Guarda ambas salidas, porque una discusión sobre resolutores se zanja antes con dos líneas que con una captura de la página de ajustes.

Luego ejercita la ruta de fallo, porque un respaldo que nadie probó es una suposición. Convierte el resolutor preferido en un agujero negro para una consulta y observa qué dirección vuelve:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Borra esa ruta en cuanto termine la consulta, o la siguiente persona hereda un misterio. Si los nombres internos siguen resolviéndose en esa ventana, algo fuera del ámbito previsto los respondió. Si en cambio agotan el tiempo, falta el respaldo o está bien delimitado, y el propio registro del resolutor te dice cuál de las dos cosas fue.

Decide: conservar, delimitar o eliminar

Conserva un segundo resolutor cuando responde al espacio de nombres que necesitas y sigue accesible bajo el perfil. Delimítalo cuando deba ver un sufijo y nada más, y elimínalo cuando no tenga ni ámbito ni propósito documentado. Una entrada sin trabajo es una fuga futura sin beneficio, y un valor predeterminado del proveedor no es un propósito.

Registra el resultado en cuatro columnas: sufijo, resolutor, interfaz y responsable. Esa línea responde a la siguiente pregunta de auditoría más rápido que cualquier captura, y sobrevive a la actualización del cliente que reordena la lista en silencio.