Why does a DNS change take time to propagate?

You change your domain’s record to point at a new server, save, and your website still shows the old version. You ring your business partner and they already see the new one. An hour later a client emails to say the page will not load. Your provider gives the usual answer: “DNS can take up to 48 hours to propagate”.

That sentence is half true and explains very little. DNS does not spread like a wave travelling round the world. What actually happens is that thousands of servers hold a saved copy of the old answer, and each one throws it away when its time comes. Understanding when each one’s time comes is what turns a nerve-racking migration into a twenty-minute job.

What happens when someone types your domain

The browser does not know which server yourdomain.com lives on. It asks a resolver: the DNS server the connection is set up to use, usually your internet provider’s, or a public one such as Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8.

If the resolver does not have the answer, it goes and finds it: it asks the root servers about .com, the .com servers about who handles yourdomain.com, and your domain’s authoritative servers (the ones you set at your registrar, whether they belong to your hosting or your DNS provider) for the actual address. With the answer in hand, it passes it to the browser and keeps it for next time.

That saved copy is the key to everything. Without it, every visit to every website in the world would repeat the whole chain of questions and DNS would be painfully slow. With it, most lookups are answered from cache in milliseconds.

The TTL: each answer’s use-by date

Every DNS record carries a TTL (time to live): the number of seconds a resolver may keep the answer before asking again. A TTL of 3600 is an hour; 300 is five minutes; 86400 is a day.

When you change a record, the change is immediate on your authoritative servers. What takes time is for resolvers already holding the old answer to discard it, and that depends on the TTL the old record had, not the new one. If the old record had a one-day TTL and a resolver looked it up an hour ago, that resolver will keep handing out the old address for another twenty-three.

That is where the famous 48 hours come from: they are the worst case from an era when TTLs of a day or two were the norm. Today many providers set TTLs of minutes by default, and most changes become visible within that time.

Why you see one thing and someone else sees another

Because you are most likely each asking a different resolver, or not asking at the same moment:

• Every provider runs its own resolvers, and each keeps its own copy. Your colleague’s may not have looked up your domain for hours and fetches the new answer straight away; yours saved it ten minutes ago.
• A public resolver is really many servers. Cloudflare, Google and Quad9 answer from data centres around the world, and their caches are not synchronised to the second.
• There are more caches in front of the resolver. The operating system and the browser keep answers too, and the office router sometimes acts as a middleman.
• Some resolvers do not follow the TTL to the letter: they apply a minimum of their own or extend the copy if the authoritative server does not respond.
• And sometimes the difference is legitimate. If your site sits behind a CDN, each visitor may get a different address depending on where they connect from, by design.

There is also a case that catches people out: if someone looked up a name before it existed (a newly created subdomain, say), the resolver caches that “does not exist” too, for as long as the domain’s SOA record specifies. That is why creating a record and testing it in the same second can sometimes leave an error stuck for a while.

Changing the domain’s name servers

Changing a record within your zone (the website’s A record, the MX for email) is the easy case. Changing the domain’s name servers at the registrar, for instance when moving DNS management to another provider, is a different matter: that information is held by the extension’s servers, and for .com the delegation usually carries a two-day TTL you cannot touch.

In practice, during that period some resolvers will ask your old servers and others the new ones. The rule for nobody noticing is that both zones say the same thing: copy every record to the new provider before switching the delegation, and do not shut down the old one for a few days. And if you are in the registrar’s dashboard anyway, take the chance to check the renewal settings, as explained in what happens when a domain expires.

How to prepare a change so it takes minutes

This is the useful part, and hardly anyone does it because it has to be remembered in advance:

1. Check the current TTL of the record you are going to change.
2. Lower it to 300 seconds at least as far ahead as that TTL. If it was a day, lower it two days before; that way, when the moment comes, no resolver will be holding a copy older than five minutes.
3. Make the change. The longest wait is now about five minutes for almost everyone.
4. Check on several resolvers that they already see the new value.
5. Keep the old server running for a while, for any resolvers lagging behind.
6. Raise the TTL again once everything is stable, to an hour or more. A permanently low TTL multiplies lookups and leaves you more exposed if your DNS provider has a problem.

It is the same order worth following when migrating a website without losing rankings: the DNS change is the last step, taken only once the new server has been tested.

While you wait, flushing your own machine’s cache helps you see the change sooner (on Windows, ipconfig /flushdns), and a private browsing window sidesteps part of the browser’s cache. But none of that speeds up anything happening beyond your computer.

Checking it

The DNS propagation checker queries the same name on Cloudflare, Google and Quad9 at once and compares their answers for A, AAAA, CNAME, MX, TXT, NS and CAA records. Next to each answer it shows the TTL that resolver returns, which for a cached answer is the time left before it asks again. You can let it repeat the lookup every thirty seconds while you wait.

If all three agree, the change is live, although your internet provider’s resolver may take a little longer for the reasons above. And if what you are changing is email records, the SPF, DKIM and DMARC checker tells you whether the new ones are written correctly.

---

Propagation cannot be forced, but it can be planned. Lowering the TTL a couple of days ahead is the one habit that makes the biggest difference between a calm migration and an afternoon spent answering the phone.