DNS TTL and Propagation: Why Changes Take Time

TTL stands for time to live, and it is a number measured in seconds. Every DNS record you publish — an A or AAAA record, an MX record, a CNAME, and so on — is served with a TTL attached.

The TTL is a permission, not a promise: it tells any resolver that fetches the record how long it may cache that answer before it must ask the authoritative servers again. A record with a TTL of 3600 can be cached for up to one hour. A record with a TTL of 300 can be cached for up to five minutes. When the TTL runs out, the cached copy is discarded and the next lookup goes back to the source.

DNS is queried constantly — every link you click, every image that loads, every email that is delivered triggers lookups. If every one of those had to travel all the way to a domain's authoritative nameservers, the system would be slow and those servers would be buried under load.

Caching fixes this. The first time a resolver looks up example.com, it stores the answer for the length of the TTL. Every later request for the same name, from anyone using that resolver, is answered instantly from memory until the TTL expires. The result is faster page loads for users and far less traffic for the authoritative servers. TTL is the dial that decides how aggressive that caching is.

People talk about DNS changes "propagating" or "spreading" across the internet, as if your update is pushed out to servers around the world. That is a myth. There is no push and nothing spreads.

When you edit a record, the change is applied to your authoritative nameservers instantly. The source of truth is updated the moment you save. What lags is everyone else's cached copy of the old answer. Each resolver keeps showing the old value until the TTL it cached the record with runs out — then, and only then, does it ask again and pick up the new value.

So "propagation" is not the new record travelling outward. It is the old record's caches expiring, resolver by resolver, on their own schedules. Once you see it that way, the timing stops being mysterious: it is bounded by the TTL that was in effect when the old answer was cached.

Caching applies to "no such record" answers too. If a resolver asks for a name that does not exist, it gets an NXDOMAIN response, and it caches that negative answer so it does not keep asking. The same happens for a name that exists but has no record of the requested type.

How long those negative answers are cached is governed by the minimum field of the zone's SOA (Start of Authority) record, as defined in RFC 2308 — this is the negative TTL. It matters in a common situation: you look up a record before it exists, the absence gets cached, and then you add the record. Until the negative TTL expires, resolvers that already cached the "does not exist" answer keep returning it. If you are adding brand-new records, keep the SOA minimum modest so a cached miss does not linger.

When you know a change is coming — moving a site to a new IP, switching mail providers — you can make the cut-over fast and clean by managing the TTL ahead of time:

1. Lower the TTL well in advance. Some time before the change (at least the length of the current TTL, ideally a day or two earlier), drop the record's TTL to something short like 300 seconds.
2. Wait out the old TTL. Give the previous, longer TTL time to fully expire everywhere. After that window, resolvers worldwide are caching your record for only five minutes.
3. Make the change. Update the record to its new value. Because the cached TTL is now short, the world picks up the new answer within minutes, not hours.
4. Raise the TTL back up. Once the change has settled and you are happy with it, restore a longer TTL to get the caching and load benefits back.

The key insight: lowering the TTL only helps if you do it before the change and wait out the old value. Lowering it at the same moment you make the change does nothing for the copies already cached at the old, longer TTL.

Choosing a TTL is a trade-off between agility and efficiency. A low TTL means changes take effect quickly, but resolvers re-query more often, adding queries and load. A high TTL means answers are cached longer — cheaper and faster for users — but changes are slow to take effect. Common values:

TTL (seconds)	Roughly	Good for
300	5 minutes	Records you are about to change, or that fail over often
3600	1 hour	A sensible default for most records
86400	24 hours	Stable records that rarely change, to maximize caching

A practical pattern is to run stable records at one hour or a day for the efficiency, and temporarily drop to five minutes around a planned change.

During the window after a change, the internet is not in one consistent state — it is a patchwork. A user whose resolver never cached the record, or whose cache has already expired, gets the new value. A user behind a resolver that cached the old record with time still left on its TTL keeps getting the old value until that timer runs out.

Because different resolvers cached the record at different moments, their TTLs expire at different times. That is why two people can load the same site and reach different servers for a while. It is expected, it is temporary, and it ends when the longest remaining cached TTL expires — never longer than the TTL that was in effect when the change was made.

Switching DNS providers — changing your domain's nameservers at the registrar — is bounded by a different TTL than your individual records. The delegation lives in the parent zone (the TLD's servers), and the NS records there carry their own TTL, which is often long — measured in hours or up to a day or two.

That means a nameserver change can take noticeably longer to settle than a routine record edit, because resolvers may keep using your old nameservers until the parent's NS TTL expires. You cannot shorten the parent's TTL yourself; the practical move is to keep both old and new nameservers serving correct, matching data during the transition so visitors get the right answer no matter which set they are routed to.

When you are mid-change and unsure what the world sees, look at the records directly. who.is /dns shows you the current authoritative-ish answers for a domain along with their TTLs, so you can confirm what value is being published and how long it will be cached.

If you suspect a stale cache, remember that what your own machine sees depends on your resolver's cache, not just the authoritative data. Querying the authoritative servers directly (or checking from a different network) tells you whether the change is live at the source while local caches catch up.