La propagación DNS es el período de tiempo entre cuando actualizas un registro DNS y cuando todos los resolvers del mundo dejan de servir el valor anterior y comienzan a servir el nuevo.
TL;DR La propagación DNS no es una transmisión — los cambios de DNS no se envían al mundo. Cuando actualizas un registro DNS, solo tu servidor de nombres autoritativo se actualiza de inmediato. Los resolvers de todo el mundo almacenan en caché tu registro anterior durante el tiempo que indica su TTL (Time To Live). Hasta que ese TTL expire, siguen sirviendo el valor anterior a quien lo solicite. Un registro con TTL 86400 puede tardar hasta 24 horas en propagarse globalmente. La solución: reduce tu TTL a 300 segundos al menos 24–48 horas antes de cualquier cambio planificado, luego auméntalo nuevamente después de que la migración sea estable.
¿Qué es la propagación DNS?
La propagación DNS es el tiempo que tarda un cambio en un registro DNS — realizado en tu servidor de nombres autoritativo — en reflejarse en todos los resolvers recursivos a nivel global.
El término “propagación” es ligeramente engañoso. Los cambios de DNS no se propagan activamente hacia afuera. En cambio, los resolvers mantienen copias en caché de los registros DNS durante la duración del TTL del registro. Cuando el TTL expira, el resolver vuelve a consultar el servidor autoritativo y obtiene el valor actualizado.
El servidor autoritativo se actualiza instantáneamente. El retraso se debe completamente a las copias en caché en los resolvers de todo el mundo que aún no han expirado.
Por qué la propagación DNS lleva tiempo
Cuando un usuario consulta un dominio, casi nunca contacta directamente tu servidor de nombres autoritativo. Su resolver DNS (ISP, DNS corporativo, 8.8.8.8, 1.1.1.1) almacena la respuesta en caché y la sirve desde el caché para solicitudes posteriores — hasta que el TTL expire.
La línea de tiempo de propagación:
- Actualizas un registro A en tu servidor de nombres autoritativo. El cambio está activo de inmediato en el servidor autoritativo.
- Un resolver que almacenó el registro anterior en caché seguirá sirviéndolo hasta que su TTL en caché expire.
- Cuando el TTL expira, el resolver vuelve a consultar el servidor autoritativo y obtiene el nuevo valor.
- Diferentes resolvers almacenaron el registro en caché en diferentes momentos — por lo que expiran en diferentes momentos.
- Propagación completa = el tiempo hasta que la última copia en caché del resolver haya expirado.
TTL: la variable clave
TTL (Time To Live) es el número de segundos que un resolver tiene permitido almacenar en caché un registro DNS antes de volver a consultar el servidor autoritativo.
| Valor de TTL | Duración del caché | Tiempo de propagación |
|---|---|---|
| 300 (5 minutos) | 5 minutos | ~5–15 minutos globalmente |
| 3600 (1 hora) | 1 hora | ~1–2 horas globalmente |
| 86400 (24 horas) | 24 horas | Hasta 48 horas globalmente |
| 172800 (48 horas) | 48 horas | Hasta 72+ horas globalmente |
Un resolver que almacenó tu registro en caché hace 23 horas y 59 minutos con TTL 86400 servirá el valor anterior durante otro minuto más. Un resolver que acaba de almacenarlo en caché servirá el valor anterior por casi 24 horas. Por eso el tiempo de propagación es aproximadamente igual al TTL restante de la copia almacenada en caché más antigua del mundo.
Cómo reducir el tiempo de propagación
Paso 1: Reduce el TTL antes del cambio (con 24–48 horas de anticipación)
Cambia el TTL de tu registro a 300 segundos (5 minutos) al menos 24–48 horas antes de tu migración planificada. Esto le da tiempo a todas las copias en caché existentes para expirar y ser reemplazadas por el nuevo registro de TTL bajo.
Antes de la migración (48h antes): TTL 86400 → cambia a TTL 300Día de la migración: Haz el cambio del registro (registro A, nameserver, etc.)Después de que la migración sea estable: Sube el TTL de nuevo a 3600 o 86400Si omites este paso y cambias el registro mientras el TTL anterior sigue siendo 86400, algunos resolvers servirán el valor anterior hasta por 24 horas.
Paso 2: Haz el cambio de DNS
Una vez que el TTL bajo haya tenido tiempo de propagarse (24–48 horas), cambia el valor real del registro (la dirección IP, nameserver o destino CNAME). Con TTL 300, el nuevo valor debería ser visible globalmente en 5–15 minutos.
Paso 3: Verifica en múltiples resolvers
Usa herramientas como dnschecker.org o WhatsMyDNS.net para verificar el valor de tu registro en 20+ resolvers en diferentes países simultáneamente.
Paso 4: Sube el TTL después de la estabilización
Una vez que la migración se confirme como estable, sube el TTL de nuevo a 3600 o 86400 para reducir la carga en tu servidor autoritativo y mejorar el rendimiento de resolución para los usuarios.
Qué afecta la velocidad de propagación
| Factor | Efecto |
|---|---|
| Valor de TTL | El control principal — TTL más bajo = propagación más rápida |
| Comportamiento de caché del resolver | Algunos resolvers respetan el TTL exactamente; otros almacenan en caché un poco más |
| Tasas de actualización del resolver del ISP | Los resolvers corporativos y de ISP pueden tener tiempos mínimos de caché independientemente del TTL |
| Distribución geográfica | Los resolvers en diferentes regiones expiran en diferentes momentos |
| TTL negativo (NXDOMAIN) | Las búsquedas fallidas (dominio no encontrado) también se almacenan en caché — definidas en el registro SOA |
Propagación vs. cambio autoritativo
| Cambio autoritativo | Propagación | |
|---|---|---|
| Cuándo ocurre | Instantáneamente cuando guardas el cambio | A lo largo del período de expiración del TTL globalmente |
| Quién lo ve primero | Consultas directas a tu servidor autoritativo | Nadie hasta que su TTL en caché expire |
| Cómo verificar | Consulta tu servidor autoritativo directamente: dig @ns1.tudominio.com example.com | Usa una herramienta de verificación en múltiples ubicaciones |
Para verificar que el servidor autoritativo tiene tu cambio de inmediato, consúltalo directamente:
dig @ns1.example.com example.com APara verificar lo que los resolvers globales están sirviendo actualmente:
dig @8.8.8.8 example.com A # Resolver de Googledig @1.1.1.1 example.com A # Resolver de CloudflareProblemas comunes de propagación
| Problema | Causa | Solución |
|---|---|---|
| Cambio no visible después de 24+ horas | El TTL estaba alto cuando se hizo el cambio | Espera; verifica con consulta autoritativa directa para confirmar que el cambio está activo |
| Diferentes usuarios ven diferentes valores | Diferentes resolvers tienen diferentes edades de caché | Normal durante la propagación; se resuelve cuando todos los TTL expiran |
| El cambio se revirtió después de parecer funcionar | Registro anterior devuelto por resolver que re-almacenó en caché antes de que el TTL expirara | Verifica que el servidor autoritativo esté correctamente actualizado |
| “Propagación detenida” en una región | El resolver del ISP regional ignora el TTL | Contacta al ISP; usa resolvers públicos alternativos (8.8.8.8, 1.1.1.1) |
Preguntas frecuentes
¿Cuánto tiempo tarda la propagación DNS? El tiempo de propagación DNS es igual al TTL del registro que se cambió. Un registro con TTL 86400 (24 horas) puede tardar hasta 24–48 horas en propagarse globalmente, porque algunos resolvers pueden haber almacenado en caché el valor anterior cerca del inicio de la ventana de 24 horas. Un registro con TTL 300 (5 minutos) se propaga en 5–15 minutos. La solución es reducir el TTL antes de hacer cambios.
¿Por qué la propagación DNS tarda tanto? La propagación DNS no es una transmisión — los cambios no se envían al mundo. Los resolvers almacenan en caché tus registros DNS durante la duración del TTL y vuelven a consultar el servidor autoritativo solo cuando el caché expira. Diferentes resolvers almacenaron el registro en caché en diferentes momentos, por lo que expiran en diferentes momentos. La copia almacenada en caché más antigua determina el tiempo máximo de propagación.
¿Puedo acelerar la propagación DNS? Sí — reduciendo el TTL antes de hacer cambios. Establece el TTL en 300 (5 minutos) al menos 24–48 horas antes de tu cambio planificado. Esto garantiza que todas las copias en caché expiren rápidamente. Para cambios de emergencia cuando el TTL ya es alto, no puedes hacer mucho excepto esperar — o contactar a los principales ISPs para que vacíen sus cachés manualmente.
¿La propagación DNS es igual en todas partes? No. Diferentes resolvers en todo el mundo tienen copias en caché diferentes con diferentes antigüedades. Un resolver que consultó tu registro hace 5 minutos con un TTL de 1 hora verá la actualización en 55 minutos. Un resolver que consultó 5 minutos después de que cambiaste el registro ve el nuevo valor de inmediato. “Propagación completa” significa que los cachés de todos los resolvers han expirado y se han actualizado.
¿Cómo verifico la propagación DNS? Usa una herramienta en línea como dnschecker.org o WhatsMyDNS.net — consultan tu dominio desde 20+ resolvers en diferentes países simultáneamente y muestran cuáles tienen el nuevo valor. Desde la línea de comandos: dig @8.8.8.8 tudominio.com A para verificar el resolver de Google, y dig @ns1.tudominio.com tudominio.com A para verificar el servidor autoritativo directamente.
¿Reducir el TTL afecta el rendimiento? Un TTL más bajo significa que los resolvers vuelven a consultar tu servidor autoritativo con más frecuencia, aumentando su carga de consultas. Para dominios de alto tráfico, un TTL de 300 puede generar significativamente más consultas autoritativas que 86400. Por eso reduces el TTL temporalmente antes de las migraciones y lo subes nuevamente después de la estabilización.
¿Qué es el TTL negativo en DNS? El TTL negativo es cuánto tiempo los resolvers almacenan en caché una respuesta “dominio no encontrado” (NXDOMAIN). Se define en el campo de TTL mínimo del registro SOA. Si eliminas un registro y luego lo recreas inmediatamente, los resolvers que almacenaron en caché la respuesta NXDOMAIN seguirán devolviendo “no encontrado” hasta que el TTL negativo expire.
¿Qué pasa con el tráfico durante la propagación DNS? Durante la propagación, diferentes usuarios se enrutan a diferentes servidores dependiendo de qué registro DNS está sirviendo su resolver. Por eso es importante mantener la infraestructura anterior en funcionamiento hasta que la propagación sea completa — los usuarios que aún llegan al registro anterior deben poder alcanzar el servidor anterior, mientras que los usuarios con el nuevo registro llegan al nuevo servidor.