DNS resilience for banks is now an identity governance issue

At a glance

What this is: This is a managed DNS analysis for banks that argues DNS security and availability are foundational to customer trust and service continuity.

Why it matters: It matters to IAM practitioners because DNS failures can undermine authentication journeys, redirect users, and create availability risks that sit adjacent to identity and access controls.

👉 Read DigiCert's analysis of DNS security for banks and financial organisations

Context

DNS is the naming layer that turns a human-readable domain into the IP address a browser or app can reach. In banking, that layer affects whether customers can get to portals, complete transactions, and trust that they are talking to the right service.

The article frames DNS as a security and availability dependency, not a background utility. For IAM and security teams, that means DNS integrity, routing, and resilience belong in the same governance conversation as access paths, trust boundaries, and customer-facing authentication journeys.

Key questions

Q: How should banks govern DNS as part of identity and access security?

A: Banks should treat DNS as part of the trust path that supports identity, not as a separate infrastructure concern. Governance should cover record integrity, availability, routing ownership, and incident response so customers can reliably reach authenticated services without redirection or disruption.

Q: Why do DNS failures create identity security risk for financial organisations?

A: DNS failures can stop users reaching login pages, redirect them to malicious destinations, or break federation and transaction flows. That turns a naming problem into a trust problem, because users cannot safely complete access when the service address itself is unreliable.

Q: What breaks when DNSSEC is not operationally maintained?

A: DNSSEC loses value when signing, key rotation, or validation is inconsistent. In that state, tampering and spoofing become easier to exploit, and the organisation may believe it has integrity protection that is not actually working across the resolution chain.

Q: Who should own DNS resilience decisions in a bank?

A: DNS resilience should be jointly owned by infrastructure, security, and identity teams because it affects access paths, routing, and trust validation. Clear ownership prevents gaps where outages are handled as network issues even though they directly affect customer authentication and service access.

Technical breakdown

DNSSEC and record integrity in banking environments

DNSSEC adds cryptographic signatures to DNS records so resolvers can verify that a response was not altered in transit. That matters in banking because spoofed records and pharming attacks depend on poisoned or tampered responses that send users to a false destination. DNSSEC does not stop all attacks, but it closes one of the most direct paths for redirecting traffic away from legitimate financial services. In practice, the control only works if signing, key management, and validation are consistently maintained across the authoritative chain and downstream resolvers.

Practical implication: validate DNSSEC deployment end to end, including signing operations and resolver validation, not just zone-level enablement.

DDoS mitigation for authoritative DNS availability

Authoritative DNS is a high-value availability target because if it becomes unreachable, users cannot resolve service names even when the application itself is healthy. DDoS mitigation for DNS usually combines traffic filtering, rate limiting, and distributed infrastructure so attack volume does not exhaust the service. In financial environments, the problem is not only raw traffic volume but the business dependency on low-latency, always-on name resolution. Resilience therefore depends on redundancy, geographic spread, and operational controls that keep query handling stable under stress.

Practical implication: test authoritative DNS under load and confirm that mitigation still preserves resolution for critical banking domains.

Traffic steering and global load balancing as trust controls

Global load balancing and traffic steering route users to the nearest or healthiest endpoint based on policy, location, or availability. In banking, these functions improve performance, but they also shape which service instance a customer reaches and therefore which trust path is exercised. If the steering layer is unstable or misconfigured, users may see timeouts, failovers, or inconsistent service reachability that undermines the experience of secure access. The operational issue is not just speed, but whether routing decisions remain predictable and controlled during incidents.

Practical implication: document routing policy ownership and failure behavior so load balancing changes do not become hidden access-path failures.

Threat narrative

Attacker objective: The attacker wants to redirect banking users, disrupt access, or weaken trust in the institution's online channels.

1. Entry occurs through DNS spoofing, pharming, or a DDoS campaign that targets the naming layer rather than the banking application itself.
2. Escalation happens when tampered responses or unavailable authoritative servers interrupt legitimate resolution and steer users toward malicious or unreachable destinations.
3. Impact is service disruption, credential harvesting, financial loss, and loss of customer trust when banking access paths are no longer reliable.

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

DNS resilience is part of identity trust, not separate from it. Banking users do not experience DNS, certificates, and access control as isolated layers. They experience a single trust path from name resolution to login and transaction. When DNS is unreliable or manipulated, the identity journey fails before authorization even begins, which is why IAM and security governance should treat DNS as part of the access surface.

Availability failures create governance failures. A control stack that proves authentication but cannot reliably resolve the service name still fails the business. That is why name resolution belongs in risk and resilience discussions alongside MFA, federation, and session control. Practitioners should read DNS outages as evidence that trust controls are only as strong as the service discovery layer beneath them.

DNSSEC is a trust integrity control, but only when operationalized. The protocol protects against tampering and spoofing, yet it depends on disciplined key management and validation. The governance problem is not the protocol itself, but whether the bank can sustain it across zones, resolvers, and change windows. For practitioners, this is a lifecycle control problem as much as a cryptographic one.

Identity programmes need a shared ownership model for routing risk. DNS failures expose a gap that often sits between infrastructure teams and identity teams, with neither owning the full customer trust path. That split produces blind spots in incident planning, change control, and service recovery. The practical conclusion is that access, routing, and name resolution need one governance model for the customer-facing journey.

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 Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• For lifecycle context, NHI Lifecycle Management Guide explains how provisioning, rotation, and offboarding reduce standing exposure across non-human identities.

What this signals

DNS control is increasingly part of broader trust architecture. Banks that separate naming resilience from identity governance will keep missing failure modes that show up first as access complaints, not security alerts. The practical signal is to align DNS ownership with service access governance, especially where customer authentication depends on a stable name resolution layer.

The governance gap is often organisational rather than technical. Security may own certificates, network may own routing, and identity may own authentication, but the customer sees one experience. That makes DNS a useful stress test for how well a bank can coordinate access, availability, and incident response across teams.

Identity resilience requires visibility into the service path, not only the credential path. Our research shows only 5.7% of organisations have full visibility into their service accounts, and the same blind-spot logic applies when teams cannot see how names resolve or fail. Banks should use this as a prompt to harden the full trust chain, including operational links such as the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0.

For practitioners

• Map DNS into the identity trust path Document where DNS resolution sits in login, federation, and transaction flows so incidents can be triaged as trust-path failures, not just infrastructure outages.
• Validate DNSSEC key and signing operations Review who signs zones, who rotates keys, and how validation is monitored across authoritative and recursive layers before an outage or spoofing event exposes the gap.
• Test banking domains under DDoS conditions Run load and failover exercises against authoritative DNS so teams can confirm mitigation, redundancy, and resolver behavior for critical customer-facing domains.
• Assign routing ownership across security and infrastructure Define who approves traffic steering changes, who monitors availability impact, and how DNS changes are reviewed when they affect secure access paths.

Key takeaways

• DNS reliability affects customer trust, transaction continuity, and safe access, so banks should treat it as a security control as well as an infrastructure service.
• Spoofing and DDoS against the naming layer can disrupt banking even when applications remain healthy, which makes resilience testing and validation essential.
• Practical governance depends on shared ownership of DNS integrity, routing, and failover rather than leaving the trust path split across disconnected teams.

Key terms

• DNSSEC: DNSSEC is a set of extensions that adds cryptographic validation to DNS records so resolvers can detect tampering. In banking, it helps protect users from spoofed responses and pharming, but it only works when signing, key management, and validation are consistently operated across the resolution chain.
• Authoritative DNS: Authoritative DNS is the system that serves the official records for a domain. If it is unavailable or overwhelmed, users cannot resolve the domain even when the application behind it is healthy, which makes it a critical availability dependency for digital banking services.
• Traffic Steering: Traffic steering is the policy-driven routing of users or requests to specific endpoints based on location, health, or predefined rules. In identity-sensitive environments, it influences which service instance a user reaches and therefore which trust path and incident behavior they experience.
• DNS Spoofing: DNS spoofing is the manipulation of DNS responses so users are sent to a false destination. It is a trust-path attack, not just a network issue, because it can redirect customers away from legitimate services and create opportunities for credential harvesting or fraud.

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: Securing the Foundations: The Critical Role of DNS for Banks and Financial Organizations. Read the original.