Managed DNS security and performance controls for San Jose businesses

At a glance

What this is: This is a managed DNS overview that ties performance, availability, and DNSSEC to business reliability and trust.

Why it matters: It matters because identity and trust teams increasingly inherit DNS as part of the control surface for availability, integrity, and incident resilience across human, workload, and service access paths.

By the numbers:

• Studies have shown that a one-second delay in website loading time can result in a 7% reduction in conversions.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 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 security and performance for San Jose businesses

Context

Managed DNS is the operational layer that keeps domain resolution fast, available, and trustworthy when traffic spikes or infrastructure fails. In practice, it sits close to identity and access concerns because DNS integrity affects how users, services, and security controls reach the systems they are meant to trust.

For IAM, NHI, and platform teams, the important point is that DNS is no longer just a network utility. Secondary DNS, failover, and DNSSEC shape resilience, while misconfigurations or hijacking attempts can create outages or redirect trust flows in ways that affect both human and machine access patterns.

Key questions

Q: How should security teams reduce the impact of DNS hijacking on identity and access paths?

A: Security teams should protect the DNS records that support sign-in, API access, and certificate validation first, because those zones carry the highest trust value. DNSSEC, strict change control, and monitored record updates reduce the chance that users or workloads are redirected to attacker-controlled infrastructure. The key is to treat DNS as part of access governance, not just network plumbing.

Q: When does managed DNS become part of identity governance rather than network operations?

A: Managed DNS becomes an identity governance issue when it directly affects how users, workloads, and services reach trusted endpoints. If DNS failure can interrupt authentication, certificate checks, or service-to-service communication, it belongs in the same control mapping as access and trust infrastructure. That ownership should sit with the teams that manage the availability of those trust dependencies.

Q: What breaks when DNS integrity controls are missing?

A: When DNS integrity controls are missing, attackers can redirect traffic, intercept users, or disrupt service without changing the application itself. That makes the incident harder to spot because the failure starts at resolution, not at login or authorization. In practice, the organisation loses confidence that the domain name still points to the intended service.

Q: How do you know if your DNS resilience controls are actually working?

A: You know they are working when secondary DNS, failover, and resolver monitoring keep services reachable during simulated outages, record corruption, or authority loss. Test results should show predictable resolution, minimal delay, and no manual recovery surprises. If your recovery depends on ad hoc intervention, the control is theoretical rather than operational.

Technical breakdown

Managed DNS load balancing and response-path resilience

Managed DNS load balancing distributes DNS queries across multiple servers so resolution stays responsive under traffic pressure. The practical effect is lower lookup latency and less dependence on a single resolver path. For organisations that depend on customer-facing portals, APIs, or internal service discovery, DNS responsiveness becomes part of availability engineering rather than a separate network concern. In identity-heavy environments, DNS health also influences sign-in journeys, certificate validation, and machine-to-machine reachability. If name resolution slows or fails, the access layer can look broken even when the application itself is healthy.

Practical implication: monitor DNS resolution latency and fail open only where service design can tolerate it.

Secondary DNS and failover as continuity controls

Secondary DNS provides an alternate authoritative source when the primary DNS service is unreachable, while failover shifts resolution paths during outages. This is a continuity pattern, not a performance optimisation alone. It reduces the chance that a single server failure, network issue, or regional disruption takes down a domain. For identity and trust teams, the key issue is that resilient resolution supports certificate checks, service endpoints, and access workflows that depend on predictable name resolution. Without it, availability problems can masquerade as authentication or application incidents.

Practical implication: test failover paths regularly and include DNS in incident response runbooks.

DNSSEC and protection against DNS hijacking

DNSSEC adds cryptographic validation to DNS responses so resolvers can detect tampering and unauthorized modification. It does not encrypt DNS traffic, but it does help prove that a response has not been altered in transit or at the authoritative source. That matters because DNS hijacking can redirect users and services to malicious endpoints while appearing operationally normal. For identity programmes, DNSSEC protects a trust precondition: if the lookup path is corrupted, downstream authentication, certificate trust, and workload connections can all be misled before any access control fires.

Practical implication: prioritise DNSSEC on domains that anchor login, API, and certificate validation flows.

Threat narrative

Attacker objective: The attacker wants to redirect legitimate traffic or disrupt availability by corrupting the trust path behind domain resolution.

1. Entry occurs when an attacker targets DNS infrastructure or resolution paths through hijacking, spoofing, or other manipulation of authoritative records.
2. Escalation follows when tampered responses redirect users or services to attacker-controlled endpoints, enabling credential capture or service disruption.
3. Impact is achieved when trust in the domain is undermined, leading to outage, fraud, or unauthorized traffic redirection.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Managed DNS is a trust-control problem as much as an availability problem. The article frames DNS around speed and uptime, but the governance issue is broader: DNS is a decision point that determines whether users and workloads reach the right destination at all. When resolution is manipulated, the failure occurs before conventional identity controls engage. Practitioners should treat DNS integrity as part of the access trust chain, not as a back-end utility.

DNSSEC represents integrity assurance, not just a technical hardening step. The value of DNSSEC is that it gives resolvers a cryptographic basis for rejecting altered responses, which matters when hijacking attempts target the lookup layer. That puts DNSSEC in the same governance conversation as certificate validation and service identity trust. Teams should recognise that a secure endpoint is less useful if the path used to find it is compromised.

Resolution path resilience: the hidden dependency between DNS continuity and identity workflows. Managed DNS failover, secondary DNS, and load balancing are not only uptime features. They shape whether sign-in journeys, API calls, and workload connections remain stable under stress. The practical lesson is that identity and platform teams should map which authentication and service flows depend on DNS reachability before an outage exposes the gap.

San Jose’s cloud-heavy operating model makes DNS governance more visible, not less. Technology-centric organisations often assume they can absorb DNS fragility because they have modern infrastructure. That assumption fails when the resolver path becomes the single point of trust for web traffic, APIs, and certificate validation. Practitioners should reclassify DNS as shared control infrastructure with clear ownership, testing, and incident accountability.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• A separate finding from our research shows that only 44% of developers are reported to follow security best practices for secrets management, which keeps exposure and misuse conditions persistent across environments.
• For practitioners building stronger trust paths, NHI Lifecycle Management Guide is the relevant next step for lifecycle controls around credentials and access paths.

What this signals

Resolution-path governance is becoming inseparable from access governance. As organisations distribute applications, certificates, and service endpoints across more environments, the DNS layer increasingly determines whether trusted destinations remain reachable and authentic. Teams that already use NIST Cybersecurity Framework 2.0 should map DNS continuity into protect and recover activities rather than leaving it implicit.

Trust-anchor domains deserve different treatment from ordinary web properties. Domains that support sign-in, API routing, or certificate validation should have stricter record-change controls, tighter monitoring, and explicit ownership. The practical signal is simple: if a DNS change can interrupt identity workflows, it is a governance event, not routine administration.

With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, identity and trust programmes are already dealing with more places where compromise can spread. DNS resilience is one of the few controls that can reduce the blast radius before access paths are weaponised.

For practitioners

• Map DNS dependencies across identity and service flows Identify which login pages, API endpoints, certificate checks, and internal services rely on each authoritative DNS zone so outages do not surprise the identity team. Include business-critical domains in service maps and incident exercises.
• Enable DNSSEC on trust-anchor domains Prioritise domains that support authentication, certificate validation, and customer access journeys. Validate signing, key rollover, and resolver support before assuming protection is active.
• Test secondary DNS and failover paths under failure conditions Simulate primary DNS loss, regional interruption, and record corruption to confirm that alternate resolution behaves as intended and does not create stale or inconsistent answers.
• Add DNS events to identity incident response playbooks Treat hijack, poisoning, and authoritative record changes as identity-impacting events. Ensure the response includes domain verification, certificate review, and endpoint validation before restoration.

Key takeaways

• Managed DNS is not just about speed. It is part of the trust layer that determines whether users and services reach the correct destination.
• DNSSEC, secondary DNS, and failover address different failure modes, so teams need all three in the control map rather than a single preferred tool.
• Identity and platform teams should classify DNS failures as governance events whenever they can affect authentication, certificates, or service reachability.

Key terms

• Managed DNS: Managed DNS is an outsourced or centrally operated DNS service that handles authoritative name resolution for domains. It improves operational consistency by adding features such as load balancing, failover, and policy controls, while reducing the likelihood that domain availability depends on a single fragile server path.
• DNSSEC: DNSSEC is a set of cryptographic extensions that lets resolvers verify that DNS answers have not been altered in transit or at the authoritative source. It improves integrity, not confidentiality, and is most valuable on domains that anchor login, certificate validation, or service routing.
• Secondary DNS: Secondary DNS is a backup authoritative DNS source that can answer queries if the primary DNS service is unavailable. It is a continuity control, not a security control by itself, but it becomes essential when resilience and service availability depend on uninterrupted name resolution.
• DNS Hijacking: DNS hijacking is the manipulation of DNS records, resolution paths, or upstream infrastructure so traffic is sent to an unintended destination. It can be used for fraud, malware delivery, or service disruption, and it is especially damaging when it affects domains that users already trust.

Deepen your knowledge

NHI Governance, agentic AI identity, machine identity security, IAM, and secrets management 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 governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Best Managed DNS for San Jose, California. Read the original.