Planteamiento y alcance
Esta pregunta de tecnología general evalúa los fundamentos de redes y la resolución de problemas. La clave es separar un registro autoritativo actualizado de una respuesta antigua retenida por un resolver recursivo o un cliente.
Qué evalúa el entrevistador
- Explicar los roles de un stub resolver, un resolver recursivo y un servidor autoritativo.
- Razonar correctamente sobre TTL, almacenamiento en caché negativo (negative caching) y tipos de registros independientes.
- Utilizar consultas desde múltiples ubicaciones y resolvers para aislar un problema de caché o de delegación.
- Planificar una transición de DNS reversible en lugar de limitarse a decir a los usuarios que limpien sus cachés.
Preguntas de aclaración que debe hacer
Confirme si el cambio es de tipo A, AAAA, CNAME o delegación NS; si ambos endpoints están en buen estado; si el problema es global o está limitado a un proveedor, región o red; el TTL antiguo y los parámetros de caché negativo del SOA; el estado de DNSSEC; y si la aplicación fija resultados (pinning) o utiliza pools de conexiones.
La respuesta de 30 segundos
Consultaría primero el servidor autoritativo y luego compararía la respuesta y el TTL restante de varios resolvers públicos y redes afectadas. Si la autoridad es correcta pero la recursión devuelve datos antiguos, la causa es la caché o un TTL upstream. Si la autoridad es inconsistente, inspeccione la delegación, la publicación de la zona y la automatización. Antes de la transición, reduzca el TTL y espere a que transcurra la ventana de tiempo del TTL antiguo, mantenga ambos endpoints en buen estado, observe el tráfico y solo entonces retire el antiguo.
Análisis detallado paso a paso
1. Dibujar la ruta de consulta real
Por lo general, una aplicación recurre a un stub resolver del navegador o del sistema operativo, el cual pregunta a un resolver recursivo. El resolver recursivo devuelve una respuesta en caché cuando esta es reciente o sigue a los servidores raíz (root), TLD y autoritativos cuando no lo es. El servidor autoritativo almacena el registro de la zona. Cada capa puede tener su propia caché y tiempos de actualización.
2. Explicar el tiempo con el TTL y el almacenamiento en caché negativo
Un TTL más largo mejora la tasa de aciertos de caché (cache hit rate) y reduce la carga de consultas, pero retrasa los cambios. Las respuestas existentes en caché generalmente permanecen hasta que su TTL antiguo llega a cero. Las respuestas negativas también se pueden almacenar en caché según los parámetros relacionados con el SOA, por lo que un nombre recién creado aún puede parecer inexistente. Mida el TTL restante por tipo de registro y por resolver en lugar de prometer una única duración de propagación.
3. Hacer que la investigación sea reproducible
Consulte el servidor autoritativo y verifique que la delegación sea consistente. Luego consulte el mismo nombre, tipo y flags a través de múltiples resolvers recursivos, regiones y redes, registrando la respuesta, el TTL, el código de respuesta y la hora. Los patrones "autoridad correcta, recursión antigua", "autoridad inconsistente" y "solo un cliente desactualizado" apuntan respectivamente a la caché, a la publicación/delegación y a capas locales.
4. Descartar direcciones obsoletas ajenas al DNS
Los proxies HTTP, las CDN, la configuración de la aplicación, los pools de conexiones, el service discovery o un archivo hosts pueden seguir utilizando una dirección antigua después de que el DNS sea correcto. Compruebe la IP de destino real, el certificado TLS, los encabezados de respuesta y los logs del balanceador de carga para demostrar que el fallo reside en la resolución y no en el enrutamiento o en la caché de la aplicación.
5. Planificar una transición segura
Reduzca el TTL a un valor aceptable para el negocio antes del cambio y espere a que transcurra la ventana de tiempo del TTL anterior; mantenga disponibles tanto el endpoint antiguo como el nuevo de forma simultánea. Tras el cambio, monitoree la distribución de respuestas, los errores y el tráfico real por región y resolver. Conserve el endpoint antiguo hasta que se cierre la ventana de riesgo y prepare degradación a nivel de aplicación o servicio dual, ya que el rollback de DNS también depende de las cachés.
Un ejemplo de respuesta sólida
Verificaría primero el registro autoritativo y la delegación, luego consultaría varios resolvers recursivos y redes afectadas mientras registro las respuestas y el TTL restante. Una autoridad actualizada con una respuesta recursiva antigua significa expiración de caché; una autoridad inconsistente apunta a la publicación de la zona, NS o automatización; unos pocos dispositivos anómalos apuntan a la caché local, archivo hosts, proxy o al estado del pool de conexiones. El TTL controla cuánto tiempo se puede usar una respuesta antigua y el almacenamiento en caché negativo afecta a los nombres nuevos, por lo que no prometería un tiempo de propagación fijo. Bajaría el TTL antes de la transición, mantendría ambos endpoints activos, monitorearía el tráfico real y los errores, y retiraría el endpoint antiguo solo tras la ventana de riesgo.
Errores comunes
- Afirmar que la propagación del DNS siempre finaliza en pocos minutos.
- Limpiar la caché de una sola laptop y tomar eso como evidencia global.
- Consultar únicamente a un proveedor de DNS público.
- Actualizar el registro A olvidando AAAA, CNAME, NS o DNSSEC.
- Apagar el servicio antiguo inmediatamente después de cambiar la autoridad.
- Culpar al DNS cuando una CDN, proxy o archivo hosts está sirviendo la dirección antigua.
Preguntas de seguimiento y respuestas
¿Por qué un nuevo registro sigue devolviendo NXDOMAIN?
Es posible que un resolver upstream haya almacenado en caché la respuesta negativa según los parámetros relacionados con el SOA. Confirme que el registro autoritativo existe y espere a que expire la caché negativa.
¿Por qué sigue apareciendo la respuesta antigua tras reducir el TTL?
Reducir el TTL afecta a las entradas de caché obtenidas recientemente; las entradas existentes siguen descontando su TTL antiguo. Verifique también que se modificaron el registro, la zona y el servidor autoritativo correctos.
¿Se puede forzar a todos los usuarios a actualizar el DNS?
No. Los resolvers recursivos y los clientes están fuera de su control. Reduzca el riesgo con un cambio temprano de TTL, endpoints duales, enrutamiento a nivel de aplicación y monitoreo.
¿Cómo detectar si IPv6 es la causa?
Consulte y pruebe A y AAAA por separado, registrando la familia de direcciones utilizada realmente por los clientes. Si AAAA sigue apuntando al endpoint antiguo, corríjalo de forma independiente.