El síntoma confuso
Haces un cambio en DNS. Actualizas un registro A, cambias nameservers o añades un MX. Luego revisas el sitio — y según el dispositivo, la red o el navegador, recibes respuestas distintas. Tu móvil ve el sitio antiguo. Tu portátil ve el nuevo. Tu amigo al otro lado de la ciudad ve el antiguo. Horas después, el cuadro sigue mixto.
No es un bug del proveedor DNS. Es DNS haciendo exactamente lo que se diseñó para hacer — y la única manera de dejar de frustrarte con ello es entender qué pasa de verdad.
Qué significa realmente "propagación"
"Propagación de DNS" es técnicamente un nombre engañoso. El sistema DNS no empuja activamente cambios a ningún sitio. En cambio, cada ordenador que pide un registro DNS recibe una respuesta más un TTL (Time To Live) — segundos que esa respuesta puede cachearse. Durante el TTL, los resolvers recursivos (los servidores que tus dispositivos consultan) siguen devolviendo la cacheada en lugar de re-consultar.
Así que cuando haces un cambio DNS, la nueva respuesta está disponible inmediatamente en el nameserver autoritativo. Pero todo resolver recursivo del mundo aún tiene la antigua hasta que su caché expire. La "propagación" es solo el ciclo de vida de todas esas entradas cacheadas expirando y refrescándose.
El TTL es la palanca
Cada registro DNS tiene un valor TTL, fijado por el dueño del dominio. Valores comunes:
- 300 segundos (5 minutos): agresivo, bueno para pruebas y cambios frecuentes.
- 3600 segundos (1 hora): default común para la mayoría de registros.
- 86400 segundos (24 horas): máximo recomendado para registros estables.
- Hasta 7 días: máximo teórico; rara vez útil.
TTLs bajos significan propagación más rápida pero más consultas DNS (coste algo mayor en lo autoritativo, experiencia algo más lenta para usuarios en cache miss). TTLs altos significan menos consultas pero propagación más lenta.
Estrategia: antes de un cambio, baja el TTL a 300 segundos y espera la duración del TTL anterior. Luego haz el cambio. Tras estabilizarse, sube el TTL otra vez a 3600 o más.
Las capas de caché
La caché no es una sola cosa. Hay varias capas entre el nameserver autoritativo y tu dispositivo:
- Caché del navegador: Chrome, Firefox, Safari cachean respuestas DNS 30–120 segundos.
- Caché del SO: Windows, macOS, Linux cachean lookups DNS localmente.
- Caché del router: muchos routers domésticos/oficina cachean DNS para su LAN.
- Caché del ISP/resolver recursivo: Comcast, Verizon, el resolver de tu ISP — y resolvers públicos como 1.1.1.1 y 8.8.8.8 — cachean durante el TTL.
- Nameserver autoritativo: la fuente de verdad.
Un cambio en el autoritativo se vuelve visible para tu dispositivo solo cuando TODAS las capas superiores se han refrescado. Por eso ves respuestas distintas en distintos dispositivos de la misma red — cachés distintas, expiraciones distintas.
Por qué los cambios de nameserver son los más lentos
Cambiar un registro A individual es una cosa. Cambiar tus nameservers (registros NS en el registro) es asunto mayor. Los registros NS los gestiona el registro TLD (Verisign para .com), y su TTL es típicamente 24–48 horas y no configurable por el usuario.
Por eso mover proveedores DNS — pasar del DNS de tu registrador a Cloudflare, por ejemplo — puede tardar uno o dos días enteros para que los últimos rezagados se pongan al día. Planifica en consecuencia.
Cómo verificar el estado de propagación
Herramientas que puedes usar:
- dig +trace example.com en una terminal Linux/macOS — muestra el camino completo de raíz a autoritativo.
- nslookup example.com 1.1.1.1 — consulta a un resolver público específico para ver qué devuelve ahora.
- whatsmydns.net o dnschecker.org — comprueban la respuesta desde decenas de resolvers globales. Si la mayoría muestra la nueva, la propagación está casi completa.
Importante: el servidor autoritativo es la única fuente de verdad. Si el panel de tu DNS autoritativo muestra el nuevo registro, has hecho tu parte. El resto es esperar.
Cómo acelerarla (donde se pueda)
- Baja TTLs por adelantado. La mayor palanca. Baja a 300s un día antes de cualquier cambio planificado.
- Vacía cachés locales:
- Windows: ipconfig /flushdns
- macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux (systemd): sudo systemd-resolve --flush-caches
- Chrome: chrome://net-internals/#dns → Clear host cache
- Prueba desde otra red. Datos móviles en lugar de Wi-Fi suele golpear otro resolver y mostrarte el estado actual.
- Usa un resolver público directo. Configura tu dispositivo para usar 1.1.1.1 o 8.8.8.8 en vez del de tu ISP — ambos tienen políticas de caché más cortas y suelen actualizar antes.
Qué evitar durante la propagación
- No edites por pánico. Si el cambio no aparece en 5 minutos, es normal. Re-editar el registro mientras propaga solo añade confusión.
- No asumas "roto" significa roto. Distintos dispositivos mostrando distintas respuestas es el estado esperado durante propagación, no un fallo.
- No elimines la infraestructura antigua demasiado pronto. Si cambias de host y desmantelas el viejo antes de completar la propagación, verás caídas reales para usuarios aún golpeando la IP vieja.
El cronograma honesto
Para la mayoría de cambios DNS:
- 5–15 minutos: propagación visible en tu entorno inmediato.
- 1–4 horas: mayoría de resolvers globales actualizados.
- 24 horas: casi todas las cachés refrescadas.
- 48 horas: rezagados y casos límite ya alineados.
Para cambios de nameserver específicamente, duplica esos números.
El modelo mental que conservar
La propagación DNS no es un interruptor. Son millones de cachés expirando independientemente en momentos ligeramente distintos. Tu trabajo es hacer el cambio una vez, bajar TTLs por adelantado para acortar las ventanas de caché, y esperar. Re-comprobar obsesivamente no acelera nada; solo te hace más consciente de las discrepancias.