Managed DNS in London: why performance, security and uptime matter

At a glance

What this is: This is a DigiCert blog post arguing that managed DNS can improve performance, security and availability for London organisations.

Why it matters: It matters to IAM and identity teams because DNS reliability and integrity underpin access paths, service trust and the resilience of machine and human-facing digital services.

By the numbers:

• A one-second delay in website loading time can result in a 7% reduction in conversions.

👉 Read DigiCert's article on managed DNS for performance, security and high availability

Context

Managed DNS is the practice of delegating DNS operations to a service that can improve routing, resilience and integrity for public-facing digital services. In this post, DigiCert links that control plane to business outcomes in London, where performance, trust and uptime directly affect customer access and conversion.

For identity and access programmes, DNS is not just a network concern. It influences how reliably users, services and security controls can reach authentication endpoints, certificate services and application entry points, which makes DNS integrity relevant to both human IAM and machine identity operations.

Key questions

Q: How should security teams govern DNS for identity-critical services?

A: Security teams should treat DNS as part of the access path and apply the same governance discipline used for certificates, federation and workload identities. That means identifying critical zones, enforcing change control, validating integrity with DNSSEC where appropriate and testing recovery for the domains that users and services must reach.

Q: Why does DNS security matter to IAM programmes?

A: DNS security matters because users and workloads must reach the right endpoint before authentication, certificate validation or API trust can work. If DNS is altered, the attacker can steer traffic to a false destination even when credentials are strong. IAM teams should therefore include DNS integrity in service assurance planning.

Q: What breaks when DNS failover is not tested regularly?

A: When failover is not tested, organisations can discover during an outage that secondary DNS serves stale records, missing entries or inconsistent responses. That can break authentication portals, application access and workload connectivity at the same moment the business most needs continuity. Failover must be validated as a live dependency, not assumed.

Q: How do teams know whether DNS governance is actually working?

A: Teams know DNS governance is working when critical records are signed, changes are attributable, failover preserves intended destinations and identity-dependent services stay reachable during disruption. The clearest signal is that DNS incidents do not cascade into login failure, certificate errors or service discovery breakdowns.

Technical breakdown

Managed DNS performance and intelligent routing

Managed DNS improves how quickly users reach a service by using intelligent routing, load balancing and CDN integration to direct requests toward healthier or closer endpoints. The operational point is not simply faster resolution, but fewer dependency bottlenecks during traffic spikes or partial outages. For organisations with global users, DNS performance becomes part of the availability design, because a slow or unstable lookup path can degrade the entire access experience before the application layer even loads.

Practical implication: map DNS latency and failover behaviour into service-level objectives, not just network monitoring.

DNSSEC, hijacking resistance and record integrity

DNSSEC adds cryptographic validation to DNS responses so clients can detect tampering or forged records. That matters because DNS hijacking does not need to break application authentication directly if attackers can steer users to a malicious endpoint first. Record integrity is especially important where DNS supports login flows, certificate validation and APIs, because a poisoned DNS answer can undermine trust in every downstream control that depends on the correct destination.

Practical implication: validate that critical domains are signed and that DNSSEC failures are monitored as security events.

Secondary DNS and failover for continuity

Secondary DNS provides an alternate source of authoritative answers if the primary DNS service, network path or server fails. Failover reduces the chance that a single outage interrupts access to public services, identity endpoints or machine-to-machine dependencies. This is a resilience control, but it also has governance value because it limits the blast radius of infrastructure failure. Where DNS supports certificates, authentication or workload connectivity, failover is part of keeping trust services reachable.

Practical implication: test failover for identity-critical domains, not only for customer-facing web properties.

NHI Mgmt Group analysis

Managed DNS is a trust-control problem as much as an availability problem. The article correctly connects DNS to performance and continuity, but the deeper issue is that DNS is part of the trust chain for every user and workload that must reach an authenticated endpoint. If the lookup layer is unstable or tampered with, identity and access controls can be bypassed before they are even exercised. Practitioners should treat DNS governance as part of the access path, not a separate infrastructure afterthought.

DNS integrity failures can create access risk without touching credentials directly. DNS hijacking, unauthorized record modification and misrouting all move the attacker’s control point upstream of the login or API call. That means the security model has to account for destination integrity, not only authentication strength. In practice, this is where DNSSEC, authoritative change control and monitoring of critical records become governance requirements rather than optional hardening.

High availability matters because identity-dependent services fail in real time, not on a maintenance schedule. If authentication, certificate validation or service discovery depends on DNS, then outage tolerance is part of identity assurance. The business case is not just continuity for the website, but continuity for the systems that prove who and what is allowed to connect. Teams should evaluate DNS as a shared dependency across human and machine identity flows.

Managed DNS creates a clearer operating model for distributed digital services, but it does not remove accountability. Outsourcing the DNS function can improve resilience and routing efficiency, yet the organisation still owns record governance, validation policy and recovery decisions. The practical conclusion is that DNS service design must sit inside the same governance discipline as certificates, federation endpoints and workload reachability.

Managed DNS exposes a distinct control gap: trust in resolution is often assumed, not verified. Many programmes secure the destination system and ignore the path used to find it. That gap becomes visible whenever a routing decision, record update or failover event can alter user trust outcomes. Practitioners should close the gap by aligning DNS operations with identity, resilience and change-control governance.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Read NHI Lifecycle Management Guide for the governance controls that reduce exposure across provisioning, rotation and offboarding.

What this signals

Managed DNS becomes a governance issue when service availability and trust depend on the same records. Teams should inventory which access paths are sensitive enough that a DNS change would become an identity event, then fold those domains into change control, monitoring and recovery testing. The organisational signal is simple: DNS ownership now belongs in the same operational conversation as certificate and federation ownership.

DNSSEC is only useful if the organisation is ready to act on validation failures. A signed zone without monitoring and response workflows creates confidence without control. Teams that want resilient access paths should align DNS change workflows with service ownership, and they should be able to show that integrity failures trigger operational response before users experience widespread disruption.

With 27 days as the average estimated time to remediate a leaked secret in our research, prolonged control gaps remain common across identity-adjacent operations. Even where DNS is not a secret itself, the lesson applies: governance breaks when operational responsibility is diffuse and recovery is slow. Practitioners should use that benchmark to pressure-test whether their DNS, certificate and identity dependencies can be corrected fast enough to matter.

For practitioners

• Classify DNS as an identity dependency Document which authentication portals, certificate services, APIs and workload endpoints depend on each critical domain or subdomain. Use that map to prioritise monitoring, change control and recovery testing for the names that would break access if altered.
• Enable DNSSEC on identity-critical zones Sign public zones that support login, federation, certificate validation or workload connectivity, and alert on validation failures. Review the full record lifecycle so that key changes cannot silently weaken destination integrity.
• Test failover for access-path services Run continuity tests for primary and secondary DNS on the domains that serve customer access, SSO flows and machine-to-machine integrations. Verify that failover preserves the intended records and does not degrade trust or route users to stale endpoints.
• Tie DNS change control to service ownership Require approval and audit trails for record changes on sensitive zones, especially where DNS supports certificates or federated access. Separate routine operational edits from emergency recovery actions so accountability remains clear during outages.

Key takeaways

• Managed DNS is not just an infrastructure choice, because DNS integrity and continuity directly affect how users and services reach trusted endpoints.
• DNSSEC and failover only reduce risk when organisations also control record changes, monitor validation failures and test recovery for identity-critical domains.
• IAM, certificate and workload teams should treat DNS as a shared dependency, because a failure in resolution can become a failure in access.

Key terms

• Managed DNS: Managed DNS is an outsourced or centrally operated DNS service that handles authoritative name resolution, routing and resilience for one or more domains. It reduces operational burden, but the organisation still owns record governance, trust decisions and recovery outcomes for the services it supports.
• DNSSEC: DNSSEC is a set of cryptographic extensions that lets DNS responses be validated as authentic and unmodified. It does not encrypt traffic, but it helps prevent forged records and DNS tampering, which makes it a core integrity control for trusted access paths.
• Secondary DNS: Secondary DNS is a backup authoritative DNS service that can answer queries if the primary service or path becomes unavailable. It improves resilience, but it must be tested because a backup that serves stale or incomplete records can still interrupt access and trust.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by DigiCert: Driving Digital Excellence in London with Managed DNS. Read the original.