¿Por qué tarda en propagarse un cambio de DNS?

Cambias el registro de tu dominio para que apunte a un servidor nuevo, guardas, y tu web sigue mostrando la versión antigua. Llamas a tu socio y él ya ve la nueva. Una hora después, un cliente te escribe para decirte que la página no carga. El proveedor responde lo de siempre: «el DNS puede tardar hasta 48 horas en propagarse».

Esa frase es cierta a medias y explica poco. El DNS no se propaga como una onda que recorre el mundo. Lo que pasa es que miles de servidores tienen guardada una copia de la respuesta antigua, y cada uno la descarta cuando le toca. Entender cuándo le toca a cada uno es lo que convierte una migración angustiosa en una tarea de veinte minutos.

¿Qué pasa cuando alguien escribe tu dominio?

El navegador no sabe en qué servidor está tudominio.com. Se lo pregunta a un resolutor: el servidor DNS que tiene configurado la conexión, normalmente el del operador de internet, o uno público como el 1.1.1.1 de Cloudflare o el 8.8.8.8 de Google.

Si el resolutor no tiene la respuesta, la busca él mismo: pregunta a los servidores raíz por .com, a los de .com por quién lleva tudominio.com, y a los servidores autoritativos de tu dominio (los que configuras en el registrador, sean de tu hosting o de tu proveedor de DNS) por la dirección concreta. Con la respuesta en la mano, se la entrega al navegador y la guarda para la próxima vez.

Esa copia guardada es la clave de todo. Sin ella, cada visita a cada web del mundo repetiría la cadena entera de preguntas y el DNS sería lentísimo. Con ella, la mayoría de las consultas se responden en milisegundos desde la caché.

El TTL: la fecha de caducidad de cada respuesta

Cada registro DNS lleva un TTL (time to live): el número de segundos que un resolutor puede guardar la respuesta antes de volver a preguntar. Un TTL de 3600 es una hora; uno de 300, cinco minutos; uno de 86400, un día.

Cuando cambias un registro, el cambio es inmediato en tus servidores autoritativos. Lo que tarda es que los resolutores que ya tenían la respuesta vieja la descarten, y eso depende del TTL que tenía el registro antiguo, no del nuevo. Si el registro viejo llevaba un TTL de un día y un resolutor lo consultó hace una hora, ese resolutor seguirá dando la dirección antigua otras veintitrés.

De ahí salen las famosas 48 horas: son el peor caso de una época en la que los TTL de uno o dos días eran lo normal. Hoy muchos proveedores ponen TTL de minutos por defecto, y la mayoría de los cambios se ven en ese tiempo.

¿Por qué tú ves una cosa y otra persona otra distinta?

Porque lo más probable es que cada uno pregunte a un resolutor distinto, o que no lo haga en el mismo momento:

• Cada operador tiene sus propios resolutores, y cada uno guarda su copia. El de tu socio puede llevar horas sin consultar tu dominio y pedir ya la respuesta nueva; el tuyo la guardó hace diez minutos.
• Un resolutor público son en realidad muchos servidores. Cloudflare, Google o Quad9 responden desde centros de datos repartidos por el mundo, y sus cachés no están sincronizadas al segundo.
• Hay más cachés antes del resolutor. El sistema operativo y el navegador también guardan respuestas, y el router de la oficina a veces hace de intermediario.
• Algunos resolutores no respetan el TTL al pie de la letra: aplican un mínimo propio o alargan la copia si el servidor autoritativo no responde.
• Y a veces la diferencia es legítima. Si tu web está detrás de una CDN, cada visitante puede recibir una dirección distinta según desde dónde se conecte, y es a propósito.

Hay además un caso que sorprende: si alguien consultó un nombre antes de que existiera (un subdominio recién creado, por ejemplo), el resolutor también guarda ese «no existe», durante el tiempo que marca el registro SOA del dominio. Por eso crear un registro y probarlo en el mismo segundo a veces deja un error pegado durante un rato.

¿Y si cambio los servidores DNS del dominio?

Cambiar un registro dentro de tu zona (el A de la web, el MX del correo) es el caso fácil. Cambiar los servidores DNS del dominio en el registrador, por ejemplo al pasar la gestión a otro proveedor, es otra historia: esa información la guardan los servidores de la extensión, y en .com la delegación suele llevar un TTL de dos días que tú no puedes tocar.

En la práctica, durante ese periodo unos resolutores preguntarán a tus servidores antiguos y otros a los nuevos. La regla para que nadie lo note es que las dos zonas digan lo mismo: copia todos los registros al proveedor nuevo antes de cambiar la delegación, y no des de baja el antiguo hasta pasados unos días. Y si en el proceso tocas el registrador, aprovecha para revisar la renovación: lo contamos en qué pasa si caduca tu dominio.

¿Cómo preparar un cambio para que tarde minutos?

Esta es la parte útil, y casi nadie la hace porque hay que acordarse con antelación:

1. Mira el TTL actual del registro que vas a cambiar.
2. Bájalo a 300 segundos con, al menos, tanta antelación como ese TTL. Si era de un día, bájalo dos días antes; así, cuando llegue el momento, ningún resolutor tendrá una copia de más de cinco minutos.
3. Haz el cambio. Ahora la espera máxima es de unos cinco minutos para casi todo el mundo.
4. Comprueba en varios resolutores que ya ven el valor nuevo.
5. Mantén el servidor antiguo encendido un tiempo, por los resolutores rezagados.
6. Vuelve a subir el TTL cuando todo esté estable, a una hora o más. Un TTL bajo de forma permanente multiplica las consultas y te deja más expuesto si tu proveedor de DNS tiene un problema.

Es el mismo orden que conviene seguir al migrar una web sin perder posicionamiento: el cambio de DNS es el último paso, y solo se da cuando el servidor nuevo ya está probado.

Mientras esperas, vaciar la caché de tu equipo ayuda a ver el cambio antes (en Windows, ipconfig /flushdns), y una ventana privada esquiva parte de la caché del navegador. Pero nada de eso acelera lo que pasa fuera de tu ordenador.

¿Cómo comprobarlo?

La utilidad de propagación de DNS consulta el mismo nombre en Cloudflare, Google y Quad9 a la vez y compara sus respuestas para los registros A, AAAA, CNAME, MX, TXT, NS y CAA. Junto a cada respuesta muestra el TTL que devuelve ese resolutor, que en una respuesta guardada es el tiempo que le queda hasta volver a preguntar. Puedes dejar que repita la consulta cada treinta segundos mientras esperas.

Si los tres coinciden, el cambio está publicado, aunque el resolutor de tu operador puede tardar algo más por las razones de antes. Y si lo que estás cambiando son registros de correo, el comprobador de SPF, DKIM y DMARC te dice si los nuevos están bien escritos.

---

La propagación no se puede forzar, pero sí planificar. Bajar el TTL un par de días antes es el gesto que más diferencia marca entre una migración tranquila y una tarde respondiendo llamadas.