DNS Propagation and TTL: How Long Domain Changes Really Take
“DNS propagation” is often described as though one global database slowly updates. In reality, authoritative servers publish the current answer and many recursive resolvers cache previous answers for a defined period. Understanding that model makes changes easier to plan and diagnose.
What TTL means
TTL—time to live—is the number of seconds a DNS answer may normally remain cached. A record with TTL 3600 can be reused for up to an hour after a resolver receives it. Lowering a TTL affects future answers; it does not recall copies already cached under the old value.
Negative answers can also be cached. If someone queried a new subdomain before it existed, their resolver may retain “not found” for the zone’s negative-cache period.
Authoritative versus recursive DNS
Authoritative nameservers contain the zone’s source answers. Recursive resolvers—often run by an ISP, company or public DNS service—look up those answers and cache them for users. Troubleshooting should begin at the authoritative layer. If it is wrong, waiting will not repair it.
How long will a DNS change take?
There is no honest universal promise. The previous TTL, resolver behaviour, delegation caching, local caches and the type of change all matter. A record edit with a deliberately lowered TTL can converge quickly. A nameserver or DNSSEC change has parent-zone and security dependencies and may take longer to appear consistently.
Do not use “up to 48 hours” as a substitute for diagnosis. Check which answer is stale, where it came from and when its cache can expire.
Plan a low-risk cutover
- Inventory the current zone and service dependencies.
- Several TTL periods before the change, lower the TTLs of records that will move.
- Build and test the destination website, mail service or DNS zone.
- At the change window, update only the planned records.
- Query authoritative servers directly.
- Check representative public resolvers and real user paths.
- Keep the old destination operating through the cache window.
- Raise TTLs again after stability is proven.
Record change versus nameserver change
Changing an A record leaves delegation in place and changes one answer. Changing nameservers moves authority for the entire zone. For a new hosting server, a record change is often enough and carries less risk. If delegation must move, create and verify the complete new zone first; see the nameserver change guide.
How to check the authoritative answer
Find the delegated NS records, then query each authoritative server for the changed name and record type. They should agree. Check the expected value, TTL and response status. Tools such as dig can target a server directly; web checkers can help but should not replace authoritative inspection.
If one authoritative server returns old data, the provider has an internal synchronisation problem. If all authoritative servers are correct but one recursive resolver is old, wait for that cache or use its documented cache-flush mechanism for testing.
Common failure patterns
The website works on mobile but not office Wi-Fi
The two networks may use different recursive resolvers. Compare their answers and check corporate proxy or local DNS caches.
www works but the bare domain does not
They are separate names. Inspect both records and hosting configuration.
The website works but email stopped
The zone move omitted MX, DKIM, SPF or DMARC. Restore the exact mail records and test externally.
Everything returns SERVFAIL
Investigate DNSSEC first, especially after nameserver changes. A parent DS record that no longer matches the zone can invalidate answers.
Some users receive certificate warnings
Old DNS may reach a server without the correct certificate, or the new certificate may not cover every hostname. Keep both endpoints valid during transition.
TTL is a reliability trade-off
Very low TTLs increase query volume and do not guarantee instantaneous updates. High TTLs improve cache efficiency but slow emergency changes. Use values appropriate to the service, reduce them deliberately before planned changes and restore normal values later.
Website migration and search
When URLs remain the same and only hosting changes, Google recommends testing the new host, lowering DNS TTL where useful, switching DNS and monitoring the old and new servers. Avoid bundling a redesign, URL migration, DNS provider move and email move into one event.
The website migration guide provides a complete sequence. Hoster’s hosting plans can be reviewed before moving, and support can help assess a critical cutover.
A concise troubleshooting sequence
- Confirm the exact hostname and record type.
- Check current delegation at the parent.
- Query every authoritative server.
- Validate DNSSEC.
- Compare recursive resolver answers and remaining TTL.
- Flush only local/test caches where appropriate.
- Verify web server, certificate and mail configuration separately.
- Document findings before making another change.