¿Arregló la VPN el DNS o solo reutilizó una respuesta en caché?

Abrir una página segundos después de que el túnel se levante no demuestra que el DNS ya funcione, aunque el ticket suela decirlo. Nada en esa observación exigía una consulta: el nombre pudo resolverse antes del cambio y reutilizarse desde una caché que el túnel nunca tocó. Dos pruebas distintas producen la misma pantalla.

Compare qué ejercitó realmente cada prueba antes de atribuir el mérito al cambio.

Cargar una página no es una consulta

Cada capa entre la aplicación y el resolutor puede recordar una respuesta durante su vida útil. El sistema operativo guarda una, el navegador guarda la suya, y una aplicación con una conexión de larga duración puede no volver a resolver nada durante la sesión. Una carga que tiene éxito tras un cambio de túnel puede ser, por tanto, una demostración de memoria y no de enrutamiento. La ausencia de un fallo no es la presencia de una consulta.

Esa distinción cambia lo que debería probar a continuación. Si el objetivo es demostrar que el nuevo resolutor responde, necesita una consulta que no pueda servirse desde una caché que no haya vaciado.

Leer un éxito en caché como prueba de que un servidor antes inalcanzable se recuperó es la versión más cara de este error, porque cierra el incidente sobre una premisa falsa.

Cuente las cachés antes de concluir

Cuatro merecen nombre: la resolución propia de la aplicación, la caché de cliente del sistema operativo, el estado interno del navegador y el resolutor recursivo que la consulta acaba alcanzando. Cada una tiene una vida útil separada y una forma separada de vaciarse. Vaciar una y probar otra es como la gente concluye que el vaciado no hizo nada. Una orden de vaciado nunca zanja la cuestión.

Las respuestas negativas también se almacenan en caché. Un nombre que se informó como ausente puede seguir ausente después de corregir la red, lo que se lee como un túnel roto cuando es un TTL que no ha caducado. La especificación DNS describe cómo deben conservarse y reutilizarse estos datos.

Registre el evento, no la impresión

Anote cuál de las tres cosas cambió: el registro, la ruta hacia el resolutor o un ajuste del cliente. La edición de un registro se propaga según su propio calendario, un cambio de ruta surte efecto al reconectar y un ajuste del navegador solo se aplica a ese navegador. Colapsarlos en un único antes y después produce una cronología que nadie puede auditar.

Anote la hora, el resolutor en uso y la respuesta recibida, incluido el caso en que la respuesta sea negativa. Eso es un hecho que otra persona puede comprobar.

Haga la comparación dos veces de la misma manera

Vacíe la caché que pretende probar, conserve la observación original y luego consulte de una forma que evite tanta memoria como sea posible. Nombrar el resolutor explícitamente le dice qué sabe ese resolutor; no le dice qué resolutor habría elegido la aplicación.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

En Windows, el vaciado de la caché de cliente borra la caché de cliente DNS y nada más. No describe el estado privado de un navegador ni vacía un servidor ascendente, así que una prueba basada en él solo puede interpretarse de forma estrecha. Diga qué caché vació siempre que informe del resultado.

Después, vuelva a probar la aplicación real con una solicitud nueva y la política de resolutor prevista activa. Un resultado producido con una política distinta no se transfiere.