Notifications
Clear all
Topic starter
23/06/2026 7:06 pm
TL;DR: A multi-day Dyn/Oracle DNS outage delayed record updates, left customers unable to use the portal and API, and created the kind of operational disruption that can cascade into service downtime and lost sales, according to DigiCert. The real lesson is that identity and access programmes must treat DNS control paths as critical operational dependencies, not just infrastructure plumbing.
NHIMG editorial — based on content published by DigiCert: Dyn/Oracle DNS Outage and the importance of instant DNS propagation
By the numbers:
- DigiCert DNS has a 12-year track record of 100% uptime.
- DigiCert DNS is more than twice as fast as Dyn DNS, with an average query resolution of 17.95ms compared to Dyn / Oracle’s 46.86ms.
Questions worth separating out
Q: How should security teams plan for DNS outages that block record updates?
A: They should treat DNS update capability as a recoverable control, not a background utility.
Q: When do TTL settings create more risk than they reduce?
A: TTL settings create more risk when they are longer than the organisation’s practical recovery window or when teams assume they can override cached responses during an outage.
Q: What breaks when managed DNS control planes are unavailable?
A: The immediate failure is operational, not just technical.
Practitioner guidance
- Test DNS failover paths under control-plane loss Run exercises where the authoritative update interface is unavailable and verify that teams can still restore routing through alternate procedures, documented access, and pre-approved changes.
- Align TTL settings with recovery objectives Map TTL values to outage response targets so that cached records do not outlive the practical window in which your team expects to redirect traffic.
- Include DNS update authority in incident runbooks Document who can change records, what approval exists during an outage, and how to validate propagation before declaring service restored.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- The vendor's explanation of its instant propagation behaviour and how TTL interacts with record changes.
- Performance comparison details between DigiCert DNS and Dyn DNS, including query-resolution timings.
- Migration support information for customers moving away from Dyn-managed DNS.
- The specific service claims and uptime framing that underpin the vendor's positioning.
👉 Read DigiCert’s analysis of the Dyn DNS outage and instant propagation →
DNS propagation outages: what IAM and NHI teams should notice?
Explore further
25/06/2026 2:56 am
DNS control-plane availability is a governance dependency, not a convenience feature. This outage shows that the authority to change records is as operationally important as the records themselves. When the portal and API fail, the organisation loses the ability to move traffic, correct mistakes, and support recovery. Practitioners should treat the DNS change path as part of the trust boundary.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to NHI Lifecycle Management Guide.
A question worth separating out:
Q: Who is accountable when DNS propagation delays extend an outage?
A: Accountability usually sits with the team that owns the routing control plane and the recovery process around it. If DNS updates, approvals, or validation steps are not defined, outage duration can expand without a clear owner for the delay. Governance should assign both control ownership and restoration responsibility.
👉 Read our full editorial: DNS propagation outages expose identity and access dependencies
