DNS propagation: definition

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 Request for Comments A numbered document in the series recording the internet's technical standards and practices. Full definition of RFC 9499, the IETF Internet Engineering Task Force The open body that writes internet standards such as DNS, EPP and RDAP. Full definition of 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 A DNS record that points a domain name to an IPv4 address. Full definition of A record that points the name at a new web server.
A change of name servers. It is made at the registrar A company that registers domain names for customers with the registry. Full definition of registrar, which passes it to the registry The central database and system of a top-level domain, or loosely the organization that runs it. Full definition of 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 The simple DNS client on a device that passes lookups to a recursive resolver. Full definition of stub resolver on a phone or computer normally relies on one of them.

Every DNS record One entry in a DNS zone, made of a name, a type, a TTL and data. Full definition of 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:

The registrar sends the change to the registry.
The registry publishes it in the TLD zone. For gTLD generic top-level domain A top-level domain not tied to a country, run under ICANN contracts. Full definition of gTLD under ICANN Internet Corporation for Assigned Names and Numbers The nonprofit that coordinates the global DNS and gTLD policy. Full definition of ICANN’s Registry Agreement The contract between ICANN and a gTLD registry operator. Full definition of 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 TLD A gTLD that existed before the 2012 New gTLD Program, such as .com. Full definition of legacy TLD such as .com, which have their own agreements, or ccTLD country code top-level domain A top-level domain for a country or territory, usually two letters long. Full definition of ccTLD.
Cached NS record Name Server record A DNS record that lists the name servers responsible for a domain. Full definition of NS record 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 The Spanish public body that manages the .es domain through its unit Dominios.es. Full definition of Red.es recommends a normal SOA record Start of Authority The record at the top of a DNS zone holding its serial number and timing settings. Full definition of SOA record 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 Non-Existent Domain The DNS answer meaning the requested name does not exist. Full definition of 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 Storing a 'does not exist' DNS answer for a set time. Full definition of 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 server A DNS server that gives the official answers for a domain or zone. Full definition of authoritative server 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

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.
Lower the TTLs in advance, as described above.
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.
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.
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.

DNS propagation