Propagación DNS: qué es y cómo reducir su impacto
La propagación DNS es el periodo durante el cual algunos resolvedores siguen sirviendo el valor antiguo de un registro después de modificarlo en el servidor de nombres autoritativo. No es una difusión: cada resolvedor conserva su respuesta en caché hasta que vence el TTL. El retraso va de unos minutos a 24 o 48 horas en un cambio de servidores de nombres, según el TTL del registro antes del cambio y, para los servidores de nombres, según el TTL de delegación que fija el registro del dominio de nivel superior. Así funciona y así se limita su impacto.
Puntos clave
- El cambio es visible al instante en el servidor autoritativo. El retraso procede solo de las cachés de los resolvedores, que conservan el valor antiguo hasta que vence su TTL.
- Lo que fija cuánto dura el valor antiguo es el TTL vigente antes del cambio, no el que acaba de introducir. Redúzcalo con antelación.
- Un cambio de servidores de nombres es el más lento, porque depende del TTL de delegación del registro, que usted no controla.
- Los errores «este nombre no existe» también se guardan en caché: visitar un nombre antes de crear su registro puede alargar el error.
Lo que la propagación DNS no es: una difusión
El término engaña. Ningún servidor envía su cambio a los demás. Cuando guarda una modificación en su proveedor de DNS, el servidor de nombres autoritativo de la zona sirve el nuevo valor de inmediato. El retraso está en otra parte: en las cachés.
Cuando un equipo busca la dirección de un nombre de dominio, la consulta atraviesa varias capas, y cada una puede recordar la respuesta:
- el navegador, cuya caché suele durar del orden de un minuto y no siempre respeta el TTL;
- el sistema operativo, que conserva las respuestas recientes;
- el resolvedor recursivo, del proveedor de acceso o público (por ejemplo 8.8.8.8 de Google o 1.1.1.1 de Cloudflare), que recorre la jerarquía DNS y guarda el resultado.
Cada resolvedor aplica el TTL que el servidor autoritativo le indicó en el momento de guardar la respuesta. Como no consultaron todos a la vez, sus copias vencen en momentos distintos. Un registro con TTL de 3600 segundos guardado hace 5 minutos se renovará dentro de 55 minutos. De ahí los informes contradictorios: uno ve el sitio nuevo, otro el antiguo y un tercero, un error.
Cuánto dura una propagación DNS
La duración depende del tipo de cambio. Un TTL de un día (86 400 segundos) es habitual, y los valores son más altos en los registros que casi no cambian, como los servidores de nombres.
| Tipo de cambio | Duración habitual | Qué la determina |
|---|---|---|
| Modificar un registro existente (A, AAAA, CNAME, MX, TXT) | Hasta la duración del TTL antiguo, de unos minutos a 24 horas según la configuración | El TTL vigente antes de la modificación |
| Crear un registro que no existía | Variable, normalmente unas pocas horas como máximo | El SOA de la zona (TTL del SOA y campo MINIMUM) |
| Cambiar los servidores de nombres en el registrador | De unas horas a 48 horas | El TTL de delegación del registro, a menudo de uno a dos días |
| Un resolvedor con límites propios | Puede superar el TTL anunciado | Un tope o un mínimo configurado (86 400 s por defecto en Unbound, 604 800 s en BIND) |
Los tres factores que deciden el retraso
El TTL de antes del cambio
Imagine un registro con TTL de 86 400 segundos que hoy ajusta a 300. Un resolvedor que lo guardó ayer conserva el valor antiguo hasta 24 horas, sea cual sea el nuevo valor: el TTL de 300 segundos solo se aplica cuando su copia se renueva. En un CNAME, cada nombre de la cadena tiene su propio TTL, y el más largo marca el retraso total.
La delegación en el registro
Al cambiar de servidores de nombres, la modificación se hace en el registrador, que la transmite al registro del dominio de nivel superior. Los resolvedores que aún conocen la lista antigua de servidores de nombres siguen consultándolos hasta que expira la delegación. Ese TTL pertenece al registro: no puede acortarlo.
Los resolvedores que no siguen el TTL al pie de la letra
Algunos resolvedores limitan o elevan los TTL, y los navegadores tienen su propia caché de corta duración. No se puede garantizar la misma duración en todas partes. El TTL es un límite teórico, no un compromiso de todas las cachés.
La trampa de la caché negativa
La mayoría de las guías hablan del TTL de los registros y olvidan las respuestas negativas. Cuando un resolvedor descubre que un nombre no existe (respuesta NXDOMAIN) o que no tiene registro del tipo pedido, puede recordar esa ausencia. La RFC 2308 fija la duración de la caché negativa en el menor de dos valores: el TTL del SOA de la zona y su campo MINIMUM. Considera razonables duraciones de una a tres horas y advierte de que superar un día da problemas.
El escenario típico: prueba nuevo.example.com antes de crear el registro, obtiene un error y después crea el registro. Para su resolvedor, el nombre «no existe» hasta que termina la caché negativa, aunque el registro lleve un minuto activo. Cómo evitarlo:
- cree el registro antes de probar o anunciar el nombre;
- si su proveedor de DNS permite ajustar el SOA, mantenga un campo MINIMUM moderado;
- vacíe la caché local antes de concluir que «no funciona»: Microsoft indica que
ipconfig /flushdnstambién descarta las entradas de caché negativas.
Método para limitar el impacto de una migración
- Anote el TTL actual de cada registro afectado (véanse los comandos más abajo). Es el que fija el retraso.
- Reduzca el TTL a 300 segundos, con al menos tanta antelación como dure el TTL antiguo. Con 86 400 segundos, hágalo entre 24 y 48 horas antes del cambio. Compruebe el mínimo que acepta su proveedor.
- Prepare el nuevo destino: sitio web, servidor de correo o CDN listo para responder con el mismo contenido que el anterior. Ambos deben funcionar durante la transición.
- Cambie el registro, una modificación cada vez para saber qué verificar.
- Verifique primero el servidor autoritativo y después los resolvedores públicos.
- Mantenga activo el servidor antiguo al menos hasta que pase el TTL antiguo más largo, y solo entonces apáguelo.
- Vuelva a subir el TTL (3600 segundos o más) cuando todo esté estable.
En un cambio de servidores de nombres, recree primero la zona completa en el nuevo proveedor (A, CNAME, MX, TXT con SPF y DKIM, y todo lo demás), compruebe que responde bien y solo entonces cambie los servidores de nombres en el registrador. Deje la zona del proveedor antiguo activa e idéntica durante 48 horas: los resolvedores que aún conocen la delegación antigua siguen consultándola.
Comprobar qué ve cada resolvedor
El comando dig (macOS, Linux) o nslookup (Windows) permite comparar lo que responden el servidor autoritativo y varios resolvedores públicos.
# Valor y TTL restante que ven los resolvedores públicos
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1
# Servidores de nombres declarados para el dominio
dig +short NS example.com
# Valor que sirve el servidor autoritativo (sustituya por su servidor de nombres)
dig +noall +answer example.com A @ns1.proveedor-dns.example
# Número de serie del SOA, para comparar entre servidores de nombres
dig +short SOA example.com @ns1.proveedor-dns.example
dig +short SOA example.com @ns2.proveedor-dns.example# Equivalente en Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.comEn la respuesta de un resolvedor, el TTL mostrado disminuye de una consulta a otra: es el tiempo que queda antes de que venza su copia. Si un resolvedor devuelve el valor antiguo con un TTL que sigue bajando mientras el servidor autoritativo ya devuelve el nuevo, solo hay que esperar.
Compare también el número de serie del SOA entre sus servidores de nombres. Si difieren, un servidor sirve datos obsoletos: el problema es de su proveedor de DNS, no de la propagación. La página dns.google permite consultar un tipo de registro concreto, incluido el SOA, y la guía de solución de problemas de Google Public DNS detalla esta comprobación.
Vaciar las cachés que usted controla
Vaciar su propia caché no cambia nada para los demás visitantes, pero le permite comprobar lo que ve realmente.
# Windows (símbolo del sistema)
ipconfig /flushdns
# macOS reciente
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux con systemd-resolved
resolvectl flush-cachesMicrosoft describe /flushdns y /displaydns en su página del comando ipconfig. Después cierre por completo el navegador, que guarda su propia memoria de corta duración.
Dos resolvedores públicos ofrecen además una purga, útil tras un cambio de servidores de nombres o para quienes los usan: la herramienta Flush Cache de Google Public DNS (Google aconseja purgar el dominio registrado y el nombre exacto que devuelve una respuesta obsoleta) y la purga de caché de 1.1.1.1 de Cloudflare, donde se elige el dominio y el tipo de registro. Los resolvedores de los proveedores de acceso no se pueden purgar: hay que esperar a que venzan sus copias.
Errores frecuentes
- Reducir el TTL en el momento del cambio. Es tarde: los resolvedores conservan la copia hecha con el TTL antiguo.
- Probar el nombre antes de crear el registro. La caché negativa puede alargar el error.
- Cambiar los servidores de nombres antes de recrear toda la zona. Los registros de correo o subdominios olvidados dejan de funcionar para los resolvedores que ya consultan al nuevo proveedor.
- Apagar demasiado pronto el servidor antiguo. Los visitantes cuya caché no ha vencido llegan a un servidor que ya no responde.
- Dar por terminada la propagación desde su propio equipo. Su caché local no representa a los demás resolvedores.
- Dejar un TTL muy bajo de forma permanente. Multiplica las consultas a sus servidores de nombres. Vuelva a subirlo al terminar la migración.
Preguntas frecuentes
¿Cuánto dura la propagación DNS?
Al modificar un registro, como máximo la duración del TTL antiguo: una hora con un TTL de 3600 segundos, 24 horas con 86 400. En un cambio de servidores de nombres, de unas horas a 48 horas. La mayoría de los resolvedores se actualizan mucho antes del plazo máximo. Lo que queda son algunas cachés rezagadas.
¿Se puede acelerar la propagación DNS?
No en todo Internet: no se pueden forzar las cachés ajenas. Sí se puede reducir el TTL antes del cambio, purgar los resolvedores públicos de Google y Cloudflare y vaciar las cachés propias. Los resolvedores de los proveedores de acceso no se pueden purgar.
¿Qué TTL elegir antes de una migración?
Un valor corto como 300 segundos (5 minutos), aplicado al menos durante el TTL antiguo antes del cambio. Cuando la migración esté estable, súbalo de nuevo a 3600 segundos o más: un TTL muy bajo y permanente multiplica las consultas. Compruebe el mínimo que acepta su proveedor de DNS.
¿Por qué mi compañero ve el sitio nuevo y yo no?
Pasan por resolvedores distintos, que guardaron la respuesta en momentos distintos. Consulte el mismo resolvedor público desde ambos equipos para comparar y vacíe la caché local del equipo que sigue viendo la versión antigua.
¿Qué pasa con mi correo durante la propagación?
Un cambio de registro MX sigue las mismas reglas: durante el retraso, algunos remitentes siguen escribiendo al servidor de correo antiguo. Manténgalo activo hasta el final de la transición. Si un servidor no está disponible, los servidores de envío suelen conservar los mensajes y reintentar durante varios días.
¿Hay que vaciar la caché del ordenador?
Sí, para comprobar lo que usted ve, pero no cambia nada para los demás visitantes. Use el comando de su sistema y cierre por completo el navegador. Si el valor sigue siendo el antiguo, la copia la guarda el resolvedor de su proveedor de acceso.
¿Por qué las herramientas en línea de comprobación dan resultados distintos?
Cada una consulta resolvedores de países distintos, que guardaron la respuesta en momentos distintos. Un resultado mixto es normal mientras el TTL no haya vencido en todas partes. Si los propios servidores autoritativos responden distinto, compare los números de serie del SOA: el problema está entonces en la zona, no en la propagación.