- Why does a domain change take hours to work everywhere?
- Here is what DNS propagation and TTL actually mean, and how to plan around the wait.
One of the most confusing moments for a first-time domain owner is making a DNS change and finding it works on one device but not another, or not at all for a few hours. This is DNS propagation — a normal, expected part of how the internet works, not a bug.
What Propagation Actually Is
DNS information is cached at many layers across the internet — your internet service provider, public DNS resolvers, individual devices — to avoid every single request hitting the authoritative server directly. When you change a DNS record, those cached copies do not update instantly; they expire and refresh gradually.
What TTL (Time To Live) Controls
TTL is a value attached to each DNS record specifying how long it should be cached before being re-checked, usually measured in seconds. A TTL of 3600 means caches may hold that record for up to one hour before refreshing it. Lower TTL means faster propagation of future changes, at the cost of slightly more DNS lookup traffic.
Realistic Propagation Timeframes
- With a low TTL set in advance: often complete within minutes to a couple of hours.
- With a default or high TTL: commonly 4-24 hours, occasionally up to 48 hours for full global propagation.
- Nameserver changes (switching your domain's entire DNS provider) typically take longer than individual record changes within an existing provider.
How to Minimize Wait Time Before a Planned Change
- Lower the TTL on the record you plan to change, 24-48 hours before the actual change.
- Make the change once the shortened TTL window has had time to propagate.
- Optionally raise the TTL back to a normal value once the change is confirmed stable.
A Practical Migration Timeline Using This Technique
For a real hosting migration where downtime must be minimized, the sequence looks like this: two days before the move, lower the A record's TTL from its default (often 3600 or 86400 seconds) down to 300 seconds (5 minutes), and wait the original TTL's duration to ensure that shortened value has itself fully propagated. On migration day, update the A record to point at the new server; because the TTL is now short, most visitors' caches refresh within minutes rather than hours. Once the new server is confirmed stable, the TTL can be raised back to a normal value to reduce ongoing DNS query overhead.
Checking Propagation Status
Free online DNS propagation checker tools show the current record value as seen from various global locations, letting you monitor how the change is spreading in near real time rather than guessing.
Frequently Asked Questions
Why does the change work on my phone but not my laptop?
Different devices and networks query different DNS resolvers, each with independent caching — this explains inconsistent visibility during the propagation window.
Can I force propagation to happen faster?
You cannot force other networks' caches to clear, but lowering TTL well in advance of a planned change is the standard way to minimize the eventual wait.
Is there a downside to always keeping TTL very low?
A permanently very low TTL means every visitor's device re-queries DNS more often, adding a small amount of extra load and lookup latency with no benefit unless you are actively planning changes — a moderate default (an hour or so) is more sensible for records that rarely change.
Planning a DNS change? See our domain management services or ask our team for guidance.