¿Qué TTL usar en los registros DNS?

Todo registro DNS tiene un campo pequeño que suele quedarse en el valor que sugirió el panel: el TTL. Decide cuánto tarda un cambio en llegar a tus visitantes, cuántas consultas recibe tu proveedor de DNS y si tu sitio sigue accesible cuando algo sale mal.

No existe un valor único correcto, sino el valor correcto para cada registro y para cada momento. La elección se vuelve sencilla cuando sabes qué controla el TTL y cuánto cuesta quedarte corto o pasarte.

¿Qué controla el TTL?#

El TTL (time to live) es la cantidad de segundos que un resolver puede guardar en caché la respuesta de un registro antes de volver a preguntar al servidor autoritativo. La RFC 1035 define el campo, y la RFC 2181 fija el máximo en 2147483647 segundos. Los resolvers pueden imponer un tope menor: la RFC 8767 recomienda limitarlo a 7 días (604800 segundos).

Es un intercambio directo, que la documentación de TTL de Cloudflare resume así: un TTL largo aumenta la probabilidad de que la respuesta esté en caché y acelera las consultas, pero hace que los cambios tarden más en aplicarse. En el peor caso, un cambio tarda el TTL antiguo completo en aplicarse, como explica el artículo sobre propagación de DNS.

¿Qué criterios definen el TTL correcto?#

Antes de elegir un número, responde cinco preguntas:

1. ¿Con qué frecuencia cambia este registro? Un MX que no cambia desde hace años aguanta un TTL largo. El registro A de un servidor que podrías reemplazar el mes que viene, no.
2. ¿Necesitas cambiar el destino rápidamente en una emergencia? Si tu plan de contingencia es apuntar el dominio a otro servidor, el TTL es el tiempo mínimo de recuperación para quien ya lo tiene en caché.
3. ¿Cuántas consultas recibe el dominio? Algunos proveedores de DNS cobran por consulta. La documentación de Route 53 recuerda que un TTL mayor reduce las llamadas de los resolvers, la latencia y la factura.
4. ¿Qué pasa si el DNS autoritativo se cae? Con un TTL largo, los resolvers siguen respondiendo desde la caché por más tiempo.
5. ¿El registro está detrás de un proxy o una CDN? En ese caso, el visitante recibe la IP del borde, y el proveedor suele fijar el TTL.

¿Cuáles son los valores comunes y sus pros y contras?#

Los valores por debajo de 60 segundos rara vez compensan. Muchos proveedores ni siquiera los permiten: cada uno define un mínimo y un máximo, a veces distintos según el plan, como muestra la documentación de TTL de Cloudflare.

¿Qué TTL usar en cada tipo de registro?#

Los tipos se explican en qué son los registros DNS. Esta es la recomendación para cada uno:

• A y AAAA (la IP del sitio o la API): 3600 si el servidor es estable; 300 si todavía puedes cambiar de hosting o de IP. Si tu hosting te pide un CNAME en lugar de un registro A, sigue esa indicación, como muestra A vs CNAME.
• CNAME: 3600 en la mayoría de los casos. El destino del CNAME tiene su propio TTL, controlado por quien opera ese nombre, y el resolver respeta ambos.
• MX (correo): 3600 o más. El correo tolera bien los cambios lentos, porque los servidores de envío reintentan.
• TXT (SPF, DKIM, verificación de dominio): 3600. Al configurar una verificación nueva, 300 te permite corregir un error de tipeo sin esperar.
• NS: 86400 o el valor que defina tu proveedor de DNS. La delegación en la zona padre (como .com o .mx) tiene su propio TTL, definido por el operador del TLD, y no lo controlas tú.
• Registros con health check y failover: 60 segundos o menos. Es la recomendación de la documentación de failover de Route 53, para que los clientes reaccionen rápido a los cambios de estado.

También existe la caché de respuestas negativas. Si alguien consulta un nombre antes de que lo crees, el resolver guarda el "no existe" durante el menor valor entre el TTL del SOA y el campo MINIMUM del SOA, según la RFC 2308. Si creas subdominios con frecuencia, un MINIMUM de 300 a 3600 evita esperas largas.

¿Qué TTL usar antes de una migración?#

El TTL que cuenta en un cambio es el del registro antiguo, no el del nuevo. Por eso la reducción tiene que ir antes:

1. Anota el TTL actual. Si es 86400, necesitas 1 día de antelación.
2. Reduce el TTL a 300 (o 60, si cada minuto cuenta).
3. Espera a que pase el TTL antiguo completo.
4. Cambia el valor del registro y confirma que todo funciona.
5. Vuelve a subir el TTL a 3600 o más.

Es la misma rutina que recomienda la documentación de Route 53: empezar con un valor corto, como 300 segundos, y aumentarlo después de confirmar que la configuración nueva es correcta. Para los pasos de apuntar el dominio, mira cómo apuntar un dominio a tu hosting.

¿Un TTL muy bajo tiene desventajas?#

Sí, y por eso no vale la pena dejar 60 segundos en todo "por si acaso":

• Más consultas. Cada resolver vuelve al autoritativo cada minuto. Con proveedores que cobran por consulta, se nota en la factura.
• Primera visita más lenta. Cuanto menos tiempo pasa la respuesta en caché, más visitantes pagan el viaje completo hasta el autoritativo.
• Menos resistencia a fallos. Si tu proveedor de DNS sufre un ataque o se cae, un TTL largo mantiene el dominio respondiendo desde la caché. La RFC 8767 describe resolvers que sirven respuestas expiradas en ese caso, pero no todos lo hacen.

El equilibrio para la mayoría de los proyectos es 300 durante los cambios y 3600 el resto del tiempo.

¿Cómo comprobar el TTL de un registro?#

Usa dig. Primero, averigua los servidores autoritativos del dominio:

dig NS ejemplo.com +short

Si consultas uno de ellos directamente, ves el TTL configurado. Si consultas un resolver público, ves cuánto le falta a esa caché para expirar:

dig @ns1.proveedor-dns.example ejemplo.com A +noall +answer
dig @8.8.8.8 ejemplo.com A +noall +answer

En la respuesta, el número entre el nombre e IN es el TTL en segundos. Consulta el resolver dos veces: el número baja hasta que la caché expira.

Para ver el valor usado en la caché negativa, consulta el SOA. El último número de la respuesta es el campo MINIMUM:

dig ejemplo.com SOA +short

Cómo hacerlo en Square Cloud#

En Square Cloud, el dominio personalizado está disponible a partir del plan Standard. El panel muestra los registros DNS que necesitas, y tú los creas en tu registrador o proveedor de DNS. Como la zona sigue en tus manos, es ahí donde defines el TTL, con los criterios de arriba.

El panel muestra el estado de validación en tiempo real, emite el TLS automáticamente y acepta dominios con acentos (Punycode). Si traes un dominio que ya apunta a otro lugar, reduce el TTL antes de cambiar los registros y sigue la validación desde el panel.

Mientras tanto, toda aplicación web sigue accesible por su subdominio *.squareweb.app con HTTPS, en todos los planes. Mira cómo configurarlo en la página de dominios.