What is DNS propagation?
DNS propagation is the time it takes for a DNS change to be seen everywhere. Nothing is pushed: recursive resolvers keep cached answers until the record's TTL (time to live) expires, then ask again. The old TTL sets the worst case: a record cached with a 3600-second TTL can be served for an hour after you change it.
Why DNS propagation matters
Migrations, failovers and email changes all depend on DNS. If you move a site to a new server and switch the A record, some users keep reaching the old server until their resolver's cache expires; if the old server is already off, they see an outage.
Knowing that propagation is cache expiry, not a slow broadcast, turns a vague "24 to 48 hours" into something you can plan: lower the TTL first, wait, then make the change.
How to measure DNS propagation
worst-case staleness after a change ≈ TTL of the old record, as cached planned change: lower the TTL → wait one old TTL → change the record → worst case is the new, short TTL
Worked example
Your A record has a TTL of 3600 seconds and you plan to move the site to a new server. You lower the TTL to 300 seconds first.
- Resolvers that cached the record just before you lowered the TTL may keep it for 3600 s, so wait at least 1 hour before switching.
- After that hour every cached copy carries the 300 s TTL.
- Now change the A record: the worst case is 300 s, or 5 minutes, instead of an hour.
Result: Keep the old server answering until its traffic stops, then raise the TTL again. The whole move costs at most 5 minutes of mixed traffic and no outage.
Common mistakes
- Lowering the TTL at the moment of the change. The old, long TTL is already in caches; lowering it only helps if you do it one old-TTL period in advance.
- Forgetting negative caching. If a name did not exist when a resolver asked, that NXDOMAIN answer is cached too, for a time set by the zone's SOA record. Create new names before you need them.
- Trusting one resolver. Your laptop may show the new record while a large ISP still serves the old one. Query several public resolvers.
- Treating a nameserver change like a record change. A nameserver change also depends on the delegation records in the parent zone, whose TTL is often one to two days and not yours to lower.
How Vigil handles DNS propagation
- Vigil's Domain & DNS monitor snapshots A, AAAA, MX, NS, TXT and CNAME records and alerts on any change with the old and new values, so an unexpected edit is noticed even before it has spread.
- The free DNS and email-auth checker shows the records and the SPF and DMARC setup for any domain without an account.
- During a migration, an uptime monitor on the new server and one on the old one show when traffic has moved and when it is safe to switch the old one off.
DNS propagation: frequently asked questions
Does DNS propagation really take 48 hours?
Only if TTLs are that long. Most record changes are visible everywhere within the old record's TTL. Nameserver changes can take longer because the parent zone's delegation records often have a TTL of one to two days.
Can I force propagation?
Nobody can clear other people's resolver caches. Some public resolvers offer a form to purge their own cache, but the real tool is planning: lower the TTL in advance.
How do I check propagation?
Query several resolvers directly, for example dig @1.1.1.1 example.com A and dig @8.8.8.8 example.com A, and compare the answers and the remaining TTL each one shows.