--- id: "dns-propagation" kind: "glossary-term" title: "DNS propagation" language: "en" category: "DNS and technical foundations" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/dns-propagation/" translations: es: "https://tldlog.com/es/glosario/propagacion-dns/" 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/" --- # DNS propagation The informal name for the delay before a DNS change is seen by everyone. Nothing actually spreads across the internet: resolvers simply keep old answers until their stored copies expire. The wait depends on the TTL of the records and, for name server changes, on the TLD's own settings. When a domain's DNS settings change, for example to move a website or switch to new name servers, not every user sees the change at the same moment. For a while some people reach the old setup and others the new one. That wait is what people call DNS propagation. ## What people mean by DNS propagation "Propagation" is an informal word. It suggests a change travelling outward across the internet, but nothing is pushed anywhere. Resolvers, the servers that look up names for users, keep copies of answers they have already received and reuse them until they expire. Only then do they ask again. RFC 9499, the IETF's DNS terminology document, has no entry for "propagation". The term usually covers two kinds of change: - A change to a record in the domain's own zone, such as a new A record that points the name at a new web server. - A change of name servers. It is made at the registrar, which passes it to the registry; the registry then publishes the new delegation in the TLD zone. ## Why changes are not instant: caching and TTL The main caches are the recursive resolvers run by internet providers, companies and public services. The stub resolver on a phone or computer normally relies on one of them. Every DNS record carries a TTL: a number of seconds, set by whoever runs the zone, that says how long a copy may be kept. A cached copy counts down, and at zero the copy is discarded and the next lookup fetches the record again. A TTL of 0 means the record must not be cached. The TTL is a maximum, not a promise. Resolvers may cap very long TTLs (RFC 8767 recommends a cap of seven days), and many keep answers for at least tens of seconds even when the TTL is lower. Above all, nobody can delete a cached copy from someone else's resolver. That is the real reason for the wait. ## How long it really takes, and how to shorten it before a change There is no single universal figure: it depends on the TTLs involved. For a record change, the old answer can survive in a resolver for up to the record's old TTL, counted from when that resolver last fetched it. With a TTL of 3600, a resolver may give the old answer for up to one hour after the change. For a name server change, three delays add up: 1. The registrar sends the change to the registry. 2. The registry publishes it in the TLD zone. For gTLDs under ICANN's base Registry Agreement (version of 21 January 2024), the service level is 60 minutes for at least 95% of ICANN's test probes, as of October 2026. This figure does not cover legacy gTLDs such as .com, which have their own agreements, or ccTLDs. 3. Cached NS records expire. The TLD zone holds its own copy of the domain's NS records, with a TTL the domain holder cannot change. The standard way to shorten the wait, described in RFC 1034 in 1987, is to lower the TTL in advance, at least one full old-TTL period before the change, make the change, then raise the TTL again. For .es zones, Red.es recommends a normal SOA TTL and Minimum of 3600 seconds, and temporary values down to 900 seconds (15 minutes) before major changes (as of October 2026). Lowering your own TTLs does not shorten the TLD's copy of the NS records. ## Negative caching: why a new name can stay "missing" Resolvers also remember that something does not exist. If someone looks up a name before its records are created, the resolver can cache an NXDOMAIN answer (the name does not exist) or a NODATA answer (the name exists but has no record of that type). A negative answer is kept for the lower of two values in the zone's SOA record: its own TTL and its Minimum field. With Red.es's normal values of 3600 and 3600 (as of October 2026), that is up to one hour. RFC 2308 suggests resolvers limit negative caching to one to three hours by default. The practical lesson: create the records before testing or announcing a new name. An early test can make it look missing for the whole negative-cache time. ## How to check whether a change is visible - Ask the domain's authoritative servers directly. They answer from the zone, not from a cache. - Then ask one or more recursive resolvers. If they still return old data, the TTL they show is the time left before they ask again. - For a name server change, check that the TLD's servers return the new NS records. That is the point ICANN's update time measures. ## Planning a migration without downtime 1. Set up the new hosting or name servers first, and check that the new servers already answer correctly and authoritatively for the domain. Red.es recommends this for .es. 2. Lower the TTLs in advance, as described above. 3. Make the change: edit the records, or change name servers through the registrar. For .es, delegation changes are requested from Red.es through its established procedure. 4. Keep the old servers or hosting running with correct data for at least the longer of the TLD's TTL and the domain's own TTL. 5. Verify, then raise the TTLs again. A worked example, with illustrative values only: example.com has an A record with a TTL of 86400 seconds (one day). Two days before moving the website, the owner lowers the TTL to 900. Once the old one-day TTL has passed, the owner changes the A record, and within about 15 minutes resolvers that respect the TTL get the new address. ## Sources - [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) ## related terms - [DNS caching](https://tldlog.com/glossary/dns-caching/) - [TTL](https://tldlog.com/glossary/ttl/) - [resolver](https://tldlog.com/glossary/resolver/) - [NS record](https://tldlog.com/glossary/ns-record/) - [negative caching](https://tldlog.com/glossary/negative-caching/)