DigiCert DNS Made Easy expands Denver presence for DNS resilience

At a glance

What this is: DigiCert expanded its DNS footprint with a Denver point of presence to improve routing performance, redundancy, and lookup speed.

Why it matters: For IAM and security teams, DNS resilience matters because identity, trust, and service access all depend on fast, reliable name resolution and stable control-plane connectivity.

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.
• According to Statista, 94.9% of households in Colorado have a computer, and 89.6% have a broadband internet subscription.
• 8th in the United States for overall internet, the United States for overall internet usage penetration at 85.4%.

👉 Read DigiCert's blog post on the Denver DNS point of presence

Context

DNS resilience is a control-plane issue, not just a performance metric. When name resolution slows or becomes unavailable, users feel it as latency, but identity and security teams feel it as authentication friction, access failures, and reduced trust in critical services.

This post examines DigiCert DNS Made Easy's Denver point of presence as an infrastructure change with governance implications. The practical question for practitioners is how regional DNS redundancy supports availability, routing stability, and the reliability assumptions embedded in access and trust workflows.

Key questions

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. Federation endpoints, certificate checks, application entry points, and service-to-service access all rely on stable resolution. If DNS is slow or unavailable, access can fail even when IAM controls are healthy. Resilience plans should therefore include regional redundancy, failover testing, and dependency mapping.

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. In practice, that means slow resolution can look like login failure, expired callbacks, or broken secure channels. Teams should measure DNS as part of service availability and identity continuity.

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. Users may see timeouts, applications may fail to resolve dependencies, and security workflows that expect quick name resolution can stall. The issue is not only outage risk. It is the concentration of trust and reachability in one path.

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.

How it works in practice

How a DNS point of presence changes lookup performance

A DNS point of presence is a geographically distributed node that answers queries closer to users, reducing network distance and often improving latency. In managed DNS, PoPs also add routing diversity, so traffic can shift away from congestion or local path issues. The result is not only faster lookups but also a more resilient resolution path when one region experiences instability. For teams that depend on authentication, federation, or application entry points, DNS performance is part of service continuity, not a separate concern.

Practical implication: map identity and application dependencies to DNS regions so outages or routing defects do not become access incidents.

Why peering capacity matters for resilient DNS routing

Peering capacity determines how much traffic a DNS network can exchange efficiently with upstream and interconnection partners. More capacity can reduce congestion, improve route selection, and create more headroom during traffic spikes or regional failover. The operational issue is that DNS traffic often looks lightweight until an incident concentrates demand on a small number of resolution paths. When capacity is undersized, a lookup system can fail indirectly by becoming slow enough that users and services time out before they authenticate or connect.

Practical implication: review DNS capacity as part of resilience planning, not only as a network engineering metric.

Why DNS availability is relevant to identity and trust workflows

Identity systems rely on DNS for federation endpoints, certificate validation, directory lookups, SaaS access, and security controls that assume stable name resolution. If DNS becomes unreliable, the blast radius extends beyond the resolver itself into access management, service health checks, and trust establishment. This is why DNS redundancy belongs in the same conversation as availability for IAM, PAM, and digital trust programs. The control is not just uptime for websites; it is continuity for the lookup layer beneath access and verification.

Practical implication: include DNS in identity service continuity tests, especially where authentication and trust validation depend on external resolution.

NHI Mgmt Group analysis

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.

Regional PoPs reduce the operational distance between users and trust infrastructure. That matters because latency is not a cosmetic issue when authentication, verification, or application routing sits on top of DNS. The Denver deployment illustrates how distributed resolution can reduce regional concentration risk and improve user experience without changing the identity stack itself. Practitioners should evaluate whether their own access and trust services are over-dependent on a small number of resolution paths.

Identity and availability controls fail together when the control plane is under-designed. DNS may sit outside the IAM toolchain, but the service outcomes are tightly coupled. If a region loses resolution capacity, teams can lose access even when authentication and authorisation systems are healthy. Practitioners should fold DNS redundancy into identity and digital trust governance rather than leaving it in a separate network silo.

Regional infrastructure changes should be read as governance signals, not just performance updates. A larger PoP footprint indicates that service reachability, failover routing, and end-user latency are being managed as first-order operational risks. For security and IAM leaders, the question is whether critical identity-adjacent dependencies have the same level of redundancy discipline. Practitioners should pressure-test those dependencies before they become service incidents.

From our research:

• 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.
• If your DNS and identity services are coupled to secret-bearing automation, the lifecycle issue is not just availability but rotation, offboarding, and recovery discipline, as outlined in the NHI Lifecycle Management Guide.

What this signals

DNS redundancy is increasingly an identity control issue, not just a network control issue. As access, federation, and certificate validation become more distributed, practitioners need to watch for hidden dependencies that can turn a routing defect into an access defect. The governance question is whether your identity programme assumes the resolution layer is always available, or whether it has actually been tested under regional failure conditions.

A practical sign of maturity is whether identity and trust teams can explain which services fail first when DNS degrades. If the answer is unclear, the organisation has not mapped its operational dependencies deeply enough. That gap matters because the same outage can affect user access, machine access, and third-party trust at once.

For practitioners

• 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.
• Include DNS in identity continuity exercises Add DNS dependency checks to IAM and digital trust recovery exercises so teams see the access impact before a real incident exposes it.

Key takeaways

• DNS performance is part of identity resilience because access, federation, and trust all depend on reliable name resolution.
• Distributed PoPs and higher peering capacity reduce regional concentration risk, but only if continuity plans reflect the new topology.
• Practitioners should test DNS failure paths alongside IAM and digital trust workflows so access problems do not surface only during an incident.

Key terms

• DNS point of presence: A DNS point of presence is a geographically located server site that answers name-resolution requests closer to users or workloads. It improves latency and can improve resilience by giving traffic more than one resolution path when a region or route becomes congested or unavailable.
• Peering capacity: Peering capacity is the volume of traffic a DNS network can exchange efficiently with upstream networks and interconnection partners. Higher capacity gives the resolver more headroom during demand spikes and reduces the chance that lookup traffic becomes a bottleneck for access or service continuity.
• Identity dependency mapping: Identity dependency mapping is the practice of identifying which external services identity and trust workflows rely on, including DNS, certificate validation, federation endpoints, and directory lookups. It helps teams see where infrastructure failures can turn into access failures even when IAM systems themselves are healthy.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: DigiCert DNS Made Easy announces new Denver point of presence. Read the original.