Entender el TTL de DNS: por qué los cambios tardan en verse

Todo registro DNS lleva un TTL (time to live, tiempo de vida) expresado en segundos. Es una instrucción del servidor de nombres autoritativo del dominio a cada resolvedor que obtiene el registro: «puedes reutilizar esta respuesta durante este tiempo antes de volver a preguntar». Un TTL de 300 segundos significa que un resolvedor que acaba de consultar un dominio no se molestará en volver a preguntar durante cinco minutos, aunque el registro cambie entretanto.

El equilibrio que busca el TTL

Un TTL más largo significa menos consultas DNS, búsquedas más rápidas en promedio (porque más solicitudes se sirven desde la caché) y menos carga en los servidores de nombres autoritativos. Un TTL más corto significa que un cambio en el registro se propaga más rápido, a costa de consultas más frecuentes. No hay un valor universalmente correcto: depende de con qué frecuencia se espera que cambie el registro y de cuánta tolerancia haya a las respuestas obsoletas.

Qué ocurre realmente durante un cambio

Actualizar un registro DNS no envía el cambio a todos los resolvedores de internet. Solo cambia lo que dirá el servidor de nombres autoritativo la próxima vez que se le pregunte. Todos los resolvedores que ya guardaron en caché la respuesta antigua siguen sirviéndola hasta que caduca el TTL de su copia, y por eso un mismo dominio puede resolverse brevemente a direcciones distintas según qué resolvedor, y qué caché, esté respondiendo.

• Una medida práctica habitual antes de una migración planificada es bajar el TTL uno o dos días antes, para que el cambio definitivo se propague más rápido.
• Después de la migración, el TTL suele volver a subirse a su valor normal.
• Un registro sin cambios recientes y con un TTL largo puede tardar toda esa ventana de TTL en desaparecer por completo de las cachés del mundo cuando por fin cambia.

Elegir un TTL en la práctica

Las respuestas negativas también se guardan en caché, algo fácil de pasar por alto. Cuando un dominio no existe, la propia respuesta NXDOMAIN se guarda en caché, regida por un valor distinto (el TTL mínimo del registro SOA, no el TTL de un registro que ni siquiera existía). Un dominio recién registrado a veces puede parecer que no se resuelve durante un breve periodo simplemente porque un resolvedor ya había guardado en caché su NXDOMAIN de antes de que terminara el registro.

El TTL es una petición, no una garantía

Conviene saber que un TTL es orientativo y que ninguna autoridad externa lo impone. Técnicamente, un resolvedor es libre de guardar una respuesta en caché más tiempo que el TTL indicado (algunos lo hacen bajo carga elevada para reducir el volumen de consultas) o de descartarla antes (un resolvedor con poca memoria puede eliminar entradas de la caché antes de tiempo). En la inmensa mayoría de los casos, los resolvedores públicos y de ISP bien gestionados respetan los TTL de forma estrecha y predecible, pero por eso una estimación de propagación basada en el TTL es una buena regla general y no una garantía firme y contractual. Si un cambio sigue sin verse de forma significativa pasada la antigua ventana del TTL, una caché intermedia inusualmente agresiva es una de las explicaciones menos comunes pero reales que conviene tener presentes.

Si estás verificando que un cambio de DNS ya está en marcha, una única consulta solo te dice qué tiene en caché un resolvedor en ese momento. Repetir la consulta con unos minutos de diferencia, o programar una comprobación recurrente, es una forma mucho más fiable de confirmar que un cambio se ha propagado de verdad, en lugar de captar una vez una respuesta obsoleta de la caché y darla por definitiva.