La propagación DNS es el tiempo que pasa desde que cambias un registro DNS hasta que todo el mundo ve el nuevo valor. En realidad no se envía nada: los resolvers de todo internet siguen sirviendo la copia que tienen en caché hasta que se agota su TTL (time to live) y entonces vuelven a preguntar. La mayoría de los cambios de registros se ven en todas partes dentro del TTL del registro antiguo, a menudo entre unos minutos y una hora. Los cambios de servidores de nombres en el registrador pueden tardar hasta dos días. Para saber en qué punto está un cambio, pregunta a los propios servidores de nombres del dominio qué publican y luego pregunta a algunos resolvers públicos qué siguen teniendo en caché.
Qué ocurre cuando cambias un registro
El navegador de un visitante no pregunta directamente a tu proveedor de DNS. La consulta pasa por varias cachés, y cada una puede responder de memoria:
El navegador guarda las respuestas recientes durante un rato.
El sistema operativo tiene su propia caché de resolución.
Un resolver recursivo del proveedor de internet, de la red de la empresa o de un servicio público como 1.1.1.1 u 8.8.8.8 guarda cada respuesta en caché durante el tiempo que permite su TTL.
Los servidores de nombres autoritativos de tu dominio tienen los registros reales. Al principio, solo ellos conocen tu cambio.
Cuando guardas un cambio en tu proveedor de DNS, los servidores de nombres autoritativos suelen servirlo en cuestión de segundos o minutos. Cada caché de más abajo conserva la respuesta antigua hasta que caduca su copia. Por eso dos visitantes en redes distintas pueden ver servidores diferentes durante un tiempo, y eso es normal, no un error. El TTL lo fijas tú, por registro y en segundos; la entrada del glosario sobre propagación DNS tiene la versión corta.
Cuánto tarda la propagación DNS
Registros normales: el TTL antiguo
Para un registro A, AAAA, CNAME, MX o TXT, la espera máxima es el TTL que tenía el registro antiguo cuando los resolvers lo guardaron en caché. Un registro con un TTL de 3600 puede servirse desde la caché hasta una hora después de cambiarlo. Bajar el TTL en el mismo momento del cambio no sirve de nada, porque los resolvers que ya tienen la copia antigua la conservan durante el TTL antiguo.
Cambios de servidores de nombres: la zona padre
Pasar un dominio a otro proveedor de DNS implica cambiar sus registros NS en el registrador. Esos registros se publican en la zona padre, como .com, y es la zona padre la que fija su TTL, no tú. Puedes comprobarlo tú mismo preguntando directamente a un servidor de .com:
dig +norecurse @a.gtld-servers.net example.com NS
La respuesta muestra los servidores de nombres con un TTL de 172800 segundos, es decir, 48 horas. De ahí viene el consejo de «hasta 48 horas». Durante ese tiempo, unos resolvers preguntan al proveedor antiguo y otros al nuevo, así que ambos deben servir los mismos registros hasta que el cambio se haya asentado.
Nombres nuevos: la caché negativa
Si alguien consultó un nombre antes de que existiera, por ejemplo un subdominio nuevo que probaste demasiado pronto, los resolvers pueden guardar en caché también la respuesta «ese nombre no existe». El RFC 2308 fija durante cuánto tiempo: el menor entre el campo minimum del registro SOA y el TTL del propio registro SOA. Por eso un subdominio recién creado puede mostrar DNS_PROBE_FINISHED_NXDOMAIN durante un rato en una red y funcionar en otra.
Aplicaciones que se aferran a las direcciones
Un programa que lleva mucho tiempo en ejecución, como un servidor de aplicaciones o un proxy, puede resolver un nombre de host una sola vez al arrancar y conservar la dirección hasta que se reinicia, diga lo que diga el TTL. Si un servicio sigue hablando con el servidor antiguo cuando todo lo demás ya se ha movido, reinícialo antes de sospechar del DNS.
Cómo comprobar la propagación DNS
Trabaja desde el origen hacia fuera. Primero confirma que el cambio está publicado y luego mira qué cachés siguen teniendo la respuesta antigua.
1. Averigua cuáles son los servidores de nombres autoritativos
dig NS example.com +short
Si no son los servidores de nombres del proveedor donde hiciste el cambio, editaste la zona equivocada. Es un motivo habitual por el que un cambio «nunca se propaga».
2. Pregunta directamente a cada servidor de nombres
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Repite la consulta con cada servidor de nombres de la lista. Todos deberían devolver el valor nuevo y el mismo número de serie del SOA, el tercer campo de la respuesta SOA. Un servidor con un número de serie más antiguo aún no ha recibido la actualización; eso es propagación dentro de tu proveedor, y suele resolverse en pocos minutos.
3. Pregunta a resolvers públicos
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Sin +short, dig muestra el TTL de cada respuesta. En un resolver, ese número es el tiempo que le queda a su copia en caché: un valor antiguo al que le quedan 1200 segundos se sustituirá en menos de 20 minutos. En Windows, nslookup -type=A example.com 1.1.1.1 pregunta a un resolver concreto, sin mostrar el TTL. Nuestra consulta DNS gratuita muestra las respuestas y los TTL de cualquier tipo de registro desde el resolver de nuestro servidor en Estocolmo, sin instalar nada.
4. Sigue la delegación tras cambiar de servidores de nombres
dig +trace example.com
+trace empieza en la raíz y sigue las referencias hasta tus servidores de nombres, ignorando las cachés por el camino. Si la traza termina en el proveedor nuevo, el cambio en el registrador ya está activo, y lo que queda es que las cachés se pongan al día.
Planifica el cambio para que la propagación no duela
No puedes acelerar la propagación después de un cambio, pero sí puedes hacer que sea corta antes de empezar. Para pasar a un servidor nuevo:
CuándoPasoAl menos un TTL antiguo antesBaja el TTL del registro, por ejemplo de 3600 a 300 segundos.Antes del cambioPrepara el servidor nuevo y pruébalo, por ejemplo con una entrada en el archivo hosts o con curl –resolve.El cambioApunta el registro al servidor nuevo y comprueba la respuesta autoritativa.Durante la propagaciónMantén el servidor antiguo en marcha y sirviendo el mismo contenido. Algunos visitantes siguen llegando a él.Un día o así despuésVuelve a subir el TTL y apaga el servidor antiguo.
Si cambias de servidores de nombres, copia primero todos los registros al proveedor nuevo y compara las dos zonas registro por registro, MX y TXT incluidos. Un registro TXT olvidado rompe la autenticación del correo; el comprobador de SPF, DKIM y DMARC te muestra si sigue pasando. Si el dominio usa DNSSEC, sigue los pasos del proveedor nuevo para el registro DS en el registrador, porque un registro DS que no coincide con los nuevos servidores de nombres hace que los resolvers que validan respondan SERVFAIL.
Vaciar las cachés que controlas
Puedes vaciar tus propias cachés para ver antes el valor nuevo, algo útil mientras haces pruebas. Para tus visitantes no cambia nada.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: abre chrome://net-internals/#dns y vacía la caché de hosts.
Resolvers públicos: Cloudflare y Google te permiten purgar un nombre de sus cachés, en la página de purga de 1.1.1.1 y en la página de vaciado de Google Public DNS.
El resolver de tu proveedor de internet y los de tus visitantes no se pueden vaciar desde fuera. Caducan a su propio ritmo.
Cuando no es la propagación
Si los servidores de nombres autoritativos siguen devolviendo el valor antiguo, esperar no servirá de nada. Busca en su lugar una de estas causas:
La zona o el proveedor equivocados. El registro se cambió en un proveedor que el dominio ya no usa.
El nombre equivocado. El dominio raíz (example.com) y www.example.com son registros distintos.
Un proxy delante. Con un CDN o un proxy activado para el registro, el DNS público devuelve las direcciones del proxy, no las de tu servidor, y es así por diseño.
Un registro que nunca se guardó, o una errata en el valor. Compara lo que ves en el panel del proveedor con la respuesta de dig.
La entrada sobre tipos de registros DNS explica para qué sirve cada registro, y la checklist para cuando tu web se cae cubre los pasos posteriores al DNS.
Entérate de cuándo cambia un registro con Uptimecheck
La propagación es el tipo de cambio de DNS planificado. El no planificado, una errata durante una migración o una cuenta del registrador secuestrada, es el que merece una alerta. La monitorización de DNS de Uptimecheck vigila los registros A, AAAA, CNAME, MX, NS, SOA, TXT y CAA:
Pregunta directamente a los servidores de nombres autoritativos del dominio, así que un cambio aparece en la siguiente comprobación, sin ninguna caché de resolver de por medio. Cuando los servidores de nombres dan respuestas distintas, la página del monitor lo indica.
Un conjunto de registros nuevo genera una alerta en cuanto dos comprobaciones seguidas lo han visto, con los valores antiguos y los nuevos, y queda guardado en el historial del registro.
Introduce los valores que esperas y la comprobación fallará siempre que los registros publicados no coincidan con ellos, lo que además confirma que un cambio planificado ya está activo.
Las comprobaciones se ejecutan hasta cada minuto. Start incluye 10 monitores de DNS, Professional 25 y Business 150.
Combínala con comprobaciones de disponibilidad de la propia web y con la monitorización de la caducidad del dominio. Para configurar uno, consulta cómo configurar la monitorización de DNS, y lee cómo detectar registros DNS secuestrados para conocer las señales de alarma.
Entérate en el momento en que cambian tus registros. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.