What TTL actually controls

Quick refresher. TTL (Time To Live) is how long recursive resolvers cache a DNS record before asking your authoritative server again. A TTL of 3600 means if you change the record right now, some clients won't see the new value for up to an hour — they'll keep using whatever their resolver cached until it expires.

This is not "propagation delay." There's no wave of updates pushing out across the internet. It's cache expiry. Each resolver independently decides when to re-query based on when it last fetched the record and what the TTL was at that time. That's it.

The default TTL trap

Most teams set TTLs once — during initial setup — and never think about them again. Common defaults:

These are perfectly fine for stable records. The problem isn't that these values are wrong — it's that nobody lowers them before the change that needs fast propagation.

Here's the scenario that burns teams: a service needs to move to a new IP. The A record has a TTL of 86400. Someone changes the record, then waits... and waits. Some users are hitting the old IP for up to 24 hours. The cutover that was supposed to take minutes takes a full day, and you can't decommission the old infrastructure until all caches expire.

This is entirely preventable. But it requires thinking about TTLs before you need them to be low.

When to lower TTLs

Before a migration

This is the single most important TTL practice. If you're moving a service to a new IP, a new load balancer, or a new provider, lower the TTL 48–72 hours before the change. Drop it to 60–300 seconds. By the time you flip the record, resolvers worldwide are refreshing frequently, and the new value takes effect within minutes.

The 48–72 hour lead time matters because you need the old TTL to fully expire first. If the record currently has a TTL of 86400 and you lower it to 300, resolvers that cached it at the old TTL won't re-query for up to 24 hours. Only after they re-fetch (and get the new, lower TTL) will they start refreshing every 300 seconds.

Before a failover test

If you're testing disaster recovery by switching DNS to a secondary site, lower TTLs in advance so the failover actually takes effect quickly. There's no point testing DR if the test takes 24 hours to propagate — you won't get meaningful timing data, and you'll create confusion as traffic slowly trickles over to the secondary.

For records that might need emergency changes

Some records are more likely to need urgent changes than others. Load balancer CNAMEs, API endpoint A records, service discovery records — anything that might need to move quickly during an incident. For these, consider keeping the TTL permanently low (300 seconds is a reasonable floor). The slight increase in query volume is insurance against being stuck during an outage.

During an active incident

If you need to reroute traffic right now and the TTL is 86400, you're stuck. You can change the record immediately, but clients will keep hitting the old target for hours. This is why keeping critical records at low TTLs proactively matters — by the time you're in an incident, it's too late to lower them.

If you didn't lower TTLs in advance and you're in an incident, change the record anyway and lower the TTL simultaneously. You're still waiting for old caches to expire, but at least once they do, the new TTL means subsequent changes (if you need to rollback or make further adjustments) will take effect quickly.

When to keep TTLs high

Not everything should be 60 seconds. Lower TTLs mean more queries to your authoritative servers, higher cost on metered providers, and no real benefit for records that never change.

MX records

Email infrastructure is tolerant of delay — mail servers retry delivery for hours or days. MX record changes are rare and always planned well in advance. A TTL of 3600–86400 is fine. Nobody is doing emergency MX failovers at 2am.

TXT records for verification

SPF, DKIM, DMARC — once these are set correctly, they rarely change. The same goes for domain verification TXT records (Google Workspace, Microsoft 365, etc.). TTLs of 3600 or higher are appropriate. If you do change them, plan ahead and lower temporarily.

NS records

NS records define delegation — which nameservers are authoritative for a zone. These should almost never change, and when they do (like a DNS provider migration), you're already planning weeks in advance. High TTLs (86400+) are standard and expected.

Stable A/AAAA records

If a record hasn't changed in a year and there's no foreseeable reason it would, a higher TTL is fine. It reduces load on your authoritative servers and saves money on providers that charge per query.

The cost consideration

On providers that charge per query — Route 53 charges $0.40 per million queries, for example — lower TTLs directly increase your bill. A record with a 300-second TTL generates roughly 12x more queries than the same record with a 3600-second TTL. For a high-traffic domain, that's a meaningful cost difference. The right TTL is a tradeoff between change agility and operational cost.

The pre-migration TTL playbook

Here's the step-by-step process. Follow this every time you're planning a DNS change for a migration or cutover:

  1. Check current TTL. What is it set to right now? Don't assume — verify. If it's already low (300s), you can skip the wait period.
  2. 48–72 hours before the change, lower TTL to 60–300 seconds. This is your prep step. Submit this as its own change request — it's low-risk and easily reversible.
  3. Wait for the old TTL to expire. If the TTL was 86400, wait at least 24 hours. If it was 3600, wait at least 1 hour. Resolvers that cached the record at the old TTL won't re-query until it expires.
  4. Make your DNS change. Now that resolvers are refreshing every 60–300 seconds, the new value takes effect quickly.
  5. Verify propagation. Use tools like dig against multiple resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, your ISP's resolver) to confirm the new value is live.
  6. Monitor for a day. Keep the TTL low for at least 24 hours after the change. If something goes wrong and you need to rollback, the low TTL means the rollback also takes effect quickly.
  7. Raise TTL back to your standard value. Once you're confident the change is stable and you don't need to rollback, bump the TTL back up. There's no rush — a day or two at low TTL costs very little.

Common mistakes

Lowering TTL and immediately making the change

This is the most common mistake. You lower the TTL from 86400 to 300, then immediately change the IP. But resolvers that cached the record an hour ago still have the old IP and the old TTL (86400). They won't re-query for up to 23 more hours. You didn't gain anything — the low TTL only helps resolvers that fetch the record after you lowered it.

Setting TTL to 0

TTL 0 technically means "do not cache." In practice, many resolvers treat 0 as "use my internal minimum" — which might be 30 seconds, 60 seconds, or even 300 seconds depending on the resolver implementation. Some older resolvers ignore it entirely. Don't rely on TTL 0 behaving as you expect. Use 30–60 seconds as your practical minimum.

Forgetting to raise TTL back after the change

You lower the TTL for a migration, the migration succeeds, and... you forget to raise it back. Six months later, you're paying 12x the query costs for a record that hasn't changed since the migration. Set a reminder, or better yet, schedule the TTL increase as part of your migration plan.

Not accounting for resolver minimum TTLs

Some ISP resolvers enforce a floor on TTL values — they'll cache a record for at least 30–60 seconds regardless of what your authoritative server says. This means that even with a TTL of 5 seconds, some clients won't see changes faster than every 30–60 seconds. For planning purposes, assume a practical minimum of 30–60 seconds, not whatever you set.

TTL and change control

When DNS changes go through an approval workflow, TTL becomes part of the conversation. A reviewer can look at a change request — "modify A record for api.example.com from 10.0.1.50 to 10.0.2.75" — and ask: "The TTL on this record is 86400. Shouldn't we lower it first?"

This is where pre-flight checks add real value. An automated check can warn: "You're modifying a record with a TTL of 86400 seconds. Full propagation will take up to 24 hours. Consider lowering the TTL 48 hours before this change." That warning alone prevents the most common TTL mistake.

Better still, scheduled changes can be paired with their TTL reduction. Schedule "lower TTL to 300" for Monday, then schedule "change A record to new IP" for Wednesday. Both go through approval, both are tracked, and the timing is built into the plan rather than left to memory.