Managed DNS, uptime and DNSSEC: what Chicago enterprises need

At a glance

What this is: This is a DigiCert blog post arguing that managed DNS improves performance, security, and availability for enterprise websites.

Why it matters: It matters because DNS reliability and integrity directly affect how IAM, NHI, and broader trust services remain reachable, verifiable, and resilient during outages or spoofing attempts.

By the numbers:

• Research shows that a one-second delay in website loading time can lead to a 7% reduction in conversions.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read DigiCert's blog on managed DNS, DNSSEC, and high availability

Context

Managed DNS is the layer that translates names into reachable services, and when it is slow or unreliable the business impact shows up quickly in customer experience and transaction loss. In identity and security programmes, that same layer also supports the dependable reachability of certificate services, verification endpoints, and other trust dependencies that organisations assume will simply be there.

The article treats DNS performance, DNSSEC protection, and failover as operational necessities for a modern enterprise presence. That framing is useful, but the deeper governance lesson is that resilience controls only matter when the underlying naming and resolution path is treated as part of the trust boundary rather than an IT afterthought.

Key questions

Q: How should security teams govern DNS for services that support identity and trust?

A: Security teams should treat DNS as part of the trust boundary for identity-adjacent services. That means mapping dependencies, assigning ownership, testing failover, and verifying integrity controls for zones that support authentication, certificates, and machine connectivity. If DNS fails, the control chain fails with it, even when the application itself is healthy.

Q: Why does DNS integrity matter to IAM and NHI programmes?

A: DNS integrity matters because identity workflows depend on correct name resolution to reach certificate services, login endpoints, and machine trust dependencies. If records can be spoofed or altered, users and systems may be redirected without obvious signs of compromise. That makes DNS a governance issue, not just a networking concern.

Q: When does managed DNS become a resilience control rather than a routing feature?

A: Managed DNS becomes a resilience control when service availability depends on uninterrupted resolution and rapid failover. If users, workloads, or trust validation services cannot reach the correct endpoint during a fault, then the DNS layer is part of the recovery plan. In that case, testing and ownership matter as much as routing logic.

Q: What should teams do if DNSSEC is enabled but incidents still occur?

A: Teams should assume DNSSEC is necessary but not sufficient. They need to review zone governance, resolver validation, monitoring for misconfiguration, and the security of the systems that publish records. DNSSEC protects integrity in transit, but it cannot compensate for weak administration or compromised endpoints.

Technical breakdown

Managed DNS load balancing and response-time control

Managed DNS improves service reachability by distributing lookups across healthy endpoints and reducing the time users wait for a valid response. In practice, that means the DNS layer can steer traffic away from overloaded or failing infrastructure before the application itself is visible as broken. For identity-dependent services, the value is less about marketing performance and more about preserving access to certificate validation, login-adjacent endpoints, and machine trust workflows that depend on consistent resolution. The control is only as strong as the health checks and routing logic behind it.

Practical implication: treat DNS routing as part of service continuity planning for identity and trust services, not only for web delivery.

DNSSEC and protection against spoofing

DNSSEC adds cryptographic validation to DNS responses so a resolver can verify that data was not altered in transit or replaced by a forged answer. That matters because DNS spoofing can quietly redirect users and systems to malicious infrastructure without breaking the appearance of normal connectivity. For identity teams, the real risk is not just website redirection but the compromise of trust paths that support authentication, certificate lookup, and workload connectivity. DNSSEC does not solve all DNS abuse, but it does raise the cost of tampering with the naming layer.

Practical implication: use DNSSEC where you need integrity guarantees for name resolution that underpins identity and trust operations.

Secondary DNS and failover for service continuity

Secondary DNS keeps name resolution alive when a primary server, network segment, or provider path fails. Failover works by shifting resolution to a redundant source so users and systems can still find the service even if one control plane is unavailable. In security programmes, that continuity matters because availability is a trust property: if users cannot resolve a certificate, authentication, or service endpoint, the control is effectively absent. High availability also limits the business value of disruption attempts that target the naming layer rather than the application directly.

Practical implication: test DNS failover as a resilience control for any service whose availability affects authentication or trust validation.

NHI Mgmt Group analysis

Managed DNS belongs in trust architecture, not just infrastructure operations. The article is framed around website performance, but the more important governance point is that DNS is upstream of many identity and trust workflows. If name resolution fails, spoofed records propagate, or failover is untested, the organisation loses the dependable path that other controls assume exists. Practitioners should treat DNS as a continuity dependency for identity-adjacent services, not a side utility.

DNSSEC is a control for integrity, not a complete anti-attack strategy. The post correctly points to spoofing and unauthorized modification as the problem DNSSEC addresses, but that control only protects authenticated records. It does not fix misconfiguration, endpoint compromise, or weak operational discipline around zone management. The practitioner takeaway is to align integrity controls with change governance and monitoring, because cryptographic validation cannot compensate for poor administrative hygiene.

Resolution continuity: the control that silently fails when failover is assumed. Secondary DNS and redundant routing only work when they are tested under realistic outage conditions. Many enterprises discover too late that their failover logic covers infrastructure failure but not the business processes that depend on a stable naming layer, including verification and service access. The implication is straightforward: availability planning has to include the DNS layer as a dependency, not as a separate tier.

Performance and security are coupled at the DNS layer. The article shows that latency, integrity, and availability are being sold as separate benefits, but operationally they are the same governance problem: whether the service name resolves quickly, correctly, and consistently. When that layer degrades, customer experience, trust validation, and incident response all slow down together. Practitioners should review DNS through the same resilience lens they apply to other control-plane dependencies.

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, according to The State of Secrets in AppSec.
• For practitioners, that means control-plane resilience and secrets governance need to be addressed together, especially where DNS, certificate lookup, and machine trust paths intersect with identity operations.

What this signals

Managed DNS should be treated as a dependency in identity resilience planning. If authentication, certificate validation, or service discovery rely on DNS, then latency and failover are not infrastructure-only concerns. They are programme-level issues that should appear in continuity testing, change review, and trust service ownership. The right next step is to fold DNS into the same operational map used for identity-adjacent controls, then verify the dependencies against the NIST Cybersecurity Framework 2.0.

Resolution continuity is the hidden control gap most teams under-test. A naming service can be available in the vendor console while still failing to support the actual business path users and workloads need. That is why teams should test real resolution paths, not just platform health, and compare those results with the trust requirements documented in the NIST Cybersecurity Framework 2.0.

With 43% of security professionals concerned that AI systems may learn and reproduce sensitive information patterns from codebases, according to The State of Secrets in AppSec, control-plane dependencies deserve the same scrutiny as application code. The lesson for identity teams is to track where trust services, naming services, and secrets controls intersect before an outage or exposure reveals the gap.

For practitioners

• Map DNS dependencies for identity-adjacent services Document which certificate, authentication, workload, and verification services rely on DNS resolution, then assign them to the same continuity review as other trust infrastructure. Include external dependencies, failover paths, and the operational owner for each record set.
• Validate DNSSEC on the records that matter most Confirm that high-value zones use DNSSEC and that validation succeeds from the resolvers your users and systems actually use. Pair that with change controls for zone updates so integrity is preserved both cryptographically and operationally.
• Test failover under realistic outage conditions Run resolution failover exercises that include primary server loss, network interruption, and provider-path degradation. Measure whether critical services remain discoverable, not just whether the DNS platform reports healthy.
• Track latency as a business and control-plane signal Monitor DNS response time for services where lookup speed affects conversion, login success, or certificate verification. Treat sustained latency spikes as a reliability issue that can become a governance issue if identity services depend on the same path.

Key takeaways

• Managed DNS affects more than website speed because it also supports the continuity and integrity of trust-dependent services.
• DNSSEC and failover are useful only when they are governed, monitored, and tested as operational controls rather than assumed features.
• Identity and security teams should include DNS in resilience planning wherever certificates, authentication, or machine trust depend on reliable resolution.

Key terms

• Managed DNS: Managed DNS is an outsourced or centrally operated name resolution service that handles routing, resilience, and operational oversight for domain records. In practice, it reduces the burden of running authoritative DNS while adding controls such as monitoring, failover, and policy enforcement for business-critical services.
• DNSSEC: DNSSEC is a set of cryptographic extensions that lets resolvers verify that DNS data has not been altered in transit. It protects the integrity of responses, but it does not fix poor record management, compromised publishing systems, or weak change control.
• Secondary DNS: Secondary DNS is a redundant source of authoritative records used when the primary DNS service is unavailable. It improves resilience by keeping name resolution available during outages, but it only works as intended when the failover path is tested and the records are kept in sync.
• Identity-Adjacent Service: An identity-adjacent service is any system that is not itself the identity platform but is essential to identity operations, such as certificate lookup, service discovery, or verification endpoints. These services can become governance dependencies because a failure in them interrupts trust even when authentication systems remain online.

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: Enterprise DNS for Chicago, IL: Driving Online Success. Read the original.