TTL Explained: How Long Your DNS Changes Actually Take to Take Effect

TTL (time to live) is the one DNS setting almost every provider asks you to choose, and almost nobody thinks about beyond accepting the default. It's worth a closer look, because it's a deliberate trade-off, not just a technical formality, and getting it wrong in either direction has a real cost.

What TTL actually controls

Every DNS record carries a TTL, a number of seconds telling any resolver that caches the record how long to hold onto that answer before checking again:

example.com.    300    IN    A    203.0.113.42

A TTL of 300 means a resolver that just cached this record won't ask again for five minutes, no matter how many times it's queried by different clients in that window. This is what makes DNS fast at scale: without caching, every single request for every domain would require a fresh round trip to an authoritative nameserver. For the mechanics of why that caching makes propagation feel uneven across different resolvers, see Why DNS Propagation Takes So Long. This piece is about a different question: given that trade-off exists, what TTL should you actually set, and for which records?

The trade-off, stated plainly

A high TTL (measured in hours) means fewer lookups, lighter load on your nameservers, and marginally faster resolution for cached results, since resolvers around the world are serving answers from cache rather than querying you. The cost: if you need to change that record, whether for a planned migration or to recover from a mistake, every resolver that already cached the old value keeps serving it until its own copy expires. A bad A record with a 24-hour TTL means some visitors see a broken or wrong destination for up to 24 hours after you've fixed it at the source.

A low TTL (measured in minutes) means changes take effect quickly almost everywhere, which is valuable both for planned migrations and for damage control during an incident. The cost is more queries hitting your authoritative nameservers, since fewer of them get satisfied from cache, and if your DNS provider has any latency or reliability issues, a low TTL exposes clients to that more often, since they're re-checking more frequently.

Neither setting is universally correct. It depends on how often the record needs to change and how costly a stale answer would be if you needed to change it in a hurry.

A reasonable default per record type

A and AAAA records: low-to-moderate TTL, often 300–3600 seconds. These are the records most likely to need a fast rollback (a bad deploy, a server that needs to be swapped immediately), so keeping the TTL short gives you the option to recover quickly. If you're mid-migration, temporarily dropping this to 300 or lower, as covered in the propagation article linked above, is standard practice.

MX records: moderate-to-high TTL, since mail routing changes are infrequent and planned well in advance. A stale MX record for a few hours during a rare provider migration is a minor inconvenience; unnecessarily hammering your nameservers with mail-routing lookups for no benefit is not a great trade in the other direction.

NS records: high TTL, typically dictated more by your provider's and registrar's defaults than something you tune yourself. NS changes are rare, deliberate, and already slow to propagate for structural reasons (they live in two places, as covered in What NS Records Are), so a short TTL here doesn't buy you much.

TXT records (SPF, DKIM, DMARC, verification tokens): moderate TTL is usually fine. These don't change often, but when they do (a mail provider migration, a DMARC policy tightening), you generally want the change to take effect within an hour or so rather than a full day, since email deliverability issues from a stale record are the kind of thing you want to resolve quickly.

Why lowering TTL after a change already happened doesn't help

This is the part that trips people up. TTL isn't retroactive. If a resolver cached your A record with a TTL of 3600, and you then edit the record and drop its TTL to 60, the next answer will carry the new TTL, but the resolver that already has the old answer cached doesn't know that. It holds the stale record for the remainder of the hour it originally cached, regardless of what the TTL says now.

The only way to benefit from a low TTL during a change is to lower it before the change, wait long enough for the old, longer TTL to fully expire everywhere, and only then make the actual change. This is why a careful migration plan lowers TTL a full cache cycle ahead of time rather than at the moment of the cutover.

TTL and monitoring detection speed

TTL also affects how quickly an external monitoring check can notice a change, though not in the way it affects your visitors. A monitoring tool that queries your authoritative nameservers directly, rather than relying on a cached resolver, sees the current record immediately regardless of TTL. The TTL only governs how long other resolvers hold onto a stale answer after your nameservers already reflect the change.

That distinction matters when investigating an alert: if OneDollarDNS flags a change but a browser or dig against a public resolver still shows the old value, that's very likely a cache still working through its TTL window, not a sign that the alert was wrong. Querying your authoritative nameserver directly, dig @ns1.example.com example.com A, shows the same current answer that monitoring saw.

Checking a record's TTL

dig A example.com

The TTL appears in the response, and it counts down in real time as different resolvers are queried, since each one reports how much of its own cache window remains.

How DNS monitoring fits in

Because OneDollarDNS checks your authoritative nameservers directly rather than a cached view, detection isn't gated by your TTL settings the way ordinary resolution is. A record can have a six-hour TTL and still trigger an alert within minutes of changing, since the check bypasses caching entirely to see what your nameservers are actually serving right now. TTL still matters enormously for how fast that change reaches your actual visitors; it just isn't a variable in how fast you find out about it.