--- id: "dns-propagation" kind: "glossary-term" title: "propagación de DNS" language: "es" category: "DNS y fundamentos técnicos" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/es/glosario/propagacion-dns/" translations: en: "https://tldlog.com/glossary/dns-propagation/" de: "https://tldlog.com/de/glossar/dns-propagation/" fr: "https://tldlog.com/fr/glossaire/propagation-dns/" it: "https://tldlog.com/it/glossario/propagazione-dns/" pt-BR: "https://tldlog.com/pt/glossario/propagacao-dns/" ru: "https://tldlog.com/ru/glossariy/rasprostranenie-dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns-chuanbo/" --- # propagación de DNS Nombre informal del retraso que hay hasta que todo el mundo ve un cambio en el DNS. En realidad nada se propaga por Internet: los resolutores simplemente conservan las respuestas antiguas hasta que caducan sus copias guardadas. La espera depende del TTL de los registros y, en los cambios de servidores de nombres, de la configuración propia del TLD. Cuando cambia la configuración DNS de un dominio, por ejemplo para trasladar una web o pasar a otros servidores de nombres, no todos los usuarios ven el cambio a la vez. Durante un tiempo, unos llegan a la configuración antigua y otros a la nueva. A esa espera se la llama propagación de DNS. ## Qué se entiende por propagación de DNS «Propagación» es un término informal. Hace pensar en un cambio que se extiende por Internet, pero nada se envía a ningún sitio. Los resolutores, los servidores que resuelven los nombres por cuenta de los usuarios, guardan copias de las respuestas que ya han recibido y las reutilizan hasta que caducan. Solo entonces vuelven a preguntar. La RFC 9499, el documento de terminología DNS del IETF, no tiene ninguna entrada para «propagación». El término suele abarcar dos tipos de cambio: - Un cambio en un registro de la propia zona del dominio, como un registro A nuevo que apunta el nombre a otro servidor web. - Un cambio de servidores de nombres. Se hace en el registrador, que lo pasa al registro del TLD; este publica la nueva delegación en su zona. ## Por qué los cambios no son inmediatos: caché y TTL Las cachés principales están en los resolutores recursivos de los proveedores de acceso a Internet, las empresas y los servicios públicos. El resolutor stub de un móvil o un ordenador suele apoyarse en uno de ellos. Cada registro DNS lleva un TTL: un número de segundos, fijado por quien gestiona la zona, que indica cuánto tiempo puede conservarse una copia. La copia guardada va descontando ese tiempo y, al llegar a cero, se descarta y la siguiente consulta vuelve a pedir el registro. Un TTL de 0 significa que no debe guardarse en caché. El TTL es un máximo, no una garantía. Los resolutores pueden limitar los TTL muy largos (la RFC 8767 recomienda un tope de siete días), y muchos conservan las respuestas al menos unas decenas de segundos aunque el TTL sea menor. Sobre todo, nadie puede borrar una copia guardada en el resolutor de otro. Esa es la verdadera causa de la espera. ## Cuánto tarda de verdad y cómo acortarlo antes de un cambio No hay una cifra universal: depende de los TTL en juego. Si cambia un registro, la respuesta antigua puede durar en un resolutor hasta el TTL anterior de ese registro, contado desde la última vez que lo consultó. Con un TTL de 3.600, un resolutor puede seguir dando la respuesta antigua hasta una hora después del cambio. En un cambio de servidores de nombres se suman tres esperas: 1. El registrador envía el cambio al registro. 2. El registro lo publica en la zona del TLD. En los gTLD con el Acuerdo de Registro base de la ICANN (versión del 21 de enero de 2024), el nivel de servicio es de 60 minutos en al menos el 95 % de las sondas de medición de la ICANN, a octubre de 2026. Esta cifra no se aplica a los gTLD heredados, como .com, que tienen sus propios acuerdos, ni a los ccTLD. 3. Caducan los registros NS guardados en caché. La zona del TLD tiene su propia copia de los registros NS del dominio, con un TTL que el titular no puede cambiar. La forma clásica de acortar la espera, descrita ya en la RFC 1034 en 1987, es bajar el TTL con antelación (al menos un periodo completo del TTL anterior antes del cambio), hacer el cambio y volver a subir el TTL. Para las zonas .es, Red.es recomienda un TTL del SOA y un Minimum normales de 3.600 segundos, y valores temporales que pueden bajar a 900 segundos (15 minutos) antes de cambios importantes (a octubre de 2026). Bajar los TTL propios no acorta la copia de los registros NS que tiene el TLD. ## Caché negativa: por qué un nombre nuevo puede seguir «sin existir» Los resolutores también recuerdan que algo no existe. Si alguien consulta un nombre antes de crear sus registros, el resolutor puede guardar una respuesta NXDOMAIN (el nombre no existe) o NODATA (el nombre existe, pero no tiene datos de ese tipo). Una respuesta negativa se conserva durante el menor de dos valores del registro SOA de la zona: su propio TTL y su campo Minimum. Con los valores normales de Red.es, 3.600 y 3.600 (a octubre de 2026), son hasta una hora. La RFC 2308 sugiere que los resolutores limiten por defecto la caché negativa a entre una y tres horas. La lección práctica: hay que crear los registros antes de probar o anunciar un nombre nuevo. Una prueba prematura puede hacer que parezca inexistente durante todo el tiempo de la caché negativa. ## Cómo comprobar si un cambio ya se ve - Preguntar directamente a los servidores autoritativos del dominio, que responden desde la zona y no desde una caché. - Después, preguntar a uno o varios resolutores recursivos. Si aún devuelven los datos antiguos, el TTL que muestran es el tiempo que falta para que vuelvan a preguntar. - En un cambio de servidores de nombres, comprobar que los servidores del TLD devuelven los registros NS nuevos. Eso es lo que mide el tiempo de actualización de la ICANN. ## Cómo planificar una migración sin cortes 1. Preparar antes el nuevo alojamiento o los nuevos servidores de nombres, y comprobar que ya responden de forma correcta y autoritativa para el dominio. Red.es lo recomienda para .es. 2. Bajar los TTL con antelación, como se explica arriba. 3. Hacer el cambio: editar los registros o cambiar los servidores de nombres a través del registrador. En .es, los cambios de delegación se solicitan a Red.es por el procedimiento establecido. 4. Mantener los servidores o el alojamiento antiguos en marcha, con datos correctos, al menos durante el mayor de los dos TTL, el del TLD y el del propio dominio. 5. Verificar y volver a subir los TTL. Un ejemplo, con valores solo ilustrativos: example.com tiene un registro A con un TTL de 86.400 segundos (un día). Dos días antes de trasladar la web, el titular baja el TTL a 900. Pasado un día, cambia el registro A y en unos 15 minutos los resolutores que respetan el TTL obtienen la nueva dirección. ## Fuentes - [Domain names - concepts and facilities (RFC 1034)](https://www.rfc-editor.org/rfc/rfc1034.txt) - [Negative Caching of DNS Queries (DNS NCACHE) (RFC 2308)](https://www.rfc-editor.org/rfc/rfc2308.txt) - [Considerations for Large Authoritative DNS Server Operators (RFC 9199)](https://www.rfc-editor.org/rfc/rfc9199.txt) - [Registry Agreement (ICANN base gTLD Registry Agreement, version of 21 January 2024), Specification 10](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html) - [Guía informativa DNS, Versión 1.1 (dominios.es, Red.es)](https://www.dominios.es/sites/dominios/files/2026-02/dns-guia-informativa-y-requisitos-de-configuracion.pdf) ## términos relacionados - [almacenamiento en caché de DNS](https://tldlog.com/es/glosario/almacenamiento-cache-dns/) - [TTL](https://tldlog.com/es/glosario/ttl/) - [resolutor](https://tldlog.com/es/glosario/resolutor/) - [registro NS](https://tldlog.com/es/glosario/registro-ns/) - [almacenamiento en caché de respuestas negativas](https://tldlog.com/es/glosario/almacenamiento-cache-respuestas-negativas/)