What Does DNS Propagation Time Actually Mean?
The phrase "DNS propagation" is a little misleading: when a DNS record is changed, that information does not "propagate" across the internet in a single wave. Instead, thousands of independent DNS resolvers around the world — your ISP's resolver, Google's 8.8.8.8, Cloudflare's 1.1.1.1, your operating system's cache, your browser's cache — hold the old record in cache for a period each one determines, and when that period expires they ask the authoritative nameserver again and pick up the new value.
That is why there is no single answer to the question of when a DNS change will be "fully propagated"; every resolver updates at a different moment according to its own cache duration. The instant you change the record, some users may see the new value immediately (if their resolver never cached the record at all), while others carry on seeing the old value until the old TTL expires.
What Is TTL and How Is It Set?
TTL (Time-To-Live) is the value stating how many seconds a DNS record will be kept in cache by resolvers, and it is defined per record in the DNS zone where the domain is managed. If you give an A record a TTL of 3600 seconds (1 hour), for example, a resolver that queries that record keeps the result in its own cache for an hour and answers identical queries during that period straight from cache, without going back to the authoritative nameserver.
A low TTL (300 seconds, say) lets changes propagate relatively quickly but increases the number of queries reaching the authoritative nameserver. A high TTL (86400 seconds / 1 day) reduces that query load but means the old record takes longer to clear from caches when a change is made. Choosing a TTL is a balance between the two, and it can be adjusted temporarily ahead of a planned change.
Why Do Different Users See the Same Change at Different Times?
A DNS query can pass through several independent cache layers on the way from the user to the authoritative nameserver: the browser's own DNS cache, the operating system's resolver cache, the router on the local network, and the ISP's recursive resolver or whichever public resolver is in use. Each of these layers updates at a different time depending on when it cached the record, which is why two different users can still see different IP addresses for the same domain at the same moment.
| Layer | Who caches the record | Typical effect |
|---|---|---|
| Browser | May keep a DNS cache of its own, separate from the operating system | The old record can be seen until the tab/browser is restarted |
| Operating system | Local resolver cache | Returns the old record for the duration of the TTL |
| ISP / recursive resolver | A shared cache for every user on that network | For the duration of the TTL, affects all of that ISP's users |
| Public resolver (8.8.8.8, 1.1.1.1 and so on) | A distributed cache across their own geographic locations | Depends on TTL; sometimes applies a minimum of its own |
Does TTL Vary by Record Type?
In a DNS zone, every record line (A, AAAA, CNAME, MX, TXT and so on) can have its own TTL value; TTL is defined per record, not for the whole zone. So a domain's A record may have a TTL of 3600 seconds while the same domain's MX record is defined with a different TTL. When planning a change, it is enough to look at the TTL of the record in question; it does not affect the other record types.
Practical Advice Before a Planned Change
- 24 to 48 hours before a major change (a server migration, an IP address change), lower the TTL of the record in question to a low level (300 seconds, for example); the old record then clears from resolver caches faster.
- After lowering the TTL, wait for the whole of the old (higher) TTL period to pass before making the actual change; otherwise the lowering itself may still be sitting in cache for the length of the old TTL.
- Do not shut down the old server immediately until the new record has fully propagated; even with a low TTL, some resolvers may hold the old value longer.
- To confirm that the change really has been applied on the authoritative nameserver, use a query tool that bypasses resolver caches and asks the nameserver directly; that confirms the record is correct on the server side regardless of what users are seeing.
- Once the change is complete and verified, do not forget to raise the TTL back to its normal level (3600 seconds or higher, for example); a permanently low TTL needlessly increases the query load on the authoritative nameserver.
Common Mistakes
- Assuming a DNS change will take effect instantly and globally: in reality every resolver updates on its own cache schedule, and there is no single "moment of propagation".
- Not lowering the TTL in advance of a planned migration: a change made while the TTL is high can leave the old record in caches for hours or even days.
- Confusing a DNS record change (A, CNAME) with a nameserver (NS record) change: changing a domain's nameservers depends on the NS record cache at the root and TLD servers, independently of the record TTL; the TTL of those upper-level records is generally not under the domain owner's control, so nameserver changes can take longer than ordinary record changes.
- Thinking that keeping the TTL as low as possible is always "safer": a permanently very low TTL creates unnecessary query load in ordinary use and can clash with the minimum TTL policies some resolvers apply.
To get a rough estimate of when a change will be "fully propagated", you can use the tool below, which converts a record's TTL value into a readable duration and calculates the likely worst case.