You changed the record an hour ago, and half the office still lands on the old server. That's DNS TTL: the number of seconds a resolver may cache a DNS answer before asking again, an expiry date stamped on every record. Nothing actually 'propagates'. After a change, thousands of independent caches keep serving the old value until their countdowns hit zero, and they all started at different moments. Once that clicks, DNS stops being mysterious. We'll cover how caching really works, which TTL fits which situation (a permanent 60 seconds is usually waste), and how to plan a migration around the math instead of hoping.
The short answer
TTL (time to live) is the number of seconds a resolver may cache a DNS answer before asking again. It’s set per record, and it’s why “propagation” exists: after a change, the world keeps serving the old answer until the old TTL runs out. Lower it before changes. The rest of the time, park it around an hour.
The mechanism in thirty seconds
Every DNS record carries a TTL, assigned by whoever runs the zone. When a recursive resolver (your ISP’s, say, or Google’s 8.8.8.8) fetches www.example.com A 93.184.215.14 TTL 3600, it stores the answer and serves it from memory for up to an hour, counting down as it goes. Run a DNS lookup twice in a row and you’ll see it: the second answer often returns faster, with a lower TTL. You’re reading someone’s cache mid-countdown.
That’s the entire trick that lets a protocol from 1983 serve today’s internet. Authoritative servers for a popular domain answer a tiny fraction of the world’s queries; caches absorb the rest. The TTL is the dial that trades freshness against load. Shorter, and changes apply faster. Longer, and resolvers ask less often.
The semantics live in RFC 1035 and its clarifications, and the key word is maximum, not contract. Caches may drop records early under memory pressure, and a handful of resolvers clamp very low TTLs upward. Negative answers (the domain doesn’t exist) get cached too, governed by the SOA record’s minimum field. Classic gotcha when you query a name before creating it.
”Propagation” is not what the word suggests
Nothing propagates. There’s no wave rolling across the internet. Publish a change and your authoritative servers answer with the new value; every resolver that asks fresh gets it instantly. Every resolver holding a cached copy keeps serving the old value until its countdown hits zero. Those countdowns started at different moments, on thousands of independent caches.
So the worst case for full convergence is the TTL that sat on the record before you changed it. Change a record carrying 86400 and some users can see stale data for a day; nothing you do afterward shortens it. It’s also why the gradient happens: your phone on 5G already sees the new site while your colleague’s office resolver serves the old one for forty more minutes. Both are behaving correctly.
Which inverts how most people schedule changes. The important TTL work happens before the change. Drop the TTL to 300 at least one full old-TTL period in advance, so every cache has picked up the short value. Make the change, verify, raise it back. That five-minute window is the difference between a cutover and a vigil.
Recommended TTL by situation (log scale)
Lower the TTL one full old-TTL period before any change, raise it back after.
Picking values like an operator
For everyday A and AAAA records on stable services, 3600 (one hour) is the boring, correct answer. Changes apply within a coffee break and nobody notices anything. Genuinely static infrastructure can run 4 hours or more without regret.
Failover records are the exception. If a load balancer or a DNS-based failover service is supposed to move traffic in minutes, its TTL has to stay short, 60 to 300, permanently. That’s the cost of the feature. Just be honest about which records those are. A 60 second TTL on a record nobody has changed since 2023 is pure waste: every minute, every resolver on earth re-asks the same question and gets the same answer. Most low TTLs we run into are that second kind.
Slow-moving plumbing goes the other way. NS records and glue change rarely and break loudly, so a day is normal. MX records sit comfortably at an hour or more, since sending servers retry on failure anyway; mail forgives brief DNS staleness. TXT records used for verification (SPF, DKIM, DMARC, the topic of our email authentication guide) live fine at an hour, though we drop ours to 300 while iterating on a new SPF record. Saves a lot of waiting between attempts.
A migration checklist that respects the math
Say the old record is www A 203.0.113.10 TTL 14400 and you’re moving to a new host. Day one: lower the TTL to 300, change nothing else. Wait at least four hours (the old TTL) so every cache holds the short-TTL copy. Then cut over: switch the A record to the new address and verify immediately with a fresh lookup against your authoritative servers plus a couple of public resolvers. Keep the old origin serving (or redirecting) for stragglers. Within five minutes the world has converged. A day later, raise the TTL back to its cruising value and decommission the old origin.
The whole thing is ten minutes of actual work wrapped around two waiting periods, and the waiting isn’t optional. It’s the TTL doing exactly what it says. Internalize that and DNS changes stop being scary. It’s a cache with a countdown, and you own the clock.
Frequently asked questions
What does TTL 3600 mean on a DNS record?
Resolvers may reuse that answer for up to 3600 seconds (one hour) without asking your nameservers again. A user whose resolver cached the record at minute zero can see the old value until minute sixty after you change it. It's a maximum, not a promise: caches may evict earlier, and a few misbehave and hold on longer.
How long does DNS propagation really take?
Your authoritative servers answer with the new value seconds after you publish. Everyone else catches up as their cached copy expires, so the realistic worst case is the OLD TTL that was in effect before the change, plus a little slack for resolver quirks. If the old TTL was a day, plan for a day. Nothing you do after the change speeds it up.
Is a very low TTL like 30 or 60 seconds bad?
As a permanent setting, usually yes. Every cache expiry forces a fresh lookup, so a 60 second TTL multiplies query load on your DNS provider and adds resolution latency for users, in exchange for agility you rarely use. Keep low TTLs for planned changes and failover records. Park everything else at an hour or more.
Why did my change show up for some people and not others?
Different resolvers cached the old record at different moments, so their copies expire at different moments. Some resolvers pre-fetch popular names. Mobile carriers run aggressive caches. A few resolvers flat out ignore low TTLs. Put that together and a rollout always lands as a gradient, not a step. Checking against several resolvers shows it directly.
Does TTL affect my SEO?
Not directly, TTL isn't a ranking signal. Where it bites is migrations: a botched cutover with a day-long TTL can leave crawlers hitting a dead origin for hours. Lower the TTL before moving, confirm the new target, then raise it again. Googlebot follows DNS like any other client.
