El retraso de propagación de DNS es la brecha entre cambiar un registro y que cada visitante vea realmente el nuevo valor, y esa brecha puede ir desde cinco minutos hasta dos días completos. Si acabas de migrar de host, cambiar de proveedor de correo o apuntar tu dominio a nuevos servidores de nombres, quieres una respuesta directa sobre qué acelera esto y qué simplemente no puedes tocar. Un ajuste decide la mayor parte de la espera: el TTL. Todo lo demás, el comportamiento del resolvedor, la caché del ISP, el tiempo de registro, queda fuera de tu control sin importar con qué frecuencia actualices la página.
Qué causa los retrasos en la propagación de DNS
La propagación de DNS no es un evento que ocurre en todas partes a la vez. Debido a que los datos de DNS se almacenan en caché en múltiples capas para mayor velocidad, cada cambio tiene que abrirse paso a través de miles de resolvedores recursivos, servidores de ISP y dispositivos de usuario final antes de llegar a todos. Cada resolvedor, desde tu router doméstico hasta tu ISP, almacena una respuesta de DNS durante un período determinado y sigue sirviendo esa respuesta almacenada en lugar de volver a preguntar al servidor autoritativo. Ese período almacenado tiene un nombre.
El TTL, tiempo de vida, es un número en segundos adjunto a cada registro DNS que dice a los resolvedores recursivos cuánto tiempo pueden reutilizar la respuesta en caché antes de volver a comprobar con el servidor de nombres autoritativo. Un registro establecido con un TTL de 3600 puede ser retenido por un resolvedor durante una hora; uno establecido en 86400 puede ser retenido durante un día entero. Ese número único es la razón por la que el mismo cambio puede parecer instantáneo para un visitante e invisible para otro durante horas.
Hay una arruga incluso aquí. Algunos resolvedores simplemente ignoran un TTL bajo, y ciertos resolvedores de ISP aplican su propio piso de caché mínimo, comúnmente 300 segundos, independientemente de lo que publiques. Cuando un dispositivo consulta tu dominio, pide a un servidor DNS de caché la respuesta, ese servidor almacena la respuesta durante el tiempo que dice el TTL, y durante esa ventana no volverá a comprobar las actualizaciones. No puedes forzar a ese servidor a comprobar antes.
Reducir el TTL antes de una migración: la única palanca que usted controla
El TTL se establece con antelación, lo que significa que es la única parte de este proceso que realmente puedes planificar. Una reducción escalonada funciona mejor que una caída única el día de la migración. Un calendario ampliamente utilizado se ve así:
Siete días antes de la migración, audita el TTL de cada registro crítico (A, MX, CNAME y similares) y limita cualquier valor superior a 24 horas. Tres días antes, reduce esa cifra a 3600 segundos, una hora. Entre 24 y 48 horas antes del cambio, redúcelo de nuevo a 300 segundos, cinco minutos, lo que permite la propagación más rápida y realista durante el cambio real.
La espera importa tanto como el número. El TTL antiguo y más largo tiene que expirar primero de las cachés antes de que el nuevo y más corto surta efecto en cualquier lugar, por lo que el aviso previo no es opcional. Soltar el TTL una hora antes del cambio es demasiado tarde para ayudar. Haz el cambio real solo una vez que ese TTL bajo haya tenido tiempo de extenderse.
El correo merece su propia partida, ya que un registro MX roto significa mensajes rebotados, no una carga de página lenta. Reduzca el TTL en los registros MX 48 horas completas antes de la migración para dar suficiente tiempo a la propagación. Confirme que el nuevo servidor de correo realmente está funcionando antes de tocar cualquier registro DNS que apunte a él. Cambie los registros MX durante una ventana de tráfico genuinamente tranquila, generalmente durante la noche o un fin de semana.
Una vez que el nuevo servidor sea estable, deshace la configuración temporal. Eleva el TTL de nuevo a 3600 segundos o más una vez que se confirme que todo funciona, ya que un TTL más largo funciona mejor día a día y el valor corto solo es útil alrededor del cambio en sí. Dejarlo corto permanentemente añade carga y dependencia en tus servidores DNS autorizados sin ningún beneficio continuo.
Lo que la gente entiende mal sobre la propagación de DNS
La palabra en sí causa la mayor parte de la confusión. Nada se está "empujando" realmente a través de internet; las cachés de los resolvedores simplemente expiran según el TTL que el administrador de la zona estableció, y ningún mecanismo difunde tu cambio en ninguna parte. La única forma fiable de confirmar que un cambio está en vivo es comprobarlo contra una herramienta multiresolvedor, resolvedor por resolvedor, en lugar de confiar en tu propio navegador.
La cifra de "24 a 48 horas" se trata como una ley de la física, y no lo es para las ediciones de registro ordinarias. Ese número se remonta a los primeros días del DNS comercial, cuando los registradores aplicaban rutinariamente TTLs de 24 horas y algunos resolvedores de ISP añadían su propio retraso encima. Con un TTL moderno de 300 segundos establecido con mucha antelación, la mayoría de los cambios de registro se aclaran en minutos, no en días.
Los cambios de servidores de nombres son la verdadera excepción, y el TTL no ayuda aquí de la forma en que lo hace para los registros ordinarios. Cambiar los servidores de nombres añade una capa extra de propagación en el propio registro, y los cambios de registro de servidores de nombres pueden tardar hasta 48 horas porque los registros actualizan sus archivos de zona según su propio calendario, no el tuyo. Ese retraso existe porque los registros de los servidores de nombres provienen de los servidores de nombres raíz, que comúnmente entregan un TTL de dos días completos, 172,800 segundos, lo que hace que los resolvedores de todas partes mantengan la antigua delegación durante tanto tiempo.
Los ISP añaden otra variable que no puede auditar desde su propio escritorio. Algunos proveedores ignoran por completo la configuración TTL publicada y solo actualizan sus propios registros en caché cada dos o tres días. Si un cambio parece completo en cada verificador público pero un visitante sigue accediendo al servidor antiguo, el resolutor de su ISP suele ser la razón, no su configuración.
Lo que esto significa en la práctica
Antes de tocar nada, enumera cada registro vinculado al servicio que vas a mover: A, AAAA, CNAME, MX y cualquier registro TXT para SPF o DMARC. Anota el TTL actual en cada uno, porque esa cifra es tu cronograma real, no una suposición. Cuarenta y ocho horas antes de la migración, reduce el TTL en los registros A, AAAA y CNAME que pretendes cambiar a 300 segundos. Deja solos los registros que no vas a tocar.
Cambia la dirección IP y los servidores de nombres (nameservers) como eventos separados en lugar de al mismo tiempo, ya que combinarlos hace que sea mucho más difícil saber qué capa sigue obsoleta. Mantén el servidor o buzón antiguo funcionando durante toda la ventana de TTL anterior para que cualquiera que aún esté en una respuesta almacenada en caché no llegue a un callejón sin salida. Este simple hábito elimina la mayor parte de lo que la gente llama una interrupción por migración.
Verifica el estado con una herramienta creada para ello, no con tu propio navegador. La red de resolución pública de Google, 8.8.8.8, es una de las más grandes del mundo y generalmente cumple con el TTL, lo que la convierte en un punto de referencia confiable. Si tu propia conexión sigue mostrando la respuesta antigua después de que haya pasado la ventana de TTL, reiniciar el router o cambiar a un resolvedor público como Google Public DNS a menudo detectará el estado de caché actualizado más rápido que esperar a tu ISP.
Una vez que se confirma que el corte es estable en todos los resolvedores, eleva el TTL de nuevo a un valor de producción y sigue adelante. Todo el proceso recompensa la paciencia en la etapa de configuración, no la urgencia en el día en sí. Una migración planificada 48 horas antes con un TTL de 300 segundos en su lugar casi siempre supera a una realizada a toda prisa en el último minuto.
