Notifications
Clear all
Topic starter
23/06/2026 7:06 pm
TL;DR: DNS record changes can take minutes to hours to propagate because resolvers and browser caches keep serving old values, and lower TTL settings can materially reduce the risk of downtime, according to DigiCert. The governance lesson is that DNS changes are not instantaneous state changes, they are identity and routing transitions that must be planned, staged, and observed.
NHIMG editorial — based on content published by DigiCert: Guide: How to Change DNS Records Safely
By the numbers:
- organizations that proactively adjust TTL values experience up to 75% less downtime during DNS record modifications compared to those who don't optimize their TTL settings.
Questions 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.
Q: Why do DNS changes sometimes keep pointing users to the old service?
A: Because caches keep returning the previous answer until the TTL expires.
Q: What breaks when DNS change controls are too loose?
A: Loose controls increase the chance that a bad or unauthorised record update redirects traffic, exposes users to stale endpoints, or creates avoidable service interruptions.
Practitioner guidance
- Lower TTL before the change window Set the record TTL to a short value before the planned update, then wait for the previous TTL period to expire before switching the destination.
- Stage the new destination first Bring the replacement service or IP address online and verify it before modifying the DNS record so cached traffic does not land on an unprepared endpoint.
- Monitor propagation across regions Check resolution behaviour from multiple geographies and resolver types so you can see where cached answers still point to the old target.
What's in the full article
DigiCert's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step TTL reduction and restoration sequence for planned DNS changes
- Practical notes on propagation timing, caching behaviour, and why updates appear delayed
- DigiCert's control-oriented view of centralized DNS management, monitoring, and access control
- The article's examples of traffic routing and DNSSEC-related operational safeguards
👉 Read DigiCert's guide on changing DNS records safely →
DNS record changes without downtime: what changes for teams?
Explore further
25/06/2026 2:56 am
DNS change safety is a trust-governance problem, not just an uptime problem. The article shows that stale DNS answers persist because distributed caches honour prior state for a period of time. That means the organisation is managing a transition in trust and reachability, not simply editing a configuration value. For identity teams, the relevant question is who can move traffic, how fast the change becomes effective, and how quickly the organisation can prove the new state is authoritative.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most identity teams still operate with incomplete machine-identity inventories.
A question worth separating out:
Q: What should identity and security teams review after a DNS record change?
A: They should review whether the new endpoint is live, whether caches have converged, whether the change was approved, and whether access logs show the update was made by the right operator. If the record supports authentication or service routing, the review should also confirm that dependent identity flows still work.
👉 Read our full editorial: DNS record changes safely: TTL, caches, and downtime control
