Notifications
Clear all
Topic starter
23/06/2026 7:04 pm
TL;DR: A Denver point of presence has been added to DNS Made Easy and Constellix DNS, bringing the network to 24 global DNS PoPs and 550 Gbps of total peer capacity, with reported Colorado speed improvement from 18.78 ms to 15.39 ms, according to DigiCert. The governance lesson is that routing resilience and availability are operational identity-adjacent concerns, because DNS remains a control plane dependency for access, trust, and service reachability.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- The current deployment at 910 Telecom in Denver marks the 24th global DNS PoP and adds 10 Gbps of peering to its AS16552 network.
- Colorado DNS speeds improved from an average of 18.78ms before installation to 15.39ms after the Denver PoP was added.
Questions worth separating out
Q: How should security teams account for DNS in identity resilience planning?
A: Security teams should treat DNS as a dependency of identity, not a separate infrastructure concern.
Q: When does DNS performance become an access and trust problem?
A: DNS becomes an access and trust problem when latency or routing instability delays authentication, verification, or service connection long enough to affect user and application outcomes.
Q: What breaks when a single DNS region carries too much traffic?
A: A single overloaded DNS region can create a hidden bottleneck for identity and application delivery.
Practitioner guidance
- Map DNS dependencies to identity services Identify which authentication, federation, certificate, and SaaS access flows depend on external DNS resolution, then document the regional failure points that could interrupt them.
- Test regional failover paths for lookup-heavy services Simulate a DNS PoP outage or regional congestion event and confirm that access, validation, and service routing continue without manual intervention.
- Review peering and capacity assumptions regularly Track whether DNS traffic growth, geographic expansion, and user concentration are outpacing the current peering and routing design.
What's in the full announcement
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- Local performance comparison data for the Denver deployment versus other PoP regions
- The company’s explanation of how the new Denver site fits into its broader North American footprint
- Specific peering and routing details behind the 550 Gbps AS16552 network capacity
- The published speed visuals and regional coverage context used to support the deployment
👉 Read DigiCert's blog post on the Denver DNS point of presence →
Denver DNS PoP: what it means for resilience and routing?
Explore further
25/06/2026 2:52 am
DNS resilience is part of identity resilience. Access management, federation, certificate validation, and trust services all assume that name resolution is available and consistent. When DNS performance degrades, the failure shows up as login friction, failed callbacks, or broken service-to-service connectivity, not as a DNS-only outage. Practitioners should treat DNS topology as an identity dependency map, not just an internet routing map.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: What should IAM and security teams do after a DNS footprint expands?
A: They should reassess which identity and trust services depend on that DNS footprint, then confirm regional coverage, failover behaviour, and monitoring thresholds. Expansion is useful only if the new topology is reflected in continuity plans and incident runbooks. Otherwise, the organisation may still have untested single points of failure.
👉 Read our full editorial: DigiCert DNS Made Easy expands Denver presence for DNS resilience
