El vendedor promete una migración de fin de semana “sin interrupciones”. El TTL del registro A sigue siendo 86400 desde hace años. Viernes 18:00 horas: nueva dirección IP activada en la zona. Sábado al mediodía: 40% del tráfico en el host antiguo, 60% en el nuevo: sesiones rotas, la mitad de webhooks de socios en cada IP. El soporte lo llama "propagación DNS lenta"; en realidad, TTL no preparado.
TTL (Time To Live) indica a los resolutores cuánto tiempo deben almacenar en caché su respuesta DNS. Migrar sin gestión TTL significa prometer lo instantáneo, mientras que la física del caché requiere esperar el antiguo TTL en todas partes.
Ciclo de migración compatible con TTL
- D-7 a D-2: reduzca el TTL a 300 s en los registros A/AAAA/CNAME migrados.
- Espere el TTL máximo anterior (a menudo 24 horas si el valor es 86400).
- Preparar el nuevo origen (sincronización de contenido, certificado TLS, pruebas mediante archivo hosts).
- Transición: cambia IP o CNAME al nuevo origen.
- Monitorear el tráfico mixto de dos a veinticuatro horas.
- D+7: aumente el TTL a un valor moderado (3600) si lo desea.
| TTL directo | Espera mínima antes de la transición | Ventana mixta típica |
|---|---|---|
| 86400 (24 horas) | 24 horas | hasta 24 horas |
| 3600 (1 hora) | 1 hora | 1 a 4 horas |
| 300 (5 minutos) | 5 a 15 minutos | 15 a 60 minutos |
Reducir el TTL en el gran día no acorta lo que ya está almacenado en caché en otro lugar.
Apex, www y correos electrónicos
www: CNAME al nuevo balanceador de carga: relativamente simple.
Apex @: Registro ALIAS o A del proveedor: no hay RFC CNAME en el ápice simple.
MX: migra el correo electrónico por separado: TTL MX bajo si se cambia; riesgo de pérdida de mensajes si se olvidan.
Documente la diferencia entre el TTL mínimo de SOA y el TTL de registro: confusión común en la migración.
Pruebas antes del corte público
El archivo /etc/hosts o curl --resolve le permite probar el nuevo origen sin tocar el DNS público.
Lista de verificación: certificado válido en el nuevo host, sesiones externalizadas, webhooks con nueva IP autorizada.
Ejecución dual: antiguo y nuevo en paralelo con monitoreo comparando la tasa de error.
Para conocer el contexto general de DNS, consulte DNS para principiantes.
Comunicación a las partes interesadas
Una migración mal anunciada genera tickets de “el sitio no me funciona” mientras el DNS avanza con normalidad. Notifique al equipo de soporte, a los socios de webhooks y a los clientes B2B antes de la transición, con una ventana honesta, no con la promesa de un instante.
Una página de estado interna o externa durante la conmutación por error evita que cada resolución lenta se interprete como una falla total. Breve soporte: “borrar la caché de DNS” en el lado del cliente no resuelve un TTL de 86400 que aún está activo en un ISP de terceros.
Documente la IP antigua y nueva, la fecha/hora de transición y el contacto técnico en el host, lo que resulta útil si un socio necesita incluir el nuevo origen en la lista blanca en un plazo de cuarenta y ocho horas.
La cumbre: la migración “instantánea” vendida, el TTL olvidado
Esto es lo que ninguna herramienta puede prometer.
Prepare una migración = cronograma TTL + hosts de prueba + plan apex/MX, no solo cargue archivos al nuevo VPS.
Decide y avanza sin puntos ciegos
Antes del fin de semana de cambio:
- Reduzca el TTL a 300 s al menos cuarenta y ocho horas antes del gran día.
- Probar la resolución de varios solucionadores públicos y ISP locales.
- Ejecute la transición con monitoreo activo en ambos orígenes.
- Supervise el porcentaje de tráfico en el nuevo origen: apunte al 95% en cuatro horas si TTL está preparado.
- Aumente el TTL una semana después de la estabilización.
- Procese MX y apex en un plano separado de www si el correo electrónico es crítico.
Compare los hosts y sus herramientas DNS a través del directorio y el comparador.
Preguntas frecuentes
¿Cuánto tiempo falta para la migración para reducir el TTL?
Al menos una vez el antiguo TTL máximo antes del día D; 300 segundos es un valor común para las grabaciones migradas.
¿Todavía es suficiente TTL 300?
Para una transición, sí; Todavía planifique de una a veinticuatro horas de tráfico mixto dependiendo del solucionador.
¿Dominio de Apex y migración?
Registro ALIAS o A: no hay CNAME clásico en el vértice. Mapa separado del subdominio www.
¿Cómo comprobar la propagación?
excavar desde múltiples resolutores; un rubor local no demuestra nada al resto del mundo.
Una migración DNS exitosa se prepara en el TTL, no en el discurso del vendedor.