Topic starter
23/06/2026 7:10 pm
TL;DR: TTL sets how long DNS resolvers cache records before refreshing them, shaping both propagation speed and query volume. DigiCert notes that common values range from 30 to 86,400 seconds depending on record volatility and mission-critical change needs. The governance lesson is simple: DNS change timing is a control decision, not a convenience setting.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “What is TTL?”.
By the numbers:
- TTL values between 3,600 and 86,400 seconds are commonly used for MX and TXT records.
- Lower TTL values are generally between 30 and 300 seconds for mission-critical services and DNS load balancing.
Key questions
Q: How should security teams choose TTL values for DNS records?
A: Choose TTL values based on record volatility and business impact.
Q: Why does lowering DNS TTL make change windows safer?
A: Lowering TTL reduces the time resolvers can keep stale data, so new records propagate faster after a change.
Q: Where do teams usually get DNS TTL management wrong?
A: The common mistake is changing the record before the existing cache has expired.
Practitioner guidance
- Standardize TTL bands by record class Assign higher TTLs to stable MX and TXT records, and lower TTLs to mission-critical or frequently changing records so the setting reflects volatility rather than habit.
- Lower TTL before planned DNS changes Reduce TTL ahead of a cutover, wait for caches to expire, and only then publish the new record so old values do not linger through the change window.
- Document cache-lag expectations in change runbooks Write expected propagation delay into release steps for DNS-backed services so operations teams know when to verify, roll forward, or roll back.
Bottom line: DNS TTL governs how long resolvers can keep stale DNS data, so it directly shapes propagation speed and change visibility.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:02 am
DNS TTL is a governance control, not a convenience setting: The article makes clear that TTL determines how long stale DNS state can persist, which means it directly shapes how predictable a change window really is. That is a governance problem because teams often think in terms of making a DNS edit, when the real control question is how long the old value will remain operationally valid. Practitioners should treat TTL as part of service change authority, not a tuning detail.
A question worth separating out:
Q: How should teams change DNS records without causing downtime?
A: Reduce the record TTL before the change, wait for the old TTL to expire, make the update, and then confirm propagation before restoring the normal TTL. Teams should also stage the new destination before traffic can reach it and monitor resolution from multiple regions so cached answers do not create avoidable outages.
👉 Read our full editorial: DNS TTL governs propagation speed, caching, and change control