DNS Propagation Explained: Why Changes Take Time and How to Watch Them Spread

6 min read

You changed a DNS record, your colleague across the world sees the new site, and you still see the old one. Nothing is broken. This guide explains what is actually happening, how long it takes, and how to watch it happen with our DNS Propagation Checker.

Propagation is not distribution

The word suggests your change is being copied around the internet. It is not. Nothing is pushed anywhere. Instead, thousands of DNS resolvers, run by ISPs, companies and public services like Google and Cloudflare, each keep a cached copy of your old record, labelled with an expiry time called the TTL (time to live). Your change "propagates" one resolver at a time, as each cache expires and the resolver asks again and gets the new answer.

How long it really takes

As long as the old record's TTL, plus stragglers. With a typical TTL of 1 to 4 hours, most of the world sees a change within that window. The famous "24 to 48 hours" is the worst case: a long old TTL (some records are set to a full day) plus a few stubborn ISP caches. If a change matters, check the TTL before you make it, not after.

The professional trick: lower the TTL first

A day before a planned move, set the record's TTL down to 300 seconds. Wait for the old, long TTL to expire (that wait is unavoidable, but it happens while the old setup still works). Then make your change: now every cache in the world holds it for at most five minutes, and the switch lands quickly. Afterwards, raise the TTL again so resolvers cache efficiently.

How to watch it happen

The propagation checker asks resolvers in the US, Europe and Asia the same question at the same moment and lines the answers up. All agreeing means you are done. A split table means caches are still expiring, and the rows still showing the old value tell you roughly where in the world the old answer survives.

Why your own connection is the last to know

Your ISP's resolver may cache longer than most, your router adds another cache, and your browser a third. If the checker shows the new record everywhere but your screen shows the old site, switch your device to a public resolver (1.1.1.1 or 8.8.8.8) or simply wait; the rest of the world is already where you want it. One warning in the other direction: if different resolvers return different addresses for a big site, that can be normal round-robin or CDN behaviour, several correct answers at once, not a propagation problem. The checker explains which case you are looking at.

The takeaway

DNS changes are not slow because the internet is slow; they are slow because caching is what makes DNS fast the other 364 days of the year. Plan the TTL, make the change, and verify with data instead of refreshing and hoping.

More guides