What DNS propagation is, and why it takes as long as it does

What a TTL actually promises

Every record carries a TTL, in seconds, and it is an instruction to resolvers: you may reuse this answer for this long without asking again. A record with a TTL of 300 may be cached for five minutes. A record with a TTL of 86400 may be cached for a day.

The clock starts when a given resolver fetched the record, not when you changed it. A resolver that fetched your old record one second before your edit will serve the old value for very nearly the full TTL; one that fetches for the first time a second after your edit sees the new value immediately. This is why, during a change, different networks legitimately disagree — and why the spread is not evidence of a problem.

The worst case for a single record change is therefore one TTL, counted from the moment of the change. Not an average, not a guess: the old TTL is an upper bound that resolvers are entitled to use in full.

Where the "24 to 48 hours" figure comes from

The familiar 24-to-48-hour figure is not the TTL of an ordinary record. It comes from three other things, and separating them tells you which situation you are actually in.

• Long default TTLs. Plenty of zones are still published with 86400-second TTLs on everything, because that was a sensible default when zone edits were rare. One day of TTL produces one day of wait.

• Nameserver changes at the registry. Changing which nameservers serve a domain is an edit to the delegation in the parent zone, not to your own zone. Those records carry TTLs set by the registry, commonly one or two days for a generic top-level domain, and you cannot lower them in advance because they are not yours.

• Resolvers that do not honour short TTLs. Some ISP and corporate resolvers impose a floor, refusing to re-query more often than their own minimum regardless of what your record says. This is out of specification but it exists, and it is the reason a cutover that should have completed in five minutes occasionally has a long tail.

For a routine record change on a zone with sensible TTLs, 24 to 48 hours is simply wrong and sets a false expectation. For a nameserver change, it is realistic.

Negative answers cache too

A name that does not exist is also an answer, and it is also cached. RFC 2308 defines negative caching: when a resolver is told a name does not exist, it may remember that for a period derived from the zone's SOA record — the smaller of the SOA's TTL and its minimum field, the last number in the SOA line.

The practical consequence catches people out regularly. If you look up a subdomain before you create it, your resolver caches the non-existence, and then creating the record does not make it appear for you until that negative cache entry expires. Nothing is wrong with the record; you simply asked too early and are now waiting on an answer you caused.

If you are about to set up a new hostname, the cheap defence is not to query it first. If you already have, query it against the authoritative nameserver directly, which bypasses the cached negative answer entirely.

# what the authoritative server says right now
dig @elliott.ns.cloudflare.com example.com A +noall +answer

# what one public resolver is currently serving, and for how much longer
dig @1.1.1.1 example.com A +noall +answer

Reading the remaining TTL in a cached answer

A resolver does not just return the record; it returns the record with the TTL counted down to what is left of its cached copy. That number is the single most useful piece of information during a cutover, because it tells you exactly how much longer that resolver will keep serving what it has.

Query the same public resolver twice a few seconds apart. If the TTL has decreased by roughly the gap between your queries, you are looking at a cached answer and the number is a countdown. If it comes back at the record's full TTL each time, that resolver just fetched it fresh.

A resolver still serving the old value with 900 seconds left is not broken and does not need to be reported to anyone. It needs fifteen minutes.

How to plan a change so the wait is short

The whole of TTL management is one idea: the TTL that governs a change is the one that was in place before the change, so it has to be lowered in advance.

• At least one full old-TTL period before the change — a day earlier if the record currently sits at 86400 — lower the TTL on the records you are about to edit to something short, such as 300 seconds. Change nothing else.

• Wait out the old TTL. By the end of it, every resolver that had cached the record has re-fetched it and learned the new, short TTL along with the unchanged value.

• Make the actual change. It is now bounded by the short TTL, so the cutover window is minutes rather than hours.

• Watch until resolvers agree, then raise the TTL back to a normal resting value — an hour is a reasonable default for records that change rarely. A permanently short TTL costs you extra queries and makes you more fragile to a DNS outage, so it is a tool for a migration rather than a steady state, and our own DNS checks flag TTLs that sit at either extreme.

This sequence does not help with a nameserver change, because the delegation TTL belongs to the registry. For those, plan for the registry's TTL and keep the old nameservers serving correct data throughout, so that resolvers still following the old delegation get right answers rather than none.

Mail is the case where a stale answer costs you something

For web traffic, a stale DNS answer usually means a visitor reaches the old server and sees old content. For mail it can mean a message is delivered to a server that no longer forwards it anywhere, which is silent loss rather than a visible error.

The defence is overlap rather than speed. Keep the old mail platform accepting and forwarding mail for the whole of the MX record's TTL after the change, and preferably longer — sending servers that fail a delivery attempt retry for days, so a message accepted by the old platform late in the window may still be in a queue afterwards.

Lower the MX TTL in advance the same way as any other record, but treat the TTL as the start of the safe window rather than the end of it.

What commonly goes wrong

• Checking with your own machine's resolver only. Your operating system and browser both cache independently of your network's resolver, so the last place to see a change is often your own laptop. Query a public resolver directly instead of trusting what the browser shows.

• Concluding the change failed because one checker location disagrees. Compare against the authoritative nameserver: if it has the new value, the record is correct and everything else is caching.

• Lowering the TTL at the same moment as making the change, which does nothing, because resolvers are still working from the copy they cached under the old long TTL.

• Editing the record at the old DNS provider after moving nameservers, or at the new one before the delegation has been followed everywhere. During a nameserver move, both zones need to be correct.

• Assuming a negative answer will clear when you create the record. It clears when the negative cache entry expires, which is governed by the SOA, not by your edit.