DNS changes take time because resolvers all over the world cache your old records and keep serving them until each record's TTL expires. Your DNS host publishes the new value to your authoritative nameservers within seconds. The wait you experience after that is caching, and you control most of it with the TTL you set.
How a DNS change actually spreads
When you edit a record at your DNS provider, the new value lands on your authoritative nameservers almost immediately. Query those servers directly and you get the fresh answer right away.
Almost nobody queries your authoritative servers directly. Devices ask a recursive resolver instead, usually one run by an ISP or a public service like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. That resolver fetched your record earlier, stored a copy, and keeps answering from cache until the TTL runs out. Only then does it return to your authoritative servers for a fresh answer.
Propagation is a misleading word. Nobody pushes your new record out to the internet. Cached copies expire at different times in different places, and each resolver picks up the new value on its own schedule. That is the whole mechanism.
What TTL controls
TTL stands for time to live. It is a number of seconds attached to every DNS record, and it tells resolvers how long they may keep a cached answer. A TTL of 3600 lets a resolver serve the stored record for up to an hour before it must ask your nameservers again. You set it per record at your DNS host, and different records in the same zone can carry different TTLs.
Treat TTL as your worst case wait. A resolver that cached your A record ten seconds before your change serves the stale value for nearly the full TTL. A resolver that cached it 59 minutes ago refreshes within a minute. Users sit behind thousands of resolvers at different points in that window, which is why you see the new site while a colleague on another network still sees the old one.
Sensible TTL values
- 300 seconds: use this for records you plan to change soon, such as an A record during a server migration.
- 3600 seconds: a safe default for most records on a stable site.
- 86400 seconds: fine for records that rarely move, like MX or NS entries.
Short TTLs mean faster changes and more queries against your nameservers. The extra query load is trivial for a typical site, so lean toward shorter TTLs on records you touch often.
Lower the TTL before you change the record
You can make a planned change land in minutes instead of hours. The order of operations matters.
- A day before the change, drop the record's TTL to 300 seconds. Leave the record's value alone.
- Wait out the old TTL. If the record carried a 24 hour TTL, wait 24 hours so every long lived cached copy expires.
- Change the record's value. Resolvers now pick up the new value within five minutes.
- Raise the TTL back to its normal setting once traffic looks healthy on the new value.
Why changes sometimes outlive their TTL
TTL sets the expected wait, but a few other caches and quirks can stretch it.
- Your own machine caches DNS. Browsers and operating systems keep separate DNS caches. Flush them before you blame the internet. On Windows, run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder.
- Some resolvers stretch TTLs. A handful of ISP resolvers enforce minimum cache times and hold records longer than you asked. You cannot fix this, only wait.
- Negative caching. If a name was queried before the record existed, resolvers cache the does not exist answer too. The minimum field on your zone's SOA record controls how long.
- Nameserver changes move slower. Switching DNS providers updates NS records at the registry, and parent zones often assign those records TTLs of 48 hours. Budget two days for a full nameserver move.
How to check propagation
Ask your authoritative server first
Confirm the change exists at the source before you test anything else. Run dig example.com A @ns1.valladns.com +short against one of your assigned nameservers. If the answer is wrong here, the problem is your zone file, not propagation.
Compare public resolvers
Query a few big resolvers and compare answers. Run dig example.com A @8.8.8.8 +short, then repeat with 1.1.1.1 and 9.9.9.9. On Windows, nslookup example.com 8.8.8.8 does the same job. Matching answers across resolvers mean the change has landed for most users. Disagreement is normal mid propagation, since each resolver's cache expires on its own clock.
Use a global checker
Tools like whatsmydns.net and dnschecker.org query dozens of resolvers around the world and map the results. Green checks everywhere mean you are done. A mix of old and new values means caches are still expiring, so note the record's TTL and check back after that many seconds.
Watch the TTL count down
Run the same dig query against one resolver twice, a minute apart. The number in the second column of the answer is the seconds left in that resolver's cache, and it drops between runs. When it hits zero, the resolver refetches, and you know exactly when the stale copy dies.
Propagation comes down to cache expiry, governed by a TTL you set. Keep TTLs short on records you expect to change, lower them a day before planned moves, and verify with dig or a global checker instead of refreshing your browser and guessing.