El papel de la configuración de DNS TTL

Toda respuesta DNS lleva un número asociado: el Time to Live, o TTL. Es fácil pasarlo por alto, porque los paneles DNS rellenan un valor por defecto y la mayoría de la gente nunca lo toca. Sin embargo, ese único valor decide con qué rapidez llega a los usuarios un cambio en su web, su correo o su API, cuánta carga soportan sus servidores de nombres y con qué elegancia sobrevive su dominio a una caída del proveedor. Entender el TTL marca la diferencia entre una migración que termina en cinco minutos y otra que se alarga durante un día entero.

Esta guía explica qué hace realmente el TTL, cómo elegir valores razonables, cómo planificar una migración teniéndolo en cuenta y por qué las cachés del mundo real no siempre respetan el número que usted fija.

Qué significa el TTL en el DNS

El TTL es un campo presente en cada registro de recurso y se mide en segundos. Cuando un resolutor recursivo, como el de su proveedor de internet o uno público como 1.1.1.1 u 8.8.8.8, obtiene un registro de un servidor de nombres autoritativo, guarda la respuesta y empieza a descontar el TTL. Hasta que llega a cero, el resolutor responde desde su caché sin volver a preguntar al servidor autoritativo. Cuando caduca, la siguiente consulta provoca una búsqueda nueva.

Puede observar esa cuenta atrás con dig. Ejecute la misma consulta dos veces contra un resolutor y el TTL de la sección de respuesta será menor la segunda vez:

dig @8.8.8.8 example.com A +noall +answer
example.com.    2873    IN    A    93.184.215.14

Para ver el valor original fijado por el propietario de la zona, pregunte directamente a un servidor de nombres autoritativo:

dig NS example.com +short
dig @ns1.example-dns.net example.com A +noall +answer

La famosa “propagación DNS” es en realidad esto: miles de cachés independientes que van caducando la respuesta antigua cada una a su ritmo. No se envía nada a ninguna parte; las cachés simplemente olvidan.

Ventajas e inconvenientes de los TTL cortos y largos

Ningún TTL es adecuado para todos los registros. Cada elección equilibra agilidad frente a eficiencia y resiliencia.

Un TTL largo también funciona como red de seguridad. Si su proveedor de DNS autoritativo se cae, los resolutores que guardaron sus registros hace una hora siguen respondiendo durante el resto de esa hora. Con un TTL de 60 segundos, los usuarios notan la caída casi de inmediato. Y los TTL cortos tampoco salen gratis en rendimiento: cada fallo de caché añade un viaje de ida y vuelta a los servidores autoritativos.

Cómo elegir valores para cada tipo de registro

A, AAAA y CNAME

Para una web alojada en un servidor estable, una hora es una base razonable. Si usa una CDN o un balanceador de carga gestionado, siga las indicaciones del proveedor; muchos usan TTL cortos en sus propios registros para poder dirigir el tráfico, mientras que su CNAME hacia ellos puede mantener un valor más largo.

MX y TXT relacionados con el correo

El enrutamiento del correo cambia rara vez, y los servidores remitentes reintentan durante días si la entrega falla, así que de unas horas a un día es adecuado. Bájelo con antelación si va a cambiar de proveedor de correo.

Registros NS

Los registros NS que realmente cuentan para la delegación están en la zona padre y los controla el registro del TLD, a menudo con un TTL de uno o dos días. Por eso cambiar los servidores de nombres en su registrador tarda más que cambiar un registro A. Puede comprobar a qué servidores de nombres delega actualmente un dominio con la consulta WHOIS de TLDix.

SOA

El registro SOA contiene los temporizadores de los servidores secundarios y el valor de caché negativa que veremos más adelante. Su propio TTL suele ser de una hora o más.

Bajar el TTL antes de una migración

La técnica práctica más útil con el TTL es reducirlo antes de un cambio planificado. El detalle que suele pasarse por alto es el momento: los resolutores solo conocen su TTL nuevo y más bajo después de que caduque la copia que tienen en caché con el TTL antiguo.

1. Compruebe el TTL actual en el servidor autoritativo. Supongamos que es de 86400 segundos.
2. Bájelo a 300 segundos al menos 24 horas antes de la migración, es decir, un TTL antiguo completo. Esperar un poco más es más seguro.
3. Haga el cambio, por ejemplo apuntando el registro A al nuevo servidor. La mayoría de las cachés se actualizarán ahora en cinco minutos.
4. Mantenga el servidor antiguo en marcha durante un tiempo, porque algunos clientes irán con retraso.
5. Vuelva a subir el TTL a su valor normal cuando el tráfico y los registros de acceso confirmen que el traslado ha terminado.

; 24+ hours before
www.example.com.   300    IN  A  203.0.113.10
; migration moment
www.example.com.   300    IN  A  198.51.100.20
; after verification
www.example.com.   3600   IN  A  198.51.100.20

Si se salta el paso 2 y cambia el registro mientras el TTL sigue siendo de un día, algunos usuarios llegarán al servidor antiguo durante hasta un día.

Caché negativa y el mínimo del SOA

Los resolutores también guardan en caché la ausencia de un registro. Cuando un nombre no existe (NXDOMAIN) o existe pero sin el tipo solicitado (NODATA), la RFC 2308 permite al resolutor guardar esa respuesta negativa. Su duración es el menor valor entre el TTL del propio registro SOA y el último campo del SOA, llamado históricamente “minimum”.

dig example.com SOA +noall +answer
example.com. 3600 IN SOA ns1.example-dns.net. hostmaster.example.com. 2026100701 7200 3600 1209600 3600

Aquí, el 3600 final significa que una consulta fallida puede recordarse durante una hora. Esto causa problemas cuando se consulta un subdominio nuevo antes de crearlo: una comprobación de monitorización, un intento de validación de certificado o una prueba impaciente guardan en caché el NXDOMAIN, y el nuevo registro parece entonces “no propagarse”. Para evitarlo, cree los registros antes de que nada los busque y mantenga un TTL negativo moderado en el SOA, normalmente entre 300 y 3600 segundos.

Cuando los resolutores recortan o ignoran su TTL

El TTL que publica es un máximo, no una garantía. Varias capas pueden modificarlo:

• Límites del resolutor. Programas como BIND y Unbound tienen tiempos máximos de caché configurables, y los operadores pueden fijar mínimos para que los TTL muy cortos se eleven. El máximo por defecto de BIND es de una semana, y su caché negativa está limitada por defecto a tres horas.
• Serve-stale. La RFC 8767 permite a los resolutores seguir respondiendo con datos caducados cuando los servidores autoritativos no están accesibles. Mejora la resiliencia, pero puede alargar la vida de respuestas antiguas.
• Sistemas operativos y navegadores. Los resolutores stub locales y los navegadores mantienen sus propias cachés breves, independientes del resolutor de red.
• Aplicaciones. Los procesos de larga duración pueden resolver un nombre una sola vez y reutilizar la dirección, y algunos entornos de ejecución tienen su propia configuración de caché DNS.

En resumen: cuente con una cola larga. Tras cualquier cambio, espere que la mayor parte del tráfico se traslade dentro del TTL y que una pequeña fracción se rezague durante más tiempo.

Supervisión y buenas costumbres

• Documente el TTL normal de cada registro para que las reducciones temporales no caigan en el olvido.
• Tras cada cambio, compare las respuestas autoritativas con las de varios resolutores públicos.
• Evite TTL por debajo de 30 segundos salvo que su proveedor los necesite específicamente.
• Acompañe los cambios de DNS con un seguimiento de las caducidades del dominio, los certificados y el alojamiento, porque un dominio caducado rompe el DNS sea cual sea el TTL.

Si quiere repasar qué hace cada tipo de registro, lea nuestra guía sobre los fundamentos de los registros DNS.