Apprendre
DNS Propagation: Why Changes Take Time and How to Check
Nothing propagates. A DNS change is instant at the authoritative server; what you are waiting for is every cache in the world to expire the old answer.
Lancez un audit DomainLens frais et utilisez le rapport comme liste de priorités.
Propagation is a misleading word
The mental model most people carry is that a DNS change spreads outward across the internet, arriving at different places at different times. That is not what happens. The change is complete the moment your authoritative nameserver accepts it.
What varies is caching. Every resolver that already asked about your name holds the previous answer until its TTL expires. Until then it will keep serving that answer without asking again — so the delay you observe is not distance, it is the remaining lifetime of cached copies.
How TTL controls the wait
TTL is a number of seconds attached to every record, telling resolvers how long they may reuse the answer. It is the single lever that decides how long a change takes to become universal.
- Lower the TTL to 300 at least one full old-TTL period before a migration, so every cache has re-fetched with the short value.
- Make the change, verify, then raise the TTL again — permanently short TTLs mean more queries and a harder failure if your DNS provider has an outage.
- Negative answers cache too. If a name did not exist, the SOA record's minimum field decides how long "does not exist" is remembered.
| TTL | Worst-case wait | Suits |
|---|---|---|
| 300 (5 min) | 5 minutes | The window around a planned migration |
| 3600 (1 hour) | 1 hour | Records you expect to change occasionally |
| 86400 (1 day) | 24 hours | Stable records; fewer queries, lower cost |
| 604800 (1 week) | 7 days | Records that essentially never change |
How to check what resolvers are answering
There is no single global truth to query. The useful technique is to ask several resolvers directly and compare, including the authoritative server, which always holds the current value.
- If the authoritative server has the new value and a public resolver has the old one, the change is fine and you are simply waiting on that cache.
- If the authoritative server still has the old value, the change was never saved — stop waiting and check your provider.
- The TTL shown by a caching resolver counts down, so a value well below your configured TTL tells you the cache is close to expiring.
# What your default resolver currently answers
dig example.com A +short
# Ask specific public resolvers
dig @8.8.8.8 example.com A +short # Google
dig @1.1.1.1 example.com A +short # Cloudflare
# Ask the authoritative server — never cached
dig @ns1.provider.net example.com A +short
# See the remaining TTL on a cached answer
dig example.com A | grep -A1 'ANSWER SECTION'
# Find the authoritative nameservers first
dig example.com NS +shortPlanning a change that does not lose traffic
Keeping the old server alive through the transition is the step most often skipped and the one that prevents the outage. For what each record does before you change it, see DNS record types , and for a whole-site move see the migration checklist .
- 1At least one old-TTL period before the change, lower the TTL on the records you will edit to 300.
- 2Wait out the old TTL fully, so every cache is now holding the short-lived version.
- 3Bring the new destination up and confirm it serves correctly before repointing anything.
- 4Make the DNS change, then verify against the authoritative server first and public resolvers second.
- 5Keep the old destination serving for at least 24 hours — some resolvers ignore TTLs and hold answers longer than they should.
- 6Once traffic to the old destination stops, raise the TTL back to its normal value.
How DomainLens contributes
The DNS checker queries live rather than from a cache, so it shows what a resolver asking right now would receive — useful for confirming a change landed before you start investigating why visitors still see the old site.
- How long does DNS propagation take?
- At most the TTL of the record you changed, counted from the last time each resolver fetched it. With a 300-second TTL that is five minutes; with a one-day TTL it is up to 24 hours.
- Can I force propagation?
- Not for other people's resolvers. You can flush your own cache and your operating system's, but the caches your visitors use expire on their own schedule.
- Why do different checkers show different results?
- Because they query different resolvers, each holding a copy with its own remaining TTL. Disagreement during a change window is expected, not a fault.
- Does changing DNS hurt rankings?
- Not if the site keeps serving. Rankings suffer when the change causes downtime or when the new destination responds differently — not from the DNS edit itself.