NXDOMAIN a través de una VPN no significa una caída del túnel

Es tentador leer una consulta fallida como prueba de que el túnel se ha derrumbado, sobre todo cuando el nombre funcionaba diez minutos antes. La respuesta dice otra cosa. NXDOMAIN es una transacción DNS completada en la que un resolutor declaró que el nombre consultado no existe; un túnel roto suele producir silencio, un tiempo de espera agotado o un intento de resolución contra el servidor equivocado. La versión del argumento sin wireshark es una consulta, un respondedor y un código de respuesta, y esa terna merece quedar registrada antes de cualquier cambio de configuración.

Qué establece realmente la respuesta

El DNS separa resultados que los clientes suelen fundir en un solo fallo. Un nombre que no existe produce una respuesta negativa con el código NXDOMAIN, mientras que un nombre que existe pero no tiene ningún registro del tipo solicitado produce una respuesta correcta con una sección de respuestas vacía. Ambos parecen nada útil para una aplicación, y solo uno de ellos significa que el nombre es incorrecto.

Esa diferencia decide dónde corresponde la reparación. Un registro AAAA ausente en un host que tiene un registro A no es un host ausente, y reemitir un certificado o reconstruir un túnel para perseguirlo desperdicia la única pista disponible. La distinción también fija la forma del seguimiento: un problema de nombres se corrige en la zona, y un problema de tipo se corrige pidiendo el registro correcto o aceptando que la familia de direcciones simplemente no está.

El mito: un nombre privado ausente significa que el túnel ha fallado

El mito sobrevive porque los dos sucesos llegan tan a menudo juntos. Un cliente se conecta a la VPN, el sistema operativo conserva un resolutor en el que ya confiaba, y el nombre interno que ahora necesita se pregunta a un servidor que nunca ha oído hablar de la zona privada. Ese servidor responde con honestidad y de forma negativa. El túnel transporta el paquete; la respuesta solo trata de un espacio de nombres que el respondedor no sirve.

Las disposiciones de horizonte dividido hacen que esto sea rutinario: el mismo nombre de zona existe públicamente y de forma interna con contenidos distintos, y solo el resolutor interno conoce los registros privados. Obtener una respuesta negativa que parece autoritativa es, por tanto, prueba de qué resolutor respondió, no prueba del estado de la interfaz.

Dos detalles de configuración deciden el resultado. El túnel tiene que empujar o seleccionar el resolutor interno, y el cliente tiene que aplicar esa selección al nombre que se consulta. Una regla por dominio que nombre un sufijo ligeramente distinto del registro que usted escribió enviará la consulta por la ruta pública, y la respuesta será correcta e inútil.

Pregunte al resolutor correcto con el nombre correcto

Registre al respondedor antes de registrar el veredicto. Una consulta que no muestra qué servidor respondió no puede distinguir un problema de política de un problema de espacio de nombres, y los dos tienen arreglos no relacionados.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Las dos primeras líneas muestran qué decidió el resolutor local y a quién preguntaría. La consulta +search reproduce lo que hace una aplicación cuando añade un sufijo de búsqueda, que a menudo es la consulta real y no la escrita en una herramienta de diagnóstico. La última línea pregunta directamente al servidor interno, saltándose la política del cliente; si eso tiene éxito mientras la consulta simple falla, la zona está bien y el enrutamiento de las consultas no.

El almacenamiento en caché negativo explica el retraso tras un arreglo

Las respuestas negativas se guardan en caché por diseño, y RFC 2308 describe cómo se deriva la vida útil de la caché negativa del registro de autoridad de la zona. Por tanto, corregir un registro o una regla de resolutor no garantiza un cambio inmediato en el cliente, y reintentar una consulta que sigue devolviendo la respuesta en caché no demuestra nada nuevo. Solo un respondedor distinto, un nombre distinto o una caché vaciada producen pruebas frescas.

Vacíe la caché local y luego repita la misma consulta contra el mismo respondedor. En sistemas que usan el servicio de resolutor local eso es una orden; en otros es un reinicio del servicio o una utilidad de la plataforma, y la herramienta concreta importa menos que repetir después una prueba idéntica.

Separe el nombre de la ruta

Una vez que el nombre resuelve a la dirección privada esperada, el DNS queda terminado como tema y la ruta de la aplicación pasa a ser la siguiente pregunta. Un host que responde a las consultas pero rechaza una conexión tiene otro problema, y seguir ajustando resolutores después de una respuesta correcta es como un incidente adquiere tres cambios no relacionados. Compare la dirección resuelta con la que el servicio escucha realmente antes de suponer que ambas coinciden.

Conserve la transcripción: la consulta, el respondedor, el código y la dirección resuelta. Ese registro es también lo que hace verificable un informe posterior, y es la diferencia entre un diagnóstico y una historia sobre un túnel que parecía lento.