Vas a cambiar de hosting o a apuntar tu dominio a un servidor nuevo, y en todas partes lees la misma frase: «los cambios de DNS pueden demorar entre 24 y 48 horas en propagarse».
Esa frase es un redondeo de seguridad. No hay ninguna regla técnica que diga 48 horas. El tiempo real de un cambio de DNS lo decide un número que tú controlas, y que se puede leer en un comando.
La propagación no existe
La palabra «propagación» sugiere que el cambio se expande por internet como una onda, de a poco, país por país. No es lo que pasa.
Lo que pasa es que los servidores DNS del mundo guardan en memoria las respuestas que ya consultaron, para no preguntar lo mismo mil veces. Cuando tú cambias un registro, el cambio queda hecho de inmediato en tu servidor autoritativo. Lo que demora es que expiren las copias guardadas en los resolutores que ya habían preguntado antes.
No es una onda que avanza. Son cachés que vencen. Y saben exactamente cuándo vencer, porque tú se lo dijiste.
El TTL: el número que manda
Cada registro DNS lleva un valor llamado TTL (time to live). Está definido en el RFC 1035 como un entero de 32 bits que indica segundos.
Cuando un resolutor guarda tu registro, empieza a descontar ese número. Al llegar a cero bota la copia y vuelve a preguntar. Eso es todo el mecanismo.
Así que la respuesta correcta a «cuánto demora mi cambio de DNS» es: lo que dure el TTL que tenía el registro antes de que lo cambiaras.
| TTL configurado | Espera máxima real | Cuándo se usa |
|---|---|---|
| 300 (5 minutos) | 5 minutos | Durante una migración |
| 1800 (30 minutos) | 30 minutos | Días previos a un cambio |
| 3600 (1 hora) | 1 hora | Valor por defecto de muchos paneles |
| 14400 (4 horas) | 4 horas | Valor por defecto de cPanel |
| 86400 (24 horas) | 24 horas | Registros que no cambian nunca |
Si tu registro tenía TTL de 3600, tu cambio está completo en el mundo en una hora. Nadie espera 48 horas por un TTL de una hora.
El error clásico: bajar el TTL después del cambio
Esto hay que decirlo fuerte, porque es el error más caro de todos.
Bajar el TTL después de hacer el cambio no sirve absolutamente de nada. Los resolutores que ya guardaron tu registro guardaron también el TTL viejo, y van a respetarlo hasta que se les venza. Tu TTL nuevo recién lo van a ver cuando vuelvan a preguntar, o sea, después de la espera que querías evitar.
El TTL se baja antes. La secuencia correcta es: bajas el TTL a 300, esperas a que se venza el TTL antiguo (si era 14400, esperas cuatro horas), y recién ahí haces el cambio real. El cambio queda listo en cinco minutos.
El caché negativo: lo que casi nadie explica
Acá está la parte contraintuitiva, y es la que explica los casos raros.
Los resolutores no solo guardan las respuestas positivas. También guardan las negativas. Si alguien consulta un nombre que no existe, el resolutor guarda ese «no existe» —la respuesta NXDOMAIN— durante un rato. El RFC 2308 define cuánto: el menor entre el campo MINIMUM del registro SOA de la zona y el propio TTL del SOA.
La consecuencia práctica es rara pero muy real:
- Un nombre que nunca nadie consultó responde de inmediato apenas lo creas. No hay nada guardado que tenga que vencer.
- Un nombre que consultaste ayer cuando todavía no existía te va a hacer esperar, aunque ya lo hayas creado. Tu resolutor tiene guardado que no existe.
Por eso pasa la escena típica: tú ves el sitio caído y el técnico lo ve andando. No es que uno de los dos tenga mal el computador. Es que tú consultaste antes de tiempo y te quedaste con el «no existe» guardado.
La moraleja es incómoda pero útil: no consultes el dominio antes de haber terminado la configuración. Cada consulta prematura te alarga tu propia espera.
Los resolutores no siempre respetan tu TTL
Dos matices que conviene tener claros antes de prometerle a alguien «cinco minutos»:
Hay un piso. Google Public DNS aplica un mínimo de 30 segundos. Si tu registro declara TTL de 0 o de 10 segundos, Google lo trata como 30. Poner un TTL absurdamente bajo no acelera nada.
Hay un techo informal. Algunos resolutores de proveedores de internet suben por su cuenta los TTL muy cortos para reducir consultas. Es poco frecuente, no está documentado y contradice el estándar, pero existe. Por eso conviene dejar un margen sobre el TTL teórico en lugar de prometer el minuto exacto.
Un caso medido
El 21 de agosto de 2026 delegamos un dominio .cl a un servidor nuevo. El titular publicó los servidores de nombres a las 10:20 de la mañana.
El dominio respondía y el sitio cargaba esa misma mañana, no al día siguiente. Ayudó una condición concreta: ese dominio no tenía servidores de nombres delegados antes, así que no había ninguna respuesta antigua guardada en ninguna parte esperando a vencer.
Ese es exactamente el escenario del caché negativo al revés: cuando no hay nada previo que expirar, el cambio se ve al tiro.
Qué se cae y qué no durante el cambio
Durante la ventana en que unos resolutores tienen la respuesta vieja y otros la nueva, conviven dos versiones de tu servicio. Esto es lo que importa:
- La web: unos visitantes ven el sitio antiguo y otros el nuevo. Si el sitio es informativo, no pasa nada. Si vende o recibe formularios, hay que dejar los dos servidores funcionando durante la ventana.
- El correo: es la parte delicada. Los mensajes pueden entregarse en el servidor antiguo durante horas. Deja las casillas antiguas activas y revisándose hasta que estés seguro. Un correo entregado en el buzón viejo no se pierde, pero tampoco te llega.
- El certificado: emítelo en el servidor nuevo antes de cambiar los DNS si puedes, o inmediatamente después. Si no, algunos visitantes verán la advertencia del navegador.
El orden completo, con el correo incluido, lo detallamos en cómo apuntar tu dominio a tu hosting sin quedarte sin correo.
Cómo comprobarlo de verdad
Los sitios de «comprobar propagación» que muestran un mapa con banderitas sirven para una vista rápida, pero confunden: consultan resolutores públicos repartidos por el mundo, y lo que tú necesitas saber es qué ve tu resolutor y qué dice el servidor autoritativo.
Tres comandos que sí responden la pregunta:
dig tudominio.cl +noall +answer— qué te responde tu resolutor, con el TTL que le queda.dig @8.8.8.8 tudominio.cl— qué responde un resolutor público concreto.dig tudominio.cl +trace— el recorrido completo desde la raíz, que te muestra qué dice el servidor autoritativo sin ningún caché en el medio.
Ese TTL que aparece en la respuesta es el contador en vivo: son los segundos que le quedan a la copia guardada. Cuando llegue a cero, tu resolutor vuelve a preguntar.
En Windows, nslookup tudominio.cl 8.8.8.8 hace la versión corta. Y si quieres ver el estado real sin caché local, ipconfig /flushdns limpia el tuyo.
La receta para cambiar de hosting sin caída
- Baja el TTL a 300 en los registros que vas a cambiar.
- Espera el TTL antiguo completo antes de seguir. Si era 14400, son cuatro horas.
- Monta el sitio completo en el servidor nuevo y pruébalo por dirección IP o con un nombre temporal.
- Emite el certificado en el servidor nuevo.
- Haz el cambio. Con TTL de 300 estás listo en minutos.
- Deja el servidor antiguo prendido al menos 72 horas, sobre todo por el correo.
- Sube el TTL de vuelta a 3600 o 14400 cuando termines.
Si te da lo mismo el detalle y solo quieres que tu sitio cambie de casa sin sustos, la guía de migración tiene el resto del procedimiento, incluida la parte de archivos y base de datos.
En resumen
La propagación DNS no demora 48 horas. Demora lo que dure el TTL del registro que cambiaste, y ese número lo decides tú con un día de anticipación. Las esperas eternas casi siempre son una de tres cosas: un TTL alto que nadie bajó a tiempo, un caché negativo que se generó por consultar antes de tiempo, o un registro que quedó mal escrito y nunca fue un tema de espera.
En AltaHosting hacemos la migración por ti y coordinamos el cambio de DNS con la ventana calculada, en el horario que menos te afecte. Escríbenos y lo revisamos antes de que toques un solo registro.
