Actualizaste un registro A. Su nuevo servidor está funcionando. Navegas hasta tu dominio y aún ves el sitio anterior. O alguien en otro país ve el nuevo sitio pero usted no. O ambas cosas suceden simultáneamente para diferentes usuarios.

Esta es la propagación de DNS. No es un error y no es que su registrador sea lento. Esto es exactamente lo que está sucediendo y cómo gestionarlo.

¿Qué es la propagación DNS?

DNS (Sistema de nombres de dominio) es una base de datos distribuida globalmente que asigna nombres de dominio a direcciones IP. No es un único servidor, es una jerarquía de miles de solucionadores, cada uno de los cuales almacena en caché las respuestas durante un período de tiempo.

Cuando actualizas un registro DNS, estás cambiando los datos en tu servidor de nombres autorizado : el que controla su registrador o proveedor de DNS. Pero el resto de Internet no consulta directamente a su servidor autorizado. Le preguntan a su solucionador recursivo local (generalmente administrado por su ISP o un servicio DNS público como 1.1.1.1 o 8.8.8.8), que tiene su propia copia en caché de su registro.

La propagación es el proceso por el cual esa copia almacenada en caché expira y es reemplazada por su nuevo registro.

La cadena completa de resolución de DNS

Comprensión por qué la propagación lleva tiempo y requiere comprender cómo funciona realmente una consulta DNS:

Diagrama de cadena de resolución de DNS que muestra cómo viaja una consulta desde el dispositivo a través del solucionador de ISP, el servidor raíz, el servidor TLD y el servidor de nombres autorizado.
La cadena de búsqueda de DNS completa. Los pasos 2 a 4 generalmente se omiten porque el solucionador recursivo ya tiene una respuesta en caché, que es exactamente la razón por la que la propagación lleva tiempo.

Paso 1: su navegador verifica su caché local. Los navegadores modernos almacenan en caché los resultados de DNS independientemente del sistema operativo. Chrome almacena en caché durante 60 segundos; Firefox hasta el valor TTL. chrome://net-internals/#dns muestra el caché actual de Chrome.

Paso 2: el solucionador de código auxiliar de su sistema operativo verifica su caché. Windows, macOS y Linux mantienen un caché DNS local (limpiado con ipconfig /flushdns, dscacheutil -flushcache, o resolvectl flush-caches respectivamente).

Paso 3: se consulta su solucionador recursivo. Este suele ser el solucionador de su ISP, 1.1.1.1, 8.8.8.8o un servidor DNS corporativo. Tiene su propio caché, separado del suyo, compartido entre todos sus usuarios. Si 10.000 personas utilizan el mismo solucionador de ISP, una respuesta almacenada en caché les sirve a todos.

Paso 4: el solucionador recursivo recorre la jerarquía (si su caché está vacío). Solicita a un servidor de nombres raíz el TLD, al servidor de TLD el servidor de nombres autorizado y luego al servidor autorizado su registro. Almacena en caché la respuesta con el TTL que especificaste.

Propagation is slow because: el paso 4 solo se ejecuta cuando la caché del solucionador ha caducado. Hasta entonces, ofrece la antigua respuesta almacenada en caché, independientemente de lo que haya cambiado en el servidor autorizado.

TTL: El número que lo controla todo

TTL (Tiempo de vida) es un valor que estableces en cada registro DNS, medido en segundos. Les dice a los resolutores cuánto tiempo deben almacenar en caché su registro antes de volver a consultar el servidor autorizado.

Valores TTL comunes:

TTL Segundos Uso típico
1 minuto 60 Migraciones activas, pruebas
5 minutos 300 Pre-migración (establecida 24h antes)
15 minutos 900 Registros modificados con frecuencia
1 hora 3600 Estándar para la mayoría de los registros
4 horas 14400 Registros estables
24 horas 86400 Predeterminado para muchos proveedores
48 horas 172800 Registros del servidor de nombres (NS)

El TTL que establezca determina el máximo ventana de propagación. Pero hay un problema.

Gráfico que muestra el tiempo de propagación de DNS frente al valor TTL con los mejores, típicos y peores escenarios
El mejor de los casos refleja resolutores que respetan exactamente TTL. En el peor de los casos: algunos solucionadores de ISP almacenan en caché mucho más allá del TTL declarado, especialmente para TTL cortos, tratando cualquier valor inferior a 5 minutos como "5 minutos" para reducir la carga.

El sucio secreto sobre TTL: muchos ISP ignoran los valores TTL bajos. Un solucionador que atiende a millones de usuarios no puede darse el lujo de volver a consultar cada 60 segundos dominios de alto tráfico. Algunos imponen un tiempo mínimo de caché de 5 minutos independientemente de lo que declares. Esto significa que los TTL muy bajos (60 a 300 segundos) se comportan más como TTL de 5 minutos en la práctica para una parte de los resolutores.

Un TTL de 24 horas significa que algunos usuarios pueden ver su registro anterior durante 24 horas completas después de realizar un cambio, incluso si lo cambió inmediatamente después de la expiración de un TTL anterior.

¿Cuánto tiempo lleva realmente la propagación de DNS?

Gráfico de línea de tiempo estilo Gantt que muestra la propagación de DNS a diferentes regiones del mundo después de un cambio de registro DNS
Cronograma de propagación regional para un registro con TTL de 1 hora. Los solucionadores locales se actualizan más rápido; Los ISP atípicos que ignoran TTL pueden retrasarse durante horas. Esto explica por qué algunos usuarios ven su nuevo sitio mientras que otros ven el antiguo.

Con un TTL estándar de 1 hora, esto es lo que puede esperar:

  • Tu dispositivo local: casi instantáneo después de vaciar el caché
  • Resolutores de la misma ciudad: 5 a 30 minutos (las consultas de resolución son autorizadas cuando caduca su caché)
  • DNS público principal (8.8.8.8, 1.1.1.1): normalmente entre 10 y 60 minutos
  • Propagación mundial: 1 a 4 horas para la mayoría de los usuarios
  • ISP lentos/atípicos: hasta 8–12 horas

La cifra de "hasta 48 horas" que ve en todas partes es técnicamente posible, pero cada vez es más rara para registros A y CNAME con TTL normales. Es más preciso para los cambios de registros NS (servidor de nombres), que tienen TTL inherentes más largos y se propagan a través de la capa raíz/TLD.

¿Por qué 48 horas específicamente? Los registros NS suelen tener TTL establecidos por el registro (no por usted), normalmente entre 24 y 48 horas. Cuando cambia sus servidores de nombres en su registrador, está esperando que se actualice el registro de TLD, y esa actualización se propaga a través de los servidores raíz en todo el mundo. Esta ruta lleva más tiempo que un simple cambio de registro dentro de un servidor de nombres fijo.

El enfoque profesional: reduzca previamente su TTL

El mayor error que comete la gente con las migraciones de DNS: cambiar registros sin bajar primero el TTL.

El proceso correcto para las migraciones planificadas:

  1. 48 horas antes de la migración: Reduzca el TTL a 300 segundos (5 minutos) en todos los registros que planee cambiar
  2. Espere el TTL actual completo antes de la ventana de migración (dale tiempo a los resolutores para que recojan el nuevo TTL corto)
  3. Realiza tus cambios de registro — la propagación ahora tarda un máximo de 5 minutos en lugar de 24 horas
  4. Después de que la migración sea estable: aumentar el TTL a 3600 o más

Esta es la diferencia entre una ventana de propagación de 5 minutos y una de 24 horas. Todo profesional de DNS hace esto. La mayoría de los principiantes aprenden por las malas.

Cómo comprobar la propagación de DNS ahora mismo

La forma más rápida: utiliza nuestro Comprobador de propagación de DNS : consulta su dominio desde múltiples ubicaciones geográficas simultáneamente y muestra si cada región devuelve su registro nuevo o antiguo.

Lo que estás buscando:

  • Verde/IP coincidentes: esas regiones ven tu nuevo récord
  • La IP antigua todavía se muestra: esos solucionadores aún no han caducado su caché
  • Resultados mixtos: normal durante la propagación: algunas regiones ven lo nuevo, otras lo viejo

Verificar mediante línea de comando si desea verificar la respuesta autorizada directamente (omitiendo cualquier caché):

Comando 
# Query a specific DNS server directly (bypasses your local cache)
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# On Linux/macOS — dig gives more detail
dig example.com @8.8.8.8
dig example.com @1.1.1.1

# Check the TTL of your current record
dig example.com | grep -i ttl

# Query the authoritative nameserver directly (no cache)
dig example.com @ns1.yourprovider.com

Si dig @ns1.yourprovider.com muestra tu nuevo registro pero dig @8.8.8.8 todavía muestra el anterior, su cambio es correcto; solo está esperando que caduque el caché del solucionador recursivo.

Limpia tu caché DNS local para dejar de ver datos obsoletos en su propia máquina:

Comando 
# Windows
ipconfig /flushdns

# macOS (Sequoia / Sonoma)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Chrome browser cache only
# Navigate to: chrome://net-internals/#dns → click "Clear host cache"

Nota: vaciar su caché local no ayuda si el solucionador de su ISP todavía tiene la respuesta anterior almacenada en caché. Su dispositivo simplemente volverá a consultar el solucionador de su ISP y obtendrá nuevamente la respuesta obsoleta.

Escenarios comunes de propagación de DNS

Escenario 1: Migración del sitio web a un nuevo servidor

Te estás mudando del host antiguo → al nuevo host. Antiguo registro A: 203.0.113.10. Nuevo: 198.51.100.20.

Qué sucede durante la propagación: usuarios con registros antiguos almacenados en caché aterrizan en un servidor antiguo. Los usuarios cuyos resolutores se hayan actualizado verán un nuevo servidor. Ambos servidores deben estar ejecutándose y entregando el mismo contenido hasta que se complete la propagación. Si apaga el servidor antiguo demasiado pronto, los usuarios con caché obsoleto obtendrán errores.

Mitigación: mantener activo el servidor antiguo durante al menos un TTL completo después del cambio. Si el TTL original era de 24 horas, mantenga el servidor antiguo activo 24 horas después del cambio.

Escenario 2: Migración del proveedor de correo electrónico (registro MX)

Los cambios en los registros MX afectan dónde se entrega el correo electrónico entrante. Los correos electrónicos enviados durante la propagación pueden llegar al servidor de correo antiguo o nuevo según el registro MX que resolvió el servidor de envío.

Riesgo: correos electrónicos entregados al servidor anterior después de haber dejado de monitorearlo. Solución: configure el servidor de correo antiguo para reenviarlo a uno nuevo durante una semana después de la migración, o mantenga accesibles los buzones antiguos durante la ventana TTL.

Escenario 3: CDN o transición del balanceador de carga (cambio de CNAME)

Los registros CNAME que apuntan a una CDN o un balanceador de carga generalmente se propagan más rápido que los registros A: el propio CNAME se almacena en caché, pero la IP subyacente que devuelve la CDN puede cambiar rápidamente sin afectar la propagación de su registro.

Cuidado con: Aplanamiento de CNAME. Algunos proveedores de DNS "aplanan" los registros CNAME en el vértice de la zona (reemplazando el CNAME con el registro A al que se resuelve). Esto puede provocar un comportamiento inesperado durante las migraciones si el proveedor almacena en caché la IP acoplada.

Escenario 4: Cambio de servidor de nombres (registro NS)

El tipo de propagación más lento. Los registros del servidor de nombres se almacenan en el nivel de registro de TLD (.com, .net, etc.) con TTL establecidos por el registro, normalmente entre 24 y 48 horas. No controlas este TTL.

Cuando cambia los servidores de nombres en su registrador:

  1. Su registrador notifica al registro de TLD
  2. Registro actualiza la delegación
  3. La actualización del Registro se propaga a través de los servidores de nombres raíz en todo el mundo

Espere entre 12 y 48 horas para que se propague por completo. No existe ningún truco de pre-descenso TTL que ayude en este caso.

Lista de verificación para solucionar problemas

✅ Si tu cambio de DNS no se propaga

1. Confirme que el nuevo registro sea correcto en el <strong>servidor autorizado</strong>: <code>dig example.com @ns1.yourprovider.com</code><br> 2. Verifique lo que ven varios solucionadores públicos: <a href="/dns-propagation.php">Herramienta de propagación de DNS →</a><br> 3. Vacíe su caché local (comandos arriba): es posible que solo esté viendo su propio caché obsoleto<br> 4. Verifique su TTL: <código>dig example.com | grep TTL</code>: si es 86400, estará esperando hasta 24 horas<br> 5. Si la autoridad muestra el registro correcto pero los resolutores no: espere a que expire el TTL; no hay nada más que hacer<br> 6. Si la autoridad muestra el registro incorrecto: realizó el cambio en el proveedor equivocado o no se ha guardado

Propagación DNS versus replicación DNS: la diferencia

A menudo se confunden. Están relacionados pero son distintos:

Propagación DNS = esperando a que caduquen los cachés de resolución recursiva y vuelva a consultar. Este es el retraso que experimentas como usuario. No puedes forzarlo. Solo puedes reducirlo bajando previamente el TTL.

Replicación de DNS = sincronización entre múltiples servidores de nombres autorizados para la misma zona (por ejemplo, ns1.provider.com y ns2.provider.com). La mayoría de los proveedores de DNS se replican en segundos. Si realiza un cambio y no se muestra en los servidores de nombres de su proveedor en 5 minutos, se trata de un problema del proveedor: comuníquese con el soporte.

Herramientas