ALIENWEB

DNS propagation: what it actually is, and why "48 hours" is usually wrong

By , Alien Web Design · Last reviewed: 15 August 2026 · Reviewed every 6 months

You changed a DNS record. Your host told you to wait 48 hours. Some people can see the new site, some people still get the old one, and nobody can tell you why. Here is the part most guides skip: nothing is "propagating". No message is travelling anywhere. What you are waiting on is other people's caches quietly expiring, and once you know that, you can predict almost exactly how long it will take and check it properly instead of refreshing and hoping.

Nothing propagates. Caches expire.

"Propagation" makes it sound like your change is being broadcast across the internet, server to server, until everyone has it. That is not what happens. Your DNS records live in one place: the authoritative nameservers for your domain. When you edit a record, you edit it there, and it is done immediately. There is no queue and no distribution step.

What takes time is everything that already asked. When someone visited your site last week, their internet provider's resolver asked your nameserver for the answer and then kept it, so it would not have to ask again for every visitor. That stored copy has an expiry timer on it. Until it expires, that resolver keeps handing out the old answer, because as far as it knows the answer is still good.

So the real question is never "has it propagated yet". It is "how long did I tell resolvers to keep the old answer, and when did each of them last ask". Those are two different clocks, which is why some people see the change and others do not.

What TTL actually controls

Every DNS record carries a TTL, or time to live, measured in seconds. A TTL of 3600 means one hour. It is an instruction to any resolver that asks: you may keep this answer for this many seconds, then throw it away and ask me again.

Here is the part that catches people out, and it is the single most useful thing on this page:

The countdown you care about

The TTL countdown does not start when you make the change. It starts when each individual resolver last fetched the record. A resolver that asked 55 minutes ago, with a one hour TTL, will pick up your change in 5 minutes. One that asked 2 minutes ago will take another 58. That is the entire reason your change appears "half live".

The practical consequence: the worst case is one full TTL, counted from the moment you make the change. If your TTL is 3600, everyone in the world has the new record within one hour. Not 48. One. The only people still on the old answer after that are ones whose software is ignoring the TTL, which does happen and which we will come back to.

Do this before you change anything

Because the wait is bounded by the TTL, you control it. Lower the TTL before the change, not during it.

  1. Drop the TTL on the record you are about to change

    Set it to 300 seconds (5 minutes). Change nothing else.

  2. Wait out the old TTL

    If the record was on 3600, wait an hour. If it was on 86400, wait a day. You are waiting for every resolver to pick up the new short TTL. This is the step people skip, and skipping it is why the trick does not work for them.

  3. Make the real change

    Now the whole internet is holding an answer that expires in 5 minutes, so your actual change lands in 5 minutes.

  4. Put the TTL back up

    Once it is confirmed working, return it to 3600 or higher. A permanently low TTL means more lookups, marginally slower first connections, and a harder outage if your nameservers ever become unreachable.

If a migration is already underway and you did not do this, you cannot retrofit it. Lowering the TTL now only helps the next change, because resolvers are still holding the old long TTL. That is worth knowing before you spend an afternoon wondering why it did not help.

Why the "48 hours" number will not die

Three reasons, and none of them is that your change takes two days.

It is a safe thing for a support desk to say. If a host tells you 48 hours and it works in 20 minutes, you are delighted. If they tell you 20 minutes and something else is wrong, you are on the phone. The number is a customer service decision, not a technical one.

It is inherited from a much older internet. Default TTLs used to be 86400 seconds (24 hours) or longer, and some registry level changes genuinely were slow. Doubling 24 to 48 was a sensible margin then. Modern defaults are usually 3600 or lower.

The registrars themselves still publish it. This is not a straw man. As of August 2026, checking three control panels Australians actually use: VentraIP's own documentation says a nameserver change can take up to 24 hours; Crazy Domains says 24 to 72 hours; GoDaddy says most updates take effect within an hour, but could take up to 48 hours. GoDaddy's phrasing is the honest one: the typical case and the worst case are different numbers, and the typical case is the one you will actually get.

The one change that genuinely is slower

There is a real exception, and conflating it with ordinary record edits is where a lot of the confusion comes from.

Changing a record (your A record, your MX, a TXT) happens on your own nameservers and is governed purely by that record's TTL. Changing your nameservers is different: that is a change to the delegation held by the registry for your top level domain, not by you. It has its own TTL, typically much longer, and it has to be published by the registry before resolvers will even look at your new nameservers.

Nameserver changes are the ones where "up to 24 hours" is a fair statement rather than a hedge. They are also the ones that break email, which is a big enough problem that it has its own guide. If all you need is to point your website at a new server, you almost certainly do not need to touch nameservers at all.

The reason a fixed record still looks broken

This is the one that almost no DNS guide covers, and it explains a specific, maddening symptom: you create a record that did not exist before, and it still comes back as "not found" long after it should be live.

Resolvers cache failures too. When a resolver asks for a name that does not exist, it gets back a negative answer, and it caches that answer just like a positive one. The rules for how long are set out in RFC 2308: the lifetime of a cached negative answer is taken from the minimum of your zone's SOA MINIMUM field and the SOA record's own TTL.

Why this bites

The record you just created has a nice short TTL. But that TTL is irrelevant, because the resolver is not holding your record, it is holding a "this does not exist" answer whose lifetime came from your SOA. If your SOA minimum is 86400, a subdomain you got wrong once can stay invisible for a day after you fix it, on a record whose own TTL says 300.

The fix is to look up the record before you first publicise it, not after. Once a negative answer is cached, you wait it out.

How to check it properly

Refreshing your browser is the worst possible test, because your browser, your operating system, your router and your ISP each cache separately, and any one of them can show you a stale answer. Ask the servers directly instead.

On macOS or Linux, dig is already installed. On Windows, use nslookup. The point of the sequence below is that each command answers a different question, and running them in order tells you which of the three possible problems you have.

QuestionCommandWhat the answer means
Did my change actually save? dig +short example.com.au @ns1.yourhost.com Asks the authoritative server, which never serves a cached answer. Wrong value here means the change was never saved, or was saved in a zone that is not the live one.
Is the world still caching the old answer? dig +short example.com.au @1.1.1.1 Asks a public resolver. Correct at the authoritative server but stale here means you are simply waiting out a TTL. Nothing is broken.
How much longer? dig example.com.au @1.1.1.1 Without +short, the TTL column shows the seconds remaining before that resolver discards its copy. Run it twice a minute apart and watch it count down.
Which nameservers is the registry using? dig NS example.com.au +trace Follows the delegation from the root down. Catches nameserver changes that were saved at the registrar but never reached the registry.
Same checks on Windows nslookup -type=ns example.com.au 1.1.1.1 Equivalent to the above. Specify the resolver explicitly or you will silently test your own ISP's cache.

Web based checkers such as whatsmydns.net are useful for a quick global view, with one caveat worth stating: those tools query resolvers around the world and then often cache their own results, so a map full of red can lag reality by several minutes. Treat them as a second opinion, not the source of truth. Cloudflare's documentation makes the same point about its own setup checks, noting that most of these tools use cached query results.

When it really is stuck

If the authoritative server has the right answer and you are well past a full TTL, the problem is no longer propagation. In rough order of how often we see it:

The short version

Propagation is cache expiry, not distribution. Your change is live on your nameservers the second you save it. The wait is bounded by the TTL on the record, counted separately for each resolver from the last time it asked, which is why the rollout looks patchy. Lower the TTL a full old-TTL in advance and you can make any planned change land in five minutes. Check with dig against the authoritative server first and a public resolver second, because the difference between those two answers tells you whether you have a saving problem or a waiting problem. And if you created a record that still says "not found", you are probably waiting on a cached negative answer whose lifetime came from your SOA, not from the record.

General guidance only. TTLs, control panels and defaults vary by provider. Check your own zone before making changes to a live site.

Where this comes from

The primary sources behind the above, so you can check any of it yourself rather than take our word for it: