DNS changes don't appear everywhere at once because DNS answers get cached at every stop along the lookup chain, and each cache holds its answer until its own timer runs out. There's no global "propagation" process pushing your update outward. There's only a patchwork of caches expiring on their own schedules. The main lever you control is TTL (time to live), and the fix for slow changes is almost always to lower it before you make the change, not after.
What TTL actually controls
Every DNS record has a TTL, a number in seconds that tells resolvers how long they're allowed to cache the answer. A resolver that looked up your A record with a 3600 TTL will keep serving that cached answer for up to an hour, even if you update the record five minutes later. It has no way of knowing you changed anything. It serves what it has until the clock runs out.
This is why a low TTL (300 seconds, or five minutes) makes changes visible fast, while a high TTL (86400 seconds, a full day) can leave stale answers in circulation long after you've updated the record. If you're planning a change, edit the TTL down a day or two ahead of time, wait for the old TTL to fully expire, then make the real change. That way the cache that picks up your update is already working off the short TTL.
Records for hosting are edited in Services → your hosting → DNS Zone Editor. Note that the DNS section under a domain only controls nameservers, not individual records. See what DNS is and how the internet finds your site for the full resolution chain.
Where caching actually happens
A single lookup gets cached at several independent layers, each with its own timer:
- The browser caches DNS answers separately from the OS, sometimes for the full TTL, sometimes on its own internal timer.
- The operating system keeps a resolver cache (
ipconfig /flushdnson Windows,sudo dscacheutil -flushcacheon macOS) that outlives individual browser tabs. - The recursive resolver, usually run by the visitor's ISP or a public resolver like 1.1.1.1 or 8.8.8.8, caches for the TTL and serves every device behind it from that one cached answer.
- Downstream secondary resolvers and CDNs can hold their own cached copies, occasionally past the TTL if they're misconfigured or slow to revalidate.
That's why two people on different networks can see different results for the same domain at the same moment. One's resolver cached the old answer an hour ago and still has 40 minutes left on it; the other's resolver never cached it and just did a fresh lookup.
Nameserver changes take longer than record changes
Changing an individual record (an A or CNAME, for example) only has to wait out that record's own TTL. Changing nameservers is slower, because it isn't governed by a TTL you set. It's governed by how long the registry and every resolver in the chain cache the delegation itself, which can take noticeably longer than a single record change. This is normal, not a sign anything is broken, and it applies whether you're pointing a domain at new nameservers or completing a registrar transfer. See domain locks explained if a transfer also looks stuck. A lock, not propagation, is usually the real blocker there.
Checking whether a change has actually landed
Don't trust your own browser as a test. It's the most likely thing to be showing you a cached answer. Instead:
- Query a public resolver directly instead of relying on your device's default:
dig yourdomain.com A @1.1.1.1
- Check a few different public resolvers (1.1.1.1, 8.8.8.8, and your own ISP's) to see whether the new answer has reached all of them yet.
- Use a DNS propagation checker site that queries resolvers in multiple regions at once, so you're not stuck testing one network at a time.
- If a query still returns the old value everywhere, check that the TTL you expected is actually the TTL set on the record. A record edited with a leftover 24-hour TTL will take a full day to clear, no matter how urgent the change feels.
Why some changes never seem to fully "finish"
A record with a very long TTL that gets edited rarely, an old cached answer sitting on a resolver that only refreshes under specific conditions, or a stale answer held by a secondary DNS provider can all make a change look incomplete days later even though your zone is correct. In almost every case, the record itself is right and the delay is an uncleared cache somewhere in the chain waiting for its TTL to expire. If you're not sure whether the record is wrong versus just not-yet-cached-through, query it straight from an external resolver as shown above. That tells you what's actually published, independent of any cache.
When to contact support
If a record has been showing the old value against a public resolver like 1.1.1.1 for well past its TTL, or a nameserver change hasn't resolved anywhere after several days, open a ticket from Support → New ticket in the portal. It's a real person, not a bot, and they can check the zone directly rather than guessing from the outside.