DNS propagation is one of the most misunderstood concepts in web infrastructure. It’s not a single event — it’s a gradual process that happens independently on thousands of DNS resolvers around the world.
How DNS Caching Works
When a resolver (like Google’s 8.8.8.8 or your ISP’s DNS) looks up a record, it caches the result for the duration of the TTL (Time to Live) value in that record.
Resolver gets: example.com A 93.184.216.34 TTL=3600
Resolver caches this for 3600 seconds (1 hour)
Any query for example.com during this hour → returns cached 93.184.216.34
After 3600 seconds → resolver fetches fresh data from authoritative nameserverWhen you change a DNS record, you’re changing it at your authoritative nameserver. But every resolver that has the old value cached will continue serving it until their cache expires.
The TTL: Your Primary Control
TTL determines how long your record is cached. This is the main lever you control:
| TTL Value | Cache Duration | Use When |
|---|---|---|
| 60s | 1 minute | During active migrations, testing |
| 300s | 5 minutes | Pre-migration staging |
| 3600s | 1 hour | Normal operations |
| 86400s | 24 hours | Stable infrastructure, reduces resolver load |
Best practice for planned DNS changes:
- 24 hours before: Lower TTL to 300 seconds
- Wait the old TTL for caches to expire (so resolvers pick up the new short TTL)
- Make your change — now it propagates in 5 minutes
- Verify using multiple resolvers (DomainScan checks from multiple locations)
- After confirmation: raise TTL back to 3600
If you didn’t lower TTL beforehand, you’re stuck waiting for the old TTL duration.
What “Propagation” Actually Is
Propagation is simply the time it takes for all cached copies of the old record to expire and resolvers to fetch the new value. There’s no “push” mechanism — DNS is a pull system.
Your DNS provider (authoritative) — change is instant here
↓ (resolvers pull on cache expiry, not push)
Google 8.8.8.8 — pulls after TTL expires
Cloudflare 1.1.1.1 — pulls after TTL expires (may differ from Google)
Your ISP resolver — pulls after TTL expires
User's browser cache — may cache separately from resolver (short TTL)Each resolver has its own independent cache. Propagation isn’t complete until all resolvers’ caches expire.
Checking Propagation Status
DomainScan’s DNS lookup checks your record from multiple locations simultaneously:
- North America (US East, US West)
- Europe (Frankfurt, London)
- Asia Pacific (Singapore, Tokyo)
- South America (São Paulo)
If you see the new value in most locations but not all, propagation is still in progress. If you see the old value everywhere, your change may not have saved correctly — verify at your DNS provider’s dashboard.
Local DNS Cache vs. Resolver Cache
Your computer also caches DNS results independently of your ISP resolver. Even if the resolver has the new value, your computer may serve from its local cache.
Clear your local DNS cache:
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux (systemd-resolved)
sudo systemd-resolve --flush-cachesAfter flushing, open a new browser tab (Chrome has its own DNS cache — you may also need chrome://net-internals/#dns → Clear host cache).
Browser DNS Cache
Chrome, Edge, and Firefox maintain their own DNS caches, separate from the OS:
- Chrome/Edge: Navigate to
chrome://net-internals/#dns→ Click “Clear host cache” - Firefox: About:config →
network.dnsCacheExpiration = 0(temporarily), then back to 60
Common Propagation Scenarios
Migrating to a New Host
Lower TTL → wait → update A record → verify with DomainScan from multiple regions → once confirmed everywhere, raise TTL.
Don’t cancel your old hosting until propagation is complete — users still hitting the old IP need the old server to be up.
Switching Email Providers
MX record changes are particularly important to verify. Email sent during the transition may be queued at sending servers until MX resolves. Allow 24-48 hours before decommissioning the old mail server.
Nameserver Changes
NS record changes propagate through the registry (e.g., Verisign for .com) which has its own update schedule. These can genuinely take 24-48 hours. TTL on NS records is set by the registry, not you.
When Propagation Seems Stuck
If DomainScan shows the old value everywhere after you’ve waited longer than the TTL:
- Verify at source: Use your DNS provider’s dashboard to confirm the record is saved correctly
- Check the TTL: Query
dig +nocmd example.com A +answer— the TTL field shows remaining cache time - Query authoritative directly:
dig A example.com @ns1.yourprovider.com— bypasses caches, hits authoritative server directly - Check for negative caching: If the record didn’t exist and returned NXDOMAIN, that negative response is also cached (for the SOA minimum TTL)
Common Questions
How long does DNS propagation actually take?
The honest answer: it depends on the TTL of the old record. If the record had a TTL of 3600 (1 hour), resolvers cache it for up to 1 hour after you make a change. After that, they fetch the new value. Most of the world sees changes within 1-4 hours for typical TTLs. 'Up to 48 hours' is often cited but is rarely relevant today — it applied to old root zone update schedules, not typical record changes.
I can see the new value but my colleague in another country still sees the old one. Why?
Different users use different DNS resolvers (ISPs, Google, Cloudflare) each with their own cache. If your resolver's cache expired and fetched the new value, you see it. Your colleague's resolver may still have the old value cached. Wait for their resolver's cache to expire. In the meantime, they can clear their local DNS cache or use a different resolver temporarily.
Can I force DNS propagation to be instant?
You can't force remote resolvers to flush their caches. The only thing you control is TTL: set it low (60-300 seconds) before making a change, and propagation will be much faster. After the change is confirmed, raise TTL back to 3600 or higher. If you didn't lower TTL in advance, you'll wait for the old TTL to expire.