DNS propagation is the period after a change to DNS data during which different resolvers on the internet return different answers, until every cached copy of the old record has expired and been replaced. Despite the name, nothing is actively pushed across the internet: the delay comes almost entirely from caching governed by time to live (TTL) values, plus the time authoritative servers need to synchronize.
In DNS operations, the term covers changes to ordinary records such as A, AAAA, CNAME or MX, changes of nameserver delegation at the registry, and the activation of new zones. Understanding the mechanism turns the vague advice to wait up to 48 hours into a predictable, plannable process.
Why DNS propagation happens
DNS is a distributed, cached database. When a user visits a domain, a recursive resolver, typically operated by an ISP or a public DNS service, asks the authoritative nameservers for the answer and stores it for the number of seconds set in the record’s TTL. Until that time runs out, the resolver answers from its cache and never asks the authoritative server again.
When an administrator changes a record, the authoritative servers serve the new value immediately, but every resolver that cached the old value keeps returning it until its own copy expires. Because thousands of resolvers cached the record at different moments, they switch to the new value at different times, which creates the uneven picture called propagation.
Further caching layers add to the effect: operating system resolvers, browsers, home routers and application runtimes can all hold their own copies. Some respect the TTL; others apply their own minimum or maximum, which is why a single machine can lag behind its resolver.
Factors that determine propagation time
Propagation time is bounded mainly by TTL values, but which TTL applies depends on the kind of change. The table summarizes the main factors and their usual ranges.
| Factor | Typical range | Effect on propagation |
|---|---|---|
| Record TTL | 60 s to 86,400 s | Upper bound for record changes in resolver caches |
| Negative caching TTL | Minimum of SOA minimum and SOA TTL, often 300 to 3,600 s | How long a missing record stays missing |
| Delegation NS TTL at the TLD | Often 3,600 to 172,800 s | Governs nameserver changes |
| Zone transfer to secondaries | Seconds with NOTIFY, up to the SOA refresh interval without it | Delay before all authoritative servers agree |
| Registry publication | Minutes for many TLDs | Time until a new delegation is visible |
| Local and browser caches | Seconds to minutes, sometimes longer | Individual devices lag behind |
For an ordinary record change, the realistic worst case is roughly the old TTL plus zone synchronization time. For a nameserver change, the TTL of the NS records in the parent zone dominates, and those values are frequently one or two days, which is the origin of the familiar 48-hour warning.
Types of DNS changes and their behavior
Not every change propagates the same way. The decisive question is which cached data stands between the user and the new answer.
| Change | Cached data that delays it | Typical planning approach |
|---|---|---|
| Editing an A or AAAA record | The old record in resolvers | Lower TTL in advance, then change |
| Adding a new record | Negative cache entries, if queried before | Avoid querying names before creation |
| Changing MX records | Old MX records in mail servers’ resolvers | Keep the old mail server accepting mail |
| Switching DNS provider | NS records at the TLD and in resolvers | Serve identical zones at both providers |
| Enabling or changing DNSSEC | DS records at the parent, DNSKEY caches | Follow a key rollover timeline strictly |
Negative caching is an often overlooked trap. If a monitoring tool or a user queries a name before the record exists, resolvers cache the NXDOMAIN or empty answer for the negative TTL derived from the SOA record, and the new record appears missing even after it is published.
Planning a DNS change with minimal disruption
Propagation cannot be accelerated after the fact, but it can be shortened in advance. The standard technique is to lower the TTL before the change, wait for the old, longer TTL to expire, make the change, and then raise the TTL again.
- At least one old TTL period ahead, reduce the record TTL to a short value such as 300 seconds.
- Keep the old target running so that users still directed to it are served correctly.
- Make the change at the authoritative provider and confirm that all authoritative servers return it.
- Monitor traffic on both targets until the old one receives no meaningful requests.
- Restore a longer TTL, such as 3,600 seconds or more, to reduce query load and improve resilience.
Very short TTLs have costs: more queries to authoritative servers, slightly slower lookups for users and less protection if the DNS provider has an outage. Short TTLs are best kept for migration windows and failover records, not as a permanent default.
Checking progress and common misconceptions
The reliable way to check a change is to query the authoritative nameservers directly, for example with dig @ns1.example.net www.example.com, which shows the published truth. Querying several public resolvers then shows how far caches have refreshed, and the remaining TTL in each answer reveals how long an old value will survive.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Some users see the old site | Resolvers still hold the cached record | Wait for TTL expiry, keep old server active |
| Only one computer sees the old site | Local operating system or browser cache | Flush local DNS cache, restart browser |
| New subdomain fails for hours | Negative caching of an earlier lookup | Wait for negative TTL, avoid early queries |
| Answers alternate between values | Authoritative servers out of sync | Check zone serial numbers on every server |
| Domain fails after provider switch | New zone incomplete or DNSSEC mismatch | Copy all records, update DS records correctly |
- Propagation is not a push process; no server sends updates to resolvers.
- The 48-hour figure is not a rule; it reflects long NS TTLs, while record changes often complete within the old TTL.
- Online propagation checkers show a sample, not the state of every resolver worldwide.
Explained without jargon
Imagine a company changes its phone number, and many people have the old number written on sticky notes. Each note says how long it is valid. Until a note expires, its owner keeps calling the old number, even though the official directory already shows the new one.
DNS works the same way. Servers around the world keep temporary copies of addresses to answer faster, and each copy has an expiry time. After a change, people gradually reach the new address as their copies run out. Setting short expiry times before a planned move makes the switch quick and smooth.
A typical use case
An online learning platform plans to move its website to a new hosting provider on a Saturday morning. Its www record has a TTL of 86,400 seconds, which would let some users reach the old server for up to a day after the change.
On Thursday, the operations team lowers the TTL to 300 seconds. By Saturday, all cached copies with the long TTL have expired. The team switches the A record to the new server’s address, confirms the answer on both authoritative nameservers and watches traffic. Within about ten minutes, almost all requests reach the new host, while the old server, kept online with a read-only copy, serves the few late visitors. On Monday the TTL returns to 3,600 seconds and the old server is retired, with no visible downtime for students.