Why a DNS change is not instant

You changed a record. The portal says it published. A colleague sees the new site; you still see the old one. Nothing is broken, and there is nothing to fix.

Our side is finished in seconds

A saved record reaches every one of our nameservers within seconds, and the portal shows you when each one has it. From that moment, anyone who asks us gets the new answer.

The delay is not on our side. It is in everything between us and the person looking.

Nobody asks us twice

If every lookup travelled all the way to the authoritative nameservers, DNS would collapse under its own weight. So every answer carries a TTL — a time to live, in seconds — and everyone who receives it may remember it for that long.

Your browser remembers it. Your operating system remembers it. Your internet provider's resolver remembers it, on behalf of everybody who uses that resolver.

⚠️ A resolver that asked an hour ago is still confidently handing out the old answer, and will keep doing so until its copy expires. It is not stale from its point of view — it is doing exactly what the TTL told it to.

The TTL is a request, not a rule

This is the part that surprises people, and it is the reason the honest answer is "up to 48 hours" rather than "the TTL".

A TTL is what the zone asks the world to do. Nothing enforces it.

• Some resolvers impose a floor. A TTL of 300 seconds may be treated as an hour, because the operator decided that nothing sensible changes faster than that.
• Some cap long TTLs, which helps you, and some extend short ones, which does not.
• Browsers keep their own cache, on their own timer, and it is not always the TTL's.
• Operating systems cache too, and a laptop that has been asleep may not have re-checked anything since it woke.
• Some devices cache until they are restarted. Routers, phones, smart TVs, office equipment, anything with a small embedded resolver. A few effectively never expire an entry until they lose power.

None of that is misconfiguration on your part or ours. It is a large number of independent caches, each following its own policy, and the only thing they have in common is that you cannot reach any of them.

So: 48 hours

Most of the world sees a change within the TTL. Nearly all of it within a few hours. The tail — a handful of resolvers with long floors, and devices that cache until rebooted — is what makes up to 48 hours the figure worth telling a customer or a colleague.

Quote 48 hours and be pleasantly surprised. Quote five minutes and spend two days explaining.

Lower the TTL before a planned move

This is the one thing that genuinely shortens the wait, and it only works in advance.

1. A day ahead, drop the record's TTL to five minutes.
2. Wait for the old TTL to pass, so the world is now holding the short one.
3. Make the change. Most resolvers pick it up within minutes.
4. Put the TTL back up afterwards.

⚠️ Lowering the TTL at the same time as the change is too late. The world is already counting down the old value — the one it was given before you touched anything. The new TTL only starts to apply after the old one expires, which is precisely the wait you were trying to avoid.

What you can check, and what you cannot

Resolvers: checkable. The DNS lookup tool asks fresh every time rather than reading a cache, so it tells you what the answer is now. Run it against your domain to confirm the record is correct and live. If it shows the new value, our side is done and the rest is other people's caches expiring.

⚠️ Checking from your own machine is the least reliable test there is. You are the single most likely person in the world to be holding the old answer — you looked at the site while you were working on it, and your browser and operating system both remembered. A clear result from the lookup tool and a stale page in your own browser is the expected combination, not a contradiction.

Devices: not checkable, by anyone. There is no tool, ours or anybody's, that can tell you whether a particular phone, laptop or router is still holding an old answer. The cache is inside that device and nothing outside it can read it. The only test is the direct one: open the page on that device and see.

If one device is stuck and others are fine:

• close the browser fully and reopen it, rather than refreshing;
• try a different browser, or a private window;
• turn mobile data on to bypass the local network entirely;
• restart the device, which clears most embedded caches;
• restart the router, which clears the one caching for the whole house or office.

While you are waiting

Nothing is lost during the overlap. Both the old and the new answers point at real servers, so visitors reach one or the other — not an error. If the old destination still works, the wait is invisible to almost everyone.

If it does not — a server being switched off, a host being cancelled — keep the old one running until the tail has passed. That, rather than the DNS change, is what turns a quiet migration into an outage.

Last reviewed 2026-09-25.