Por qué las respuestas DNS varían según la ubicación

Un dominio puede devolver respuestas DNS distintas a personas situadas en lugares diferentes sin que ninguna de ellas sea errónea. Los proveedores de DNS y las CDN pueden usar enrutamiento geográfico o basado en latencia para dirigir a los usuarios hacia infraestructura regional. Los resolvedores recursivos también pueden tener valores distintos en caché, y las redes corporativas pueden usar DNS de horizonte dividido para dar a los empleados una respuesta interna mientras internet recibe otra diferente. La dirección que ves es, por tanto, el resultado del nombre de host, el tipo de registro, el resolvedor, la ubicación y el momento. Una única consulta no puede representar todas las vistas posibles, así que las comparaciones deben conservar ese contexto.

DNS geográfico y basado en latencia

Un proveedor con enrutamiento geográfico evalúa cada consulta y selecciona una respuesta según las regiones configuradas, las mediciones de red o las políticas. Puede devolver un nodo de borde de una CDN cercano o un endpoint de aplicación regional. Por lo general, el proveedor ve el resolvedor recursivo que envió la consulta; ese resolvedor puede estar lejos del usuario final o dar servicio a muchos usuarios. Algunos sistemas usan EDNS Client Subnet para incluir un contexto de red parcial, pero su compatibilidad y su comportamiento en materia de privacidad varían. En consecuencia, una consulta realizada desde una ubicación no siempre describe lo que recibe una persona concreta de esa ubicación a través de su ISP o de su resolvedor corporativo.

El almacenamiento en caché es otra fuente de variación. Un resolvedor puede conservar todavía una respuesta anterior mientras otro ya ha obtenido la nueva. Reducir un TTL no acorta con carácter retroactivo un valor que ya está en caché con un TTL anterior. Los sistemas operativos y las aplicaciones locales también pueden añadir su propio comportamiento de caché. Si un registro se modificó hace poco, anota el TTL anterior y cuándo se publicó el cambio. Da tiempo a que las cachés caduquen y consulta los servidores de nombres autoritativos para verificar la propia zona antes de concluir que una actualización ha fallado.

Cómo investigar una discrepancia

Compara exactamente el mismo nombre de host y tipo de registro a través de resolvedores concretos, y anota dónde y cuándo se ejecutó cada consulta. Consulta los servidores de nombres autoritativos para ver qué publica la zona en este momento. Si solo difieren las respuestas recursivas, considera la antigüedad de la caché, la política del resolvedor o la geografía. Si los servidores autoritativos no coinciden, revisa la sincronización del proveedor y la delegación. Si los usuarios internos y externos ven valores distintos, pregúntate si el DNS de horizonte dividido es intencionado. Por último, prueba el propio endpoint del servicio: dos direcciones DNS diferentes pueden llevar ambas a copias sanas de la aplicación, o respuestas idénticas pueden fallar las dos por motivos ajenos al DNS.

• Registra el resolvedor, la ubicación de la consulta, el nombre de host, el tipo de registro, la respuesta y la marca de tiempo.
• Compara los datos autoritativos antes de volver a cambiar registros.
• Ten en cuenta el almacenamiento en caché por TTL y la caché negativa tras editar el DNS.
• Comprueba si hay reglas de CDN y de enrutamiento geográfico que hagan variar las respuestas a propósito.
• Prueba el estado real del servicio con independencia de la resolución de nombres.

Qué no demuestran las respuestas distintas

Que haya respuestas públicas distintas no significa por sí solo que el DNS haya sido secuestrado, que un dominio esté comprometido o que un servidor de origen se haya movido. Pueden ser un comportamiento normal de diseño. Del mismo modo, que las respuestas coincidan no demuestra que todos los visitantes usen la misma ruta, porque las cachés y las capas de aplicación pueden diferir. Busca pruebas que lo corroboren: la configuración del proveedor, los avisos de mantenimiento publicados, los rangos conocidos de CDN y la telemetría de la aplicación. Describe los hallazgos con prudencia, sobre todo cuando la dirección es infraestructura compartida que da servicio a muchos clientes.

Para entender los mecanismos que hay detrás de las respuestas distribuidas, consulta cómo usan las CDN el DNS y el balanceo de carga con DNS. La herramienta de consulta de dominios ofrece una instantánea pública del DNS que resulta útil; repite la misma consulta desde un segundo resolvedor si estás comparando vistas. Conservar el contexto de la consulta junto al resultado convierte una aparente contradicción en evidencia sobre la política de enrutamiento, la caché o la configuración.

Compara respuestas sin borrar el contexto

Una buena tabla comparativa debería incluir la hora de la consulta, la dirección del resolvedor, la ubicación o la red, el nombre de host, el tipo de registro, el código de respuesta, el TTL y los valores de la respuesta. Si los resultados difieren, añade si el resolvedor es público, corporativo o gestionado por el proveedor, y si el dominio usa una CDN. Repite la consulta más tarde para determinar si la diferencia es una política estable o una división temporal de la caché. Si el mismo resolvedor devuelve respuestas distintas en momentos distintos, comprueba si hay balanceo de carga y conmutación por error basada en el estado. Si dos resolvedores difieren de forma constante, investiga la geolocalización o la configuración de horizonte dividido. Este contexto convierte «el DNS es inconsistente» en una observación concreta que el proveedor de DNS puede reproducir y explicar. Al informar de la comparación, evita decir que una respuesta es la correcta a nivel global salvo que hayas confirmado la política de enrutamiento del dominio. Explica si cada respuesta procedía de un servidor autoritativo o de una caché recursiva, y conserva el TTL que se mostraba con ella. Si una CDN devuelve a propósito endpoints regionales, la pregunta correcta es si cada endpoint está sano para su región, no si todos los resolvedores devuelven una misma dirección idéntica. Esta distinción evita que un diseño de enrutamiento esperado se escale como si fuera una caída del DNS.