¿Qué es el TTL en DNS? Valores, caché y cuándo bajarlo
Qué es el TTL en DNS, cómo lo descuentan los resolvers, valores razonables por registro, caché negativa y cómo planificar un cambio sin datos obsoletos.
Publicado: · 7 min de lectura
El TTL ("time to live", tiempo de vida) es el número que acompaña a cada registro DNS e indica cuántos segundos puede un resolver conservar la respuesta en su caché antes de tener que volver a preguntar. Es el único control real que usted tiene sobre la rapidez con que un cambio de DNS llega a los usuarios, y la razón de que la "propagación DNS" tarde lo que tarda.
Cómo funciona el TTL
Cada registro de una zona lleva un TTL:
www.example.com. 3600 IN A 192.0.2.10
Cuando un resolver recursivo (el de su proveedor de Internet, el de su oficina o uno público como 1.1.1.1 u 8.8.8.8) obtiene este registro del servidor autoritativo, lo guarda y empieza a descontar desde 3600. Quien pregunte a ese resolver durante la hora siguiente recibe la copia en caché, con el TTL restante. Cuando el contador llega a cero, la entrada se descarta y la siguiente consulta desencadena una búsqueda nueva.
Se puede ver en directo:
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3412 IN A 192.0.2.10
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3397 IN A 192.0.2.10
El segundo número ha bajado. Si se pregunta directamente al servidor autoritativo, siempre se ve el valor completo configurado:
$ dig +noall +answer www.example.com @ns1.dns.example
www.example.com. 3600 IN A 192.0.2.10
Esa diferencia es un diagnóstico muy útil: un TTL inferior al configurado significa que se está mirando una caché.
Del mecanismo se derivan tres consecuencias:
- Nada se envía de forma activa. Cambiar un registro no avisa a ningún resolver. Cada caché conserva la respuesta antigua hasta que termina su propia cuenta atrás.
- Las cachés caducan en momentos distintos, porque cada una obtuvo el registro en un instante diferente. Durante un TTL como máximo tras el cambio, usuarios distintos ven respuestas distintas. Eso, y nada más, es la "propagación".
- El TTL que cuenta es el antiguo. Un resolver que guardó ayer el registro con un TTL de 86400 lo conservará durante lo que quede de esas 24 horas, ponga usted hoy el valor que ponga.
Cachés que usted no controla
El resolver recursivo no es la única caché. Los sistemas operativos, los navegadores y las aplicaciones tienen la suya, y no todas respetan el TTL al pie de la letra: los navegadores retienen las direcciones durante un tiempo fijo y breve, y las aplicaciones de larga ejecución (los entornos Java antiguos son el caso clásico) pueden conservar una resolución mientras viva el proceso. Algunos resolvers aplican además un mínimo o un máximo: un TTL de 5 segundos puede tratarse como 30 o 60, y los TTL muy largos pueden recortarse a un día aproximadamente. Los resolvers también pueden servir datos caducados durante un rato si los servidores autoritativos no responden.
Así que el TTL es una indicación fuerte, no una garantía, y no es honesto prometer que un cambio será visible "en todas partes" al cabo de exactamente N segundos.
Caché negativa: el TTL de "no existe"
Un resolver también guarda en caché la respuesta "este nombre no existe" (NXDOMAIN) y la de "este nombre no tiene registros de ese tipo". La duración sale del registro SOA de la zona: el menor de dos valores, el TTL del propio registro SOA y su último campo (llamado históricamente "minimum").
$ dig +noall +authority nosuch.example.com
example.com. 300 IN SOA ns1.dns.example. hostmaster.example.com. 2026092001 7200 3600 1209600 300
Esta es la explicación habitual de "he creado el registro, el servidor autoritativo lo devuelve, pero mi resolver sigue diciendo que no existe": alguien (a menudo usted mismo, al comprobar demasiado pronto) consultó el nombre antes de que se creara, y la respuesta negativa quedó en caché. Con un TTL negativo de 300 es una molestia de cinco minutos; con 86400, un día perdido. Manténgalo moderado: los valores entre 300 y 3600 son razonables.
Cómo elegir los valores de TTL
No hay un número correcto único. Es un compromiso entre agilidad y resistencia:
| TTL bajo (60–300) | TTL alto (3600–86400) | |
|---|---|---|
| Los cambios surten efecto | rápido | despacio |
| Los errores | se corrigen rápido | persisten durante horas |
| Carga de consultas en los servidores autoritativos | mayor | menor |
| Latencia de resolución para los usuarios | más fallos de caché | casi todo en caché |
| Si su proveedor DNS sufre una caída | los nombres dejan de resolver en minutos | las respuestas en caché sostienen a los usuarios |
La última fila se olvida a menudo. Un TTL largo es un seguro gratuito contra una caída breve del DNS.
Puntos de partida sensatos:
| Registro | TTL típico | Motivo |
|---|---|---|
A/AAAA de un sitio web estable |
3600 | los cambios son raros y planificados |
A/AAAA usados para conmutación por error o tras un balanceador |
60–300 | deben moverse rápido; a menudo los fija el proveedor |
CNAME hacia un SaaS o una CDN |
3600 | el TTL del destino gobierna la dirección final |
MX |
3600–86400 | los servidores de correo cambian poco; los remitentes reintentan de todos modos |
TXT (SPF, DKIM, DMARC) |
3600 | bájelo antes de las ediciones planificadas |
NS y SOA |
86400 | estables; el TTL de la delegación en la zona padre no depende de usted |
CAA |
3600–86400 | las CA respetan su TTL al volver a comprobarlo |
Si su proveedor ofrece la opción "Auto", suele equivaler a 300 segundos, que sirve para la mayoría de los sitios.
Planificar un cambio con el TTL
La rutina para mover un sitio web, un servidor de correo o cualquier otra cosa que esté detrás de un nombre DNS:
- Consulte el TTL actual en el servidor autoritativo. Llamémoslo T.
- Bájelo a 300 (no menos: algunos resolvers ignoran los valores muy pequeños) y espere al menos T. Solo cuando T haya pasado se puede estar seguro de que todas las cachés tienen la versión de 300 segundos.
- Haga el cambio.
- Verifique contra el servidor autoritativo y contra unos cuantos resolvers públicos.
- Mantenga en marcha el destino antiguo durante al menos el nuevo TTL (siendo realistas, unas horas), por las cachés que no siguen las reglas.
- Vuelva a subir el TTL cuando esté seguro de que no va a dar marcha atrás.
Bajar el TTL y cambiar el registro en la misma edición es el error clásico: los resolvers que importan tienen el registro antiguo con el TTL antiguo y ni siquiera verán el nuevo TTL hasta que aquel caduque.
Tenga en cuenta que, en un cambio de servidores de nombres, interviene un segundo TTL: el de la delegación en la zona padre, que suele ser de dos días y que usted no puede modificar. Un cambio de servidores de nombres necesita, por eso, un plan propio y más margen.
TTL y cadenas de CNAME
Cuando un nombre es un CNAME, el resolver guarda cada eslabón por separado, cada uno con su propio TTL:
www.example.com. 3600 IN CNAME site.cdn.example.
site.cdn.example. 60 IN A 203.0.113.20
La CDN puede mover su registro A en un minuto, pero si usted quiere apuntar www a una CDN distinta, se aplica su propio 3600. El retraso efectivo de un cambio concreto es el TTL del registro que se modifica, no el más pequeño de la cadena.
¿Se puede vaciar la caché?
La propia, sí.
# macOS
$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
> ipconfig /flushdns
# Linux con systemd-resolved
$ resolvectl flush-caches
Algunos resolvers públicos ofrecen un formulario web para purgar un nombre de su caché, lo que ayuda tras un error. Los resolvers de los demás no se pueden tocar. No existe un vaciado global, y cualquier servicio que prometa "forzar la propagación" vende un botón que no hace nada.
Errores frecuentes
- Bajar el TTL en el mismo momento del cambio, o cinco minutos antes.
- Dejarlo todo a 60 segundos para siempre "por flexibilidad" y caer después junto con el proveedor DNS.
- Un TTL de un día en un registro que forma parte de un plan de conmutación por error.
- Olvidar el valor de caché negativa y consultar un nombre antes de crearlo.
- Tomar una consulta hecha desde el propio portátil como prueba de lo que ven los usuarios.
- Creer que un porcentaje en un "comprobador de propagación" describe todo Internet. Describe las ubicaciones que esa herramienta consultó.
Compruébelo con OrbitProbe
La consulta DNS de OrbitProbe muestra el TTL junto a cada registro que devuelve, tal como lo ven los resolvers públicos en ese momento. Antes de una migración, sirve para localizar los TTL que hay que bajar; después del cambio, ejecútela de nuevo para confirmar el valor nuevo y observar el TTL restante. Para una visión general de qué registros existen, consulte tipos de registros DNS; y si el cambio forma parte de un arreglo de la entrega del correo, la lista de comprobación DNS para correos que llegan a spam.