Notifications
Clear all
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.
NHIMG editorial — based on content published by DigiCert: What is TTL?
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should teams choose DNS TTL values for records that change often?
A: Choose TTL based on how quickly a record must reflect change and how much stale data the service can tolerate.
Q: Why do long DNS TTL values create operational risk?
A: Long TTL values extend the period during which resolvers can serve outdated answers after a record changes.
Q: What breaks when TTL is set too low across an entire domain?
A: Very low TTL values drive more frequent DNS lookups, which increases query volume and can raise cost or stress authoritative infrastructure.
Practitioner guidance
- Inventory records by change frequency Separate static records from mission-critical or frequently updated records, then assign TTL policy based on how often each one realistically changes.
- Lower TTL before planned cutovers Reduce the TTL on records that will change, wait for the existing cache to expire, and only then make the configuration change.
- Set a floor for resolver compatibility Avoid TTL values below 30 seconds because many resolvers will not honour shorter durations consistently.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- Record-type examples for A, MX, and TXT configurations and why their TTL needs differ
- Practical guidance on lowering TTL before a planned DNS change and then restoring it afterward
- Examples of how TTL choices affect propagation timing, resolver refresh behaviour, and query volume
- The source article's plain-language explanation of where shorter TTLs help and where they become counterproductive
👉 Read DigiCert's guide to DNS TTL values and propagation timing →
DNS TTL and propagation speed: are your change windows safe?
Explore further
25/06/2026 3:02 am
TTL is a governance control, not just a performance setting. The article treats TTL as a technical caching parameter, but in identity-adjacent environments it functions as a policy decision about how long the organisation is willing to tolerate stale truth. That matters anywhere DNS changes affect authentication, routing, or service discovery. The practical conclusion is that TTL belongs in change control, not in a default template that nobody revisits.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: When should security and infrastructure teams lower TTL before a change?
A: Lower TTL before planned migrations, failovers, or record corrections when the existing cache could otherwise keep users on the wrong destination. Then allow the old TTL to expire before completing the switch. That sequence reduces the chance of mixed answers during cutover.
👉 Read our full editorial: DNS TTL governs propagation speed, caching, and change control
