¿DNS del VPN incorrecto? Un servidor autoritativo puede estar obsoleto
Conecta el VPN y un nombre se resuelve a la dirección de ayer. El túnel no rompió el DNS; un servidor autoritativo publicado llevaba todo el tiempo sirviendo datos de zona obsoletos.
Conecta el VPN y un nombre de host se resuelve a la dirección de ayer, o a nada. Desconecta y vuelve a funcionar. El reflejo es culpar al resolutor que impuso el túnel, pero la causa más común es un servidor de nombres publicado que dejó de recibir actualizaciones de la zona. La ruta nueva simplemente llegó a una autoridad distinta de la que originó la respuesta que tenías en caché.
El síntoma cambia con el resolutor
Un resolutor recursivo devuelve lo que le dijo una autoridad y luego conserva esa respuesta durante el TTL. Si el túnel impone otro resolutor, o cambia la ruta de modo que el antiguo ya no sea alcanzable, el cliente pregunta a otra autoridad y obtiene otra respuesta. El dominio no cambió en ese momento; tu visión de él sí.
Por eso el mismo nombre puede funcionar en una oficina y fallar desde un hotel, y por eso vaciar la caché local solo ayuda a veces. Vaciar la caché envía la pregunta otra vez a la misma autoridad.
La prueba que los distingue es una consulta directa a cada servidor publicado.
Consulta cada autoridad directamente
Empieza por la delegación y no por una lista que recuerdes. Pregunta al padre por el conjunto NS y luego consulta cada nombre de ese conjunto para el registro que te interesa. Dos consultas del mismo nombre en autoridades distintas te dicen de inmediato si la zona es coherente.
dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A
Haz lo mismo con los registros NS del ápice de la zona, porque la delegación del padre y el conjunto NS propio de la zona pueden discrepar tras una migración. Los números de serie del SOA son lo siguiente que hay que comparar, y un secundario muy atrasado es un problema de transferencia, no de respuesta.
Ejecuta esas consultas desde la red que falla, no solo desde tu escritorio.
Separa las vistas previstas de las rotas
Algunos dominios responden a propósito de forma distinta según la región o el grupo de resolutores, y las configuraciones de horizonte dividido son normales en redes empresariales.
La cuestión es si la diferencia está documentada y es estable. Una vista no prevista se ve distinta: una autoridad tiene un registro que las demás nunca recibieron, o le falta uno que todas comparten. La guía RFC 2182 de selección y despliegue trata la disponibilidad autoritativa como una responsabilidad compartida, y ese es el marco correcto aquí. La redundancia solo existe si cada servidor publicado puede responder con los datos previstos, no solo aceptar una conexión en el puerto 53.
Un servidor que responde SERVFAIL es más fácil de diagnosticar que uno que responde con seguridad y de forma errónea.
Una migración expone lo que una caché ocultaba
Durante un traslado de proveedor cambian dos ubicaciones autoritativas: la delegación del padre y los registros NS propios de la zona. Ambas hay que actualizarlas, y ambas se guardan en caché durante sus TTL. Si un servidor antiguo sigue en pie y sigue sirviendo la zona anterior, los clientes cuyos resolutores le preguntan seguirán recibiendo la respuesta antigua mucho después de que la migración pareciera completa.
Ese es exactamente el estado que oculta una caché longeva. La estación de trabajo que funcionó toda la semana hablaba con un resolutor que tenía una respuesta fresca de la nueva autoridad, mientras el viejo seguía repartiendo datos obsoletos a todos los demás.
Cambiar el resolutor en un portátil arregla ese portátil y nada más.
Arregla la zona, no el resolutor
Identifica qué servidores deben ser autoritativos para la zona, corrige la zona gestionada o la delegación para que cada uno de ellos sirva los datos previstos, y conserva la redundancia que planeaste. Borrar un servidor de nombres porque una salida VPN recibió una respuesta rara reduce la disponibilidad y deja la incoherencia en su sitio.
Después vuelve a ejecutar las consultas directas desde ambas redes y espera a que caduque el TTL del registro que cambiaste.
Confirma que la respuesta es estable desde cada autoridad y escribe la vista prevista en la documentación de la zona para que la próxima diferencia sea fácil de clasificar.