DigiCert DNS PoP in Los Angeles raises the DNS trust bar

At a glance

What this is: This is a vendor blog about a DigiCert DNS point of presence in Los Angeles and the security and performance benefits it claims for local internet traffic.

Why it matters: It matters because DNS is part of the trust path for digital services, and IAM teams should care when infrastructure changes affect availability, routing integrity, and the reliability of certificate- and identity-adjacent systems.

👉 Read DigiCert's blog post on its Los Angeles DNS point of presence

Context

DNS is the lookup layer that maps human-readable names to network destinations. When that layer is slow, unstable, or tampered with, users experience latency and services lose trustworthiness before identity controls even come into play. For identity security teams, the operational question is not whether DNS is “just networking”, but how its availability and integrity affect access to certificates, portals, APIs, and other trust-dependent services.

This article frames DigiCert's Los Angeles DNS point of presence as a performance and resilience improvement for regional traffic. The deeper governance issue is that faster routing and stronger DNS handling can reduce exposure to hijacking and disruption, but they do not replace identity controls around certificates, secrets, or privileged administrative access.

Key questions

Q: How should security teams govern DNS when it supports authentication and certificate services?

A: Security teams should treat DNS as part of the identity trust path, not a separate infrastructure concern. That means identifying which authentication, certificate, and admin workflows depend on resolution, then applying change control, privileged access review, and outage testing to those dependencies. The goal is to make DNS tampering or failure visible before it affects access decisions.

Q: Why does DNS performance matter to IAM and security architecture teams?

A: DNS performance matters because latency and failure at the lookup layer affect whether users can reach SSO, certificate checks, APIs, and admin portals at all. IAM teams do not own DNS end to end, but they do own the trust services that depend on it. Poor DNS handling can therefore become an access and availability problem, not just a network one.

Q: What breaks when DNS administration is not governed as privileged access?

A: When DNS administration is not governed as privileged access, attackers or insiders can redirect traffic, interrupt resolution, or alter trust paths without touching the application itself. That creates a failure mode where users still see the brand but reach the wrong endpoint or none at all. The control gap is not visibility alone, but authority over configuration changes.

Q: How do teams distinguish better DNS routing from stronger security?

A: Better routing reduces delay and can improve resilience, but it does not prove that access to DNS control planes is properly limited or reviewed. Stronger security requires knowing who can change records, how those identities are authenticated, and whether tampering is detected quickly. In practice, routing quality and governance quality should be measured separately.

Technical breakdown

How DNS point of presence design affects latency and reachability

A DNS point of presence, or PoP, places resolver capacity closer to users so queries can be answered with fewer network hops. That can reduce lookup latency and improve perceived application speed, especially where traffic is geographically concentrated. The design choice matters because DNS is upstream of nearly every digital service interaction: if name resolution is slow, the rest of the stack waits. The article also points to optimized routing, which means steering queries along more efficient network paths rather than relying on a single distant resolver path.

Practical implication: measure DNS resolution performance separately from application performance so you can identify whether slow access is really a name-resolution problem.

DNS hijacking, DDoS, and why trust depends on the lookup layer

DNS hijacking occurs when an attacker redirects name resolution to an unintended destination, while DDoS attacks overwhelm infrastructure so legitimate queries cannot be answered reliably. Both issues can make a service appear unavailable or untrustworthy even when the application itself is intact. In identity-adjacent environments, that is especially relevant because users may never reach SSO, certificate checks, or login endpoints. Security claims around DNS should therefore be evaluated as control-path protection, not just as bandwidth or cache efficiency.

Practical implication: include DNS integrity and availability in resilience planning alongside authentication, certificate, and secrets controls.

Why faster DNS is not the same as better identity security

Improving DNS speed can reduce friction and exposure time, but it does not solve governance problems such as over-privileged admin access, weak certificate lifecycle control, or unmanaged secrets. The article's performance framing risks blurring a distinction practitioners need to keep clear: infrastructure quality helps protect the path, while identity governance protects who can change that path. If a DNS environment is compromised, the failure is often not speed but control over privileged actions and configuration changes.

Practical implication: separate network performance ownership from privileged access governance so DNS operations do not become an uncontrolled trust boundary.

NHI Mgmt Group analysis

DNS is a trust boundary, not a background utility. When resolution quality degrades, users experience failure before identity systems can enforce policy. That makes DNS part of the practical trust path for SSO, certificate validation, and service access, even if it sits outside the IAM console. Practitioners should treat DNS resilience as part of identity service dependability.

Security claims about DNS should be judged by control over change, not by proximity alone. A regional PoP can improve performance and reduce exposure to disruption, but it does not in itself prove governance over resolver changes, routing decisions, or privileged administration. The important question is who can alter the trust path and how that access is reviewed. Practitioners should separate infrastructure locality from authoritative control.

Identity programmes increasingly depend on adjacent infrastructure that is not owned by IAM teams. Certificate verification, authentication endpoints, and administrative portals all inherit risk from the name-resolution layer beneath them. That means IAM, security architecture, and network teams need a shared model for service reachability and tamper resistance. Practitioners should map DNS ownership into identity service dependencies.

Latency reduction can mask governance debt if teams confuse speed with assurance. Faster resolution helps user experience, but it does not address weak offboarding, stale credentials, or poor change control in the systems that manage DNS. This is where identity discipline matters: operational polish is not the same as controlled access. Practitioners should avoid letting performance improvements substitute for privilege governance.

Top 10 NHI Issues remains relevant whenever infrastructure changes affect trust operations. DNS administration often involves service accounts, automation tokens, and privileged credentials that are easy to under-govern once the focus shifts to uptime. The control problem is rarely the query path itself, but the identities allowed to modify it. Practitioners should review NHI exposure wherever DNS is operated through automation.

From our research:

• From our research: 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.
• Our research also shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader governance view, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding control patterns.

What this signals

DNS reliability should now be treated as an identity service dependency. As more authentication and certificate workflows depend on stable name resolution, teams should inventory DNS as part of service-critical access paths rather than leaving it in network silos.

The practical signal is not whether a PoP exists, but whether privileged changes to DNS are traceable, reviewed, and recoverable. When identity and infrastructure teams share ownership of the trust path, failures become easier to isolate and contain.

A useful frame here is the trust-path concept: the systems that translate names, validate certificates, and deliver login endpoints all need explicit governance because they shape whether users ever reach policy enforcement.

For practitioners

• Map DNS into identity dependency chains Document which authentication flows, certificate services, and administrative portals rely on DNS resolution so outages and tampering are evaluated as identity-service risks, not just network incidents.
• Separate performance monitoring from integrity monitoring Track query latency, resolution failures, resolver changes, and unexpected routing shifts as distinct signals so faster responses do not hide weak control over the trust path.
• Review privileged DNS administration identities Confirm which service accounts, API tokens, and human admins can change DNS configuration, then apply least privilege and regular access review to that control plane.
• Test recovery paths for DNS disruption Run exercises that simulate hijacking, resolver outage, or DDoS pressure and verify that certificate validation, login, and customer-facing services fail safely rather than silently.

Key takeaways

• DNS now sits close to the identity trust path, so outages or tampering can undermine access before IAM controls are reached.
• Performance improvements help user experience, but they do not replace privileged access governance over DNS administration and routing changes.
• Identity teams should map DNS dependencies, review control-plane privileges, and test recovery so trust does not rely on speed alone.

Key terms

• Domain Name System: The Domain Name System is the naming service that translates human-readable domain names into network addresses. It is a core dependency for web access, email delivery, and many identity services, so failures or tampering at this layer can affect both availability and trust.
• DNS Point of Presence: A DNS point of presence is a geographically placed resolver or service node that answers queries closer to users. It is used to reduce latency, improve resilience, and distribute traffic, but it still requires strong governance over who can change configuration and routing.
• Identity Trust Path: An identity trust path is the chain of systems that a user or workload must traverse before an access decision is enforced, such as DNS, certificate validation, and SSO endpoints. If any link in that chain is weak, the integrity of the overall identity flow is reduced.

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: Empowering Online Experiences in Los Angeles, California with DigiCert DNS. Read the original.