DNS e infraestructura
TTL DNS: la palanca que olvidan en migraciones
Cómo usar TTL bajos para cambios seguros de hosting, CDN o correo sin días de inconsistencia.
10 min de lectura · Actualizado 2026-07-22
Qué es TTL y por qué importa en cutovers
TTL (Time To Live) en segundos indica cuánto tiempo un resolver puede cachear una respuesta DNS sin reconsultar al authoritative. TTL 3600 = una hora de «memoria» del valor viejo aunque ya cambiaste el panel.
Migración sin bajar TTL antes: cambias A record viernes 18:00, usuarios con cache de 24h siguen al servidor viejo hasta sábado tarde. Soporte recibe «sitio caído» intermitente imposible de reproducir localmente.
TTL bajo (300s) aumenta consultas al authoritative — ligera carga extra aceptable durante ventana de migración. TTL alto en steady state reduce latencia y costo de queries.
TTL es por registro. MX puede tener 3600 mientras A ya está en 300 si los cambiaste en momentos distintos — planifica holísticamente.
Plan de 48 horas estándar
T-48h: identifica registros afectados (A, AAAA, CNAME www, MX si aplica). Baja TTL a 300 en todos. Espera que expire cache previo (mínimo TTL antiguo máximo, ej. si era 86400 espera 24h real).
T-0: ejecuta cambio de valor (nueva IP, nuevo MX, nuevo CNAME). Monitorea /toolbox/dns-propagation cada 10–15 min primera hora.
T+24h: tráfico estable en destino nuevo, correo fluye, TLS OK (/toolbox/web-check). Sube TTL a 3600 o 14400 según política.
Documenta TTL previo y nuevo en ticket de cambio para auditoría.
TTL en escenarios específicos
Solo correo (MX): baja TTL MX y registros A del host MX si cambian. TXT SPF/DKIM pueden mantener TTL alto — no cambian en cutover MX típico.
CDN/proxy: algunos CDNs piden TTL 300 permanente en proxied records — aceptable si el proveedor recomienda; documenta excepción.
Failover DR: TTL bajo permanente en registros de conmutación acelera DR pero aumenta carga — trade-off consciente en DevOps.
Delegación NS cambio de registrador: TTL en glue y NS propios — proceso distinto, semanas de propagación posible; no acelerable solo bajando A.
Errores comunes
Bajar TTL y cambiar registro en la misma hora sin esperar expiración del TTL anterior — mezcla cache largo y corto simultáneo. Espera el max TTL viejo tras bajar.
Olvidar TTL en subdominio api.tudominio.com mientras migras apex — integraciones siguen al viejo.
Subir TTL a 86400 inmediatamente tras cutover « porque propagó en mi Chrome» — resolvers corporativos aún en transición.
Dos zonas activas con TTL distintos — caos. Un authoritative.
Checklist y herramientas
□ TTL 300 publicado ≥48h antes □ Export zona pre-cambio □ Cutover en ventana acotada □ Propagation checker multi-región □ Validación funcional web+correo □ TTL restaurado tras 24–48h estable □ Runbook actualizado.
/toolbox/dns-suite muestra TTL actual por registro — útil para verificar que el bajo TTL realmente aplicó (no solo guardaste en panel sin publicar).
Combina con guía propagacion-dns-checklist para migraciones completas.
Migraciones zero-downtime con balanceo DNS (weighted records) requieren diseño DevOps — TTL es una palanca, no la única en arquitecturas avanzadas.
Ponlo en práctica ahora
Usa las herramientas gratuitas del Toolbox para validar tu configuración en minutos.
¿Necesitas que lo resolvamos contigo?
Un ingeniero de Conecta puede aplicar esto en tu operación: servicio relacionado o conversación directa.