DNS Propagation Isn’t Real. Here’s What’s Actually Happening.

You changed a DNS record, and someone told you to wait 24 to 48 hours for it to propagate. That advice describes a real experience, a change that takes a while to show up everywhere, but the wrong mechanism behind it. Knowing the real one tells you exactly what to check instead of just waiting and hoping.

There’s no propagation, there’s caching

DNS propagation implies a signal spreading outward from your registrar, reaching resolvers one by one until the whole internet has heard the news. That’s not how it works. The moment you update a record, your authoritative nameserver has the new value immediately. Nothing needs to travel anywhere for that part.

What actually causes the delay is that DNS is a pull system, not a push one. Resolvers around the world only ask your nameserver for a record when someone queries it, and once they get an answer, they cache it locally for a set period rather than asking again every time. Per RFC 1035, that period is the record’s TTL, its time to live, measured in seconds. A resolver that cached your old answer yesterday has no reason to ask again until that cached copy expires, so it keeps serving the old value regardless of what your nameserver would say if asked right now.

There’s no wave. There are just thousands of independent caches around the world, each with its own clock counting down on its own copy of the old answer, with no coordination between any of them.

TTL is the only thing that actually determines the wait

This is why the real question is never “has it propagated.” It’s “what was the TTL on the old record, and has that fully elapsed for the resolvers your visitors actually use.” A record with a one hour TTL is functionally done within about an hour of the change. A record with a 24 hour TTL can plausibly still be showing the old answer to someone a full day later, and that’s not a fault, it’s the record behaving exactly as specified.

Here’s the gotcha that trips people up: lowering the TTL at the same time you make the change doesn’t help. The new, lower TTL value is part of the new record, and the new record isn’t visible to a resolver until its cached copy of the old record, with the old TTL, expires. If you want a fast cutover, the TTL needs to be lowered in advance, days ahead if possible, and left low until well after the actual change goes out. Only then does the short wait you’re hoping for actually apply.

There’s a second, separate gotcha for brand-new records rather than changed ones. If anything queried a subdomain before you created it, the resolver cached that non-existence too. RFC 2308 defines this as negative caching, and its duration comes from your zone’s SOA record, specifically the smaller of the SOA’s own TTL and its MINIMUM field, which is often an hour or more. Adding the record doesn’t clear that cached “doesn’t exist” answer any faster than an ordinary TTL would clear a changed one.

It’s also worth knowing that TTL is a request, not a universal guarantee. Most major public resolvers honor it precisely, but some consumer ISP resolvers apply their own minimum floor regardless of what you set, to reduce how often they have to re-query. If a very short TTL still isn’t behaving as expected on a particular network, this is worth ruling out before assuming something else is wrong.

Why nameserver changes really can take longer

There’s one case where the old 24 to 48 hour folklore has real grounding: changing your domain’s nameservers entirely, rather than an individual record.

Nameserver delegation isn’t controlled by your own DNS provider. It’s a record held by the parent zone, the registry for your TLD, and that record has its own TTL, often longer than anything you’d set for your own records, and not something you control directly. RFC 2181 clarifies exactly this kind of TTL handling across delegation boundaries. A resolver that’s cached the old nameserver delegation will keep asking the old nameservers, correctly, until that delegation TTL expires, and that’s very likely where the generic “give it 48 hours” advice originally came from, applied afterward to every kind of DNS change regardless of whether it actually involved switching nameservers.

How long does DNS propagation actually take?

There’s no fixed answer, because there’s no propagation to time. It depends entirely on the TTL of whatever’s being cached: the old record’s TTL for a change, the SOA’s negative caching duration for a brand-new record, or the parent zone’s delegation TTL if you’re switching nameservers, which is the one case where 24 to 48 hours isn’t just folklore. Check the specific TTL that applies to what you actually did, and that’s your real answer.

A quick self-audit

Before assuming a wait time, check the TTL on the record you’re replacing, not the new one you’re setting.
If a change is planned in advance, lower the TTL days ahead of time, then wait for the old TTL to fully expire before making the actual change.
Treat nameserver changes differently from ordinary record changes. The relevant TTL isn’t yours to set.
If one device shows the new value and another doesn’t, check local DNS caches before assuming anything is wrong upstream. Chrome and Firefox keep their own cache separate from the OS (chrome://net-internals/#dns shows and clears Chrome’s), the OS has its own resolver (systemd-resolved on Linux, mDNSResponder on macOS, ipconfig /flushdns on Windows), and a home router running its own local caching resolver adds a third layer on top of both.
Query the authoritative nameserver directly when you need to know the real current value, rather than trusting whatever your own resolver happens to have cached.

Querying your authoritative nameservers directly is what actually tells you the truth, not whatever your own resolver has cached. That’s exactly what kant.au checks for every domain you monitor, alongside a full history of what changed and when. Want to see what your domain’s records actually say right now? Check it for free.

RFC 1035, Domain Names: Implementation and Specification
RFC 2181, Clarifications to the DNS Specification
RFC 2308, Negative Caching of DNS Queries