Cuánto tarda la propagación de DNS (y cómo acelerarla)
Cambiaste un registro DNS (moviste el sitio a un servidor nuevo, cambiaste de proveedor de correo, apuntaste el dominio a Cloudflare) y ahora algunas personas ven el sitio nuevo y otras el anterior. Las empresas de hosting suelen decir "espera de 24 a 48 horas para la propagación del DNS". La respuesta real depende de lo que cambiaste y de un número que puedes controlar: el TTL. Con algo de preparación, un cambio de registro típico tarda minutos, no días.
Qué es realmente la "propagación"
En realidad, nada se envía por internet. Cuando guardas un registro, los servidores de nombres autoritativos de tu proveedor de DNS empiezan a devolver el valor nuevo casi de inmediato. El retraso viene de las cachés. Cada resolver que consultó tu dominio antes (el DNS de tu ISP, Google Public DNS, Cloudflare 1.1.1.1, el router de tu oficina, tu sistema operativo, tu navegador) conserva la respuesta anterior hasta que expira su copia en caché, y solo entonces vuelve a preguntar. "Esperar la propagación" en realidad significa esperar a que esas cachés se agoten.
TTL: el número que define la espera
Cada registro DNS tiene un TTL (time to live, tiempo de vida) en segundos. Indica a los resolvers durante cuánto tiempo pueden conservar la respuesta. Un registro con TTL 3600 puede servirse desde la caché hasta una hora después de haberse consultado; con TTL 86400, hasta un día.
| TTL | Cuánto puede durar una respuesta antigua | Dónde suele verse |
|---|---|---|
| 60–300 | 1–5 minutos | Registros preparados para una migración, balanceo de carga, registros con proxy de Cloudflare |
| 3600 | Hasta una hora | Un valor predeterminado habitual en registradores y hosts |
| 14400–86400 | 4–24 horas | MX, TXT y zonas antiguas que nadie ha tocado |
| 172800 | Hasta 2 días | Delegación NS de .com, .net y muchas otras zonas |
El detalle: los resolvers conservan el TTL antiguo, no el nuevo. Si el registro tenía un TTL de 86400 y lo bajaste a 300 en el mismo momento en que cambiaste la IP, un resolver que lo consultó ayer sigue guardando el valor anterior, con su antigua vida útil de 24 horas, hasta que esta termine. Solo conocerá el nuevo TTL en su siguiente consulta.
Por qué "24–48 horas" es solo una regla general
La cifra proviene del peor caso. La delegación de servidores de nombres de TLD populares como .com se publica con un TTL de dos días, y algunos registros con TTL largo permanecen en caché durante un día. Si a esto le sumas resolvers que imponen su propio tiempo mínimo de caché o que sirven respuestas expiradas cuando no pueden contactar con tus servidores, "hasta 48 horas" se volvió lo más seguro que pueden decir los equipos de soporte. Para un cambio normal de registro A con un TTL de 300–3600 segundos, la mayor parte de internet suele ver el valor nuevo en unos minutos o hasta una hora. Nadie puede prometer un tiempo exacto para cada red, porque algunos resolvers no respetan los TTL de forma estricta.
Cambios de registros vs. cambios de servidores de nombres
Son dos operaciones distintas y se propagan de forma diferente.
- Cambiar un registro (A, AAAA, CNAME, MX, TXT) dentro de la zona que ya usas: la espera equivale al TTL anterior de ese registro. Lo controlas por completo.
- Cambiar los servidores de nombres (mover el DNS a otro proveedor, añadir un dominio a Cloudflare): editas los registros NS en el registrador, el registrador los pasa al registro del TLD, y los resolvers que ya conocen la delegación anterior la conservan hasta que expira el TTL de los registros NS en la zona padre, hasta dos días para .com. No controlas ese TTL.
La forma segura de cambiar los servidores de nombres es dejar la zona idéntica en ambos proveedores antes de cambiar: copia todos los registros A, AAAA, CNAME, MX y TXT (incluidas las cadenas de SPF, DKIM y verificación del sitio), cambia los NS en el registrador y conserva la zona anterior al menos dos días. Así no importa a qué proveedor consulte un resolver: la respuesta será correcta. Si DNSSEC está activado, planifica el cambio del registro DS con las instrucciones de ambos proveedores a la mano: un registro DS que no coincide con las claves del nuevo proveedor hace que el dominio falle para los resolvers que validan.
Caché negativa: cuando el "no encontrado" también se guarda
Si alguien consultó new.example.com antes de que lo crearas, los resolvers guardaron en caché la respuesta "no existe" (NXDOMAIN). El tiempo que la conservan lo define el registro SOA de la zona: el menor entre el TTL del propio registro SOA y su campo mínimo. Por eso, primero crea los registros y después pruébalos: consultar un nombre "para ver si ya funciona" antes de que exista puede hacer que esperes más.
Cómo acelerarlo: baja el TTL con anticipación
- Un día o más antes del cambio, reduce el TTL de los registros que planeas cambiar (por ejemplo, los registros A y AAAA) a 300 segundos.
- Espera a que expire el TTL anterior. Comprueba que los resolvers públicos ya no informen de un TTL superior a 300 para esos registros.
- Haz el cambio. La mayoría de los resolvers tomarán el nuevo valor en unos cinco minutos.
- Mantén el servidor anterior en funcionamiento durante al menos un día. Algunos ISP y redes corporativas ignoran los TTL cortos y seguirán enviando visitantes allí durante un tiempo. En el caso del correo, el servidor anterior debe seguir aceptando mensajes al menos durante el TTL anterior del MX: comprueba los nuevos registros con la consulta MX.
- Vuelve a subir el TTL a 3600 o más cuando todo esté estable, para reducir la carga de consultas y ganar resiliencia.
Cachés locales: límpialas antes de alarmarte
A menudo internet ya está actualizado y solo tu propio equipo se ha quedado atrás. Limpia las cachés que hay entre tú y el resolver:
| Dónde | Comando o acción |
|---|---|
| Windows | ipconfig /flushdns en el Símbolo del sistema ejecutado como administrador |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux con systemd-resolved | resolvectl flush-caches |
| Chrome, Edge | chrome://net-internals/#dns → "Clear host cache"; luego #sockets → "Flush socket pools" |
| Firefox | about:networking#dns → "Clear DNS Cache" |
| Router | Reinícialo; muchos routers domésticos tienen su propia caché DNS |
Revisa también el archivo hosts (C:\Windows\System32\drivers\etc\hosts o /etc/hosts): una línea olvidada ahí anula cualquier DNS. Y si el navegador usa su propio proveedor de "DNS seguro", el navegador y la línea de comandos pueden no coincidir. Google Public DNS y Cloudflare 1.1.1.1 tienen páginas web para solicitar la actualización de la caché de un nombre concreto; la caché de tu ISP no se puede limpiar de esa forma, pero puedes cambiar tu dispositivo a un resolver público durante un tiempo.
Cómo comprobar la propagación del DNS
Usa el verificador de propagación DNS. Consulta un conjunto de resolvers públicos DNS-over-HTTPS y los nameservers autoritativos de tu zona, uno junto a otro. Interprétalo así:
- Los nameservers autoritativos muestran el valor nuevo y algunos resolvers públicos el anterior: todo está bien configurado; esos resolvers están esperando a que expire su TTL. El TTL restante de cada fila te indica aproximadamente cuánto falta.
- Los nameservers autoritativos siguen mostrando el valor anterior: el cambio no se guardó, se hizo en la zona equivocada o estás editando el DNS en un proveedor que el dominio no usa. Revisa los registros NS y los datos del registrador en una consulta WHOIS.
- Los nameservers autoritativos no coinciden entre sí: la zona está desincronizada entre ellos, un problema del lado del proveedor.
Desde la línea de comandos, dig example.com @8.8.8.8 consulta a un resolver público, y dig example.com @ns1.your-dns-provider.com consulta directamente a tu servidor autoritativo. Para ver todos los registros del dominio de una vez, usa la consulta DNS, y para confirmar a qué IP resuelve el sitio, la consulta de dominio a IP. Los tipos de registro se explican en cómo revisar los registros DNS de un dominio, y las formas prácticas de encontrar la dirección de un sitio están en cómo encontrar la dirección IP de un sitio web.
