How Long Does DNS Propagation Actually Take?
The 48-hour figure is from an era that ended. Verisign now updates the .com zone every three minutes, and your record changes are limited only by the TTL you set. There is one genuine exception, and it is the one nobody mentions.
September 22, 20266 min readDNS · TTL · Troubleshooting
The short answer. DNS does not propagate. Nothing travels anywhere. Old answers sit in caches until they expire, and the expiry time is the TTL you set. Change an A record with a 300 second TTL and it is live everywhere in five minutes. The one genuine exception is nameserver changes, which are governed by a 48 hour TTL at the registry that you do not control.
Where the 48 hour myth came from
It was true once. In the early 2000s registrars commonly set default TTLs of 86,400 seconds, which is 24 hours, and Verisign updated the .com zone file roughly twice a day. Stack a 12 hour zone update on a 24 hour cache and you get up to 36 hours, which the industry rounded to "allow 48 hours".
Both halves of that have changed. Verisign now updates .com zones every three minutes. Modern registrars and DNS providers default to TTLs of 3,600 seconds or often 300.
The advice did not change with the infrastructure. Support documentation written in 2006 was copied forward, and "allow 24 to 72 hours" became something everyone says and almost nobody checks.
What actually determines the timing
Every DNS record carries a time to live: the number of seconds a resolver may cache the answer before asking again.
That number, and nothing else, sets how long a change takes to become universal.
| TTL | Maximum time until everyone sees the change |
|---|---|
| 300 seconds | 5 minutes |
| 3,600 seconds | 1 hour |
| 86,400 seconds | 24 hours |
There is no propagation, no distribution, no network of servers passing your change around. There are only caches holding the previous answer until they are allowed to ask again.
A resolver that never cached your record gets the new answer instantly. A resolver that cached it two minutes before you made the change holds the old one for TTL minus two minutes. That is the entire mechanism.
The genuine exception: nameserver changes
This is the part worth knowing, and the reason people still experience slow changes.
Your records live in your zone, and you control their TTLs. But the delegation records, the ones at the .com registry saying which nameservers are authoritative for your domain, carry a TTL set by the registry. For .com that is 172,800 seconds, which is 48 hours.
So:
- Changing an A record: governed by your TTL. Minutes.
- Changing nameservers: governed by the registry's 48 hour TTL. Genuinely up to two days for some resolvers.
The old advice is therefore accidentally correct for exactly one operation, which is probably why it survived. If you are moving DNS providers rather than editing a record, plan for two days of overlap.
How to make a change fast
Lower the TTL before you change anything. Set the record's TTL to 300 seconds. Wait for the old TTL to expire, so every cache has picked up the short one. Then make your change, which is now live within five minutes. Raise the TTL again afterwards.
This is the whole technique. It requires planning ahead by exactly one old-TTL period, which is why people who plan migrations never experience propagation delays and people who improvise always do.
Keep both systems running during a nameserver change. Because of the 48 hour delegation TTL, some visitors reach the old nameservers for up to two days. If the old zone still answers correctly, nobody notices anything. If you tear it down immediately, some users get failures for two days.
Do not lower TTLs permanently to very low values unless you need to. Short TTLs mean more queries, slightly slower lookups for uncached users, and less resilience if your DNS provider has trouble.
Why different people see different results
Your own machine caches. The operating system and often the browser hold answers independently of your resolver.
Your router caches, frequently ignoring TTLs entirely.
Public resolvers cache independently of each other. Checking via one public resolver tells you about that resolver, not the world.
Some resolvers ignore short TTLs and impose their own minimum, which is why a 60 second TTL does not reliably mean 60 seconds.
Negative answers cache too. If you query a name before creating it, the "does not exist" answer is cached according to the zone's SOA settings. Creating the record does not clear that cache. This is why a name can appear broken after you fixed it, and the fix is to wait rather than to keep changing things.
What to do while waiting
Test from more than one place. Checking only your own machine tells you almost nothing.
Flush your local cache if you need to see current reality from your own computer.
Do not keep changing the record. Each change restarts your own understanding of what is cached where and makes diagnosis harder.
Check the registry record to confirm the nameservers changed at all. Our checker shows the live delegation, so you can distinguish "the change has not taken effect yet" from "the change never happened". Those look identical from a browser and are completely different problems.
Common questions
How long does DNS propagation take?
For normal record changes, as long as the record's TTL, typically 5 minutes to an hour. For nameserver changes, up to 48 hours, because the delegation records at the registry carry a two-day TTL.
Why do people say 24 to 72 hours?
It was accurate around 2005, when default TTLs were 24 hours and registries updated zone files twice daily. Verisign now updates .com every three minutes and default TTLs are far shorter. The advice outlived the infrastructure.
Can I speed up DNS propagation?
Not after the fact. Lower the TTL in advance, wait for the old TTL to expire, then make the change. Once a resolver has cached an answer, nothing you do at your end removes it early.
Why can I see the change but my colleague cannot?
You are using different resolvers with different cache states, and your machines cache independently. This resolves itself when the relevant TTL expires.
Does flushing DNS help?
It clears your own machine's cache, so you see current reality sooner. It has no effect on anyone else, and no effect on resolvers between you and the authoritative servers.
Why does my domain still not work after I fixed the record?
Possibly negative caching. If a resolver cached a "does not exist" answer before the record existed, it holds that for a period set by the zone's SOA record, regardless of the new record being correct.
Put the research to work.
Check your shortlist across the extensions that matter, then save the strongest names to a project.
Check a domain