DDoS attacks expose the limits of DNS resilience and access control

At a glance

What this is: This is a plain-language explainer of distributed denial-of-service attacks and how botnets flood DNS-facing services until legitimate traffic can no longer pass.

Why it matters: It matters because IAM, NHI, and resilience teams all depend on service availability, and DDoS pressure exposes where identity-adjacent systems still assume traffic will behave normally.

👉 Read DigiCert's explanation of how DDoS attacks overwhelm DNS and web services

Context

Distributed denial-of-service, or DDoS, is an availability attack that floods a target with traffic until normal users cannot get through. In the DigiCert explainer, the key failure mode is not data theft or account compromise, but service saturation at the DNS and web-server layer.

For identity teams, the important lesson is that resilience assumptions often sit beside IAM, NHI, and access controls even when the attack itself is network-led. Service continuity depends on how well DNS, routing, bot detection, and upstream access governance are coordinated before traffic spikes begin.

Key questions

Q: How should security teams reduce DDoS risk for internet-facing services?

A: Start by identifying the services that would fail first if traffic suddenly spiked, then place filtering, rate limiting, and scrubbing in front of them. DDoS defence works best when the edge can absorb or drop abusive traffic before it consumes shared capacity. Resilience testing should confirm that legitimate users still have a path during load.

Q: Why do botnets make distributed denial-of-service attacks so difficult to stop?

A: Botnets spread traffic generation across many compromised devices, which makes each source look small while the combined volume overwhelms the target. That distribution defeats simple blocking because the attack does not come from one place. Defenders need layered controls, including upstream filtering and rapid anomaly detection, not just perimeter rules.

Q: What breaks when DNS becomes the choke point during an attack?

A: When DNS is overloaded, users may be unable to resolve or reach services even if backend systems are still running. That turns a network event into a business outage because the application becomes effectively invisible. Teams should measure how quickly critical services fail over and whether alternate resolution paths actually work.

Q: Who is accountable when a DDoS outage disrupts customer access?

A: Accountability usually spans infrastructure, security, and service owners because the failure sits at the intersection of availability engineering and operational governance. If the organisation cannot absorb the traffic surge, the issue is not only the attack but the preparedness gap. Incident reviews should track which controls existed, which failed, and which recovery paths were untested.

Technical breakdown

How botnets turn traffic volume into service outage

A botnet is a distributed collection of compromised devices that can be instructed to send traffic at the same target at once. In a DDoS pattern, each node generates queries that appear individually routine but collectively exhaust server capacity, bandwidth, or application resources. The attack does not need sophistication at the packet level if the volume is high enough. The core failure is that legitimate requests compete with malicious traffic on the same path, so overload becomes a denial condition rather than a performance issue.

Practical implication: teams need upstream traffic filtering and rate controls before the request reaches shared service capacity.

Why DNS-facing services are a high-value availability target

DNS is a control point because it resolves where traffic should go, so disruption there can make an entire service appear offline even when backend systems still exist. Attackers exploit this by concentrating traffic against a small number of resolvers, authoritative services, or exposed web endpoints. Once query volume overwhelms the path, the issue moves from latency to inaccessibility. This is why DDoS is often experienced as a business outage rather than a narrow technical event: users cannot reach the service even if core infrastructure has not failed internally.

Practical implication: map which services depend on DNS availability and test failover paths under load.

What bot infection looks like in the real world

The article describes zombie computers and IoT devices that may be infected without the owner noticing. Typical warning signs include random shutdowns, slow internet, suspicious pop-ups, and inability to update operating systems. In operational terms, the device is no longer just an endpoint but a commandable traffic source inside a broader botnet. That matters because mitigation is not only about the target's edge controls. It also depends on reducing the population of exploitable devices that can be drafted into an attack.

Practical implication: strengthen endpoint hygiene and patching so compromised devices cannot become traffic amplifiers.

Threat narrative

Attacker objective: The objective is to deny legitimate access by exhausting network and server capacity until the service goes dark.

1. Entry begins when attackers compromise large numbers of computers or IoT devices and turn them into a botnet that can be remotely controlled.
2. Escalation occurs when the attacker instructs the botnet to flood the target's IP address with massive volumes of fake traffic.
3. Impact follows when legitimate users can no longer reach the website or network and the service becomes overloaded or inoperable.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

DDoS is an availability governance problem, not just a network event. The DigiCert explainer describes how traffic floods can make a service unusable even when the underlying environment is still intact. That means resilience planning has to sit alongside identity and access governance, because the business impact is measured in who can reach the service, not just what malware landed. Practitioners should treat availability as a control objective, not an afterthought.

Botnet scale is the real force multiplier. When thousands of compromised devices can be coordinated into a single traffic surge, the defender is no longer facing isolated abuse but distributed pressure. That changes how teams think about blast radius, rate limiting, and edge control design. A small set of weakly managed devices can create outsized downstream disruption, so exposure management has to include the devices that can be conscripted into attacks.

Identity-adjacent systems become part of the attack surface when DNS is the choke point. Web access, certificate verification flows, authentication redirects, and service endpoints all depend on availability at the edge. A service can have correct policy and still fail if users cannot resolve or reach it. The field should stop treating network resilience and identity governance as separate workstreams when the failure mode is service denial.

Traffic-based attacks reveal an identity blind spot in resilience planning. Most programmes are built to decide who may connect, but DDoS asks whether the environment can still serve legitimate identities when attacked at scale. That is a different control question. The practical conclusion is that governance should extend from access policy to the continuity of the access path itself.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, showing how often identity failures still sit behind broader security incidents.
• For the lifecycle angle, Ultimate Guide to NHIs , Key Challenges and Risks is the next reference point for visibility, rotation, and over-privilege.

What this signals

Traffic resilience should be treated as part of identity governance, not a separate network problem. When service availability is the control objective, teams need to ask whether legitimate identities can still reach the application path under stress. That moves DDoS from a pure perimeter concern into a governance question about continuity, ownership, and failure tolerance.

DDoS pressure exposes the hidden dependency between access controls and service reachability. Even well-designed policies fail if DNS or edge infrastructure collapses before a request is authorised or served. Practitioners should review where identity and availability controls intersect, especially for externally exposed authentication and certificate workflows.

Botnet-driven outage risk also reinforces the need for broader third-party and device governance. With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, resilience now depends on more than hardening the edge. Teams should also map which connected devices, workloads, and service relationships could amplify an external attack path.

For practitioners

• Map DNS and web service choke points Identify which resolvers, load balancers, and public endpoints would fail first under sustained query floods, then document failover paths and dependencies.
• Implement upstream traffic filtering Use rate limiting, scrubbing, and edge controls before traffic reaches shared server capacity so fake queries do not compete directly with legitimate users.
• Harden the device population that can be conscripted Patch IoT and endpoint fleets quickly, remove unnecessary remote access, and monitor for the warning signs of zombie infection described in the article.
• Test service continuity under load Run failover and stress exercises that verify legitimate users can still reach the service when DNS or application-layer traffic spikes abruptly.

Key takeaways

• DDoS attacks are designed to exhaust service capacity until legitimate users cannot get through.
• Botnets turn thousands of compromised devices into a single availability threat that can overwhelm DNS and web infrastructure quickly.
• Practitioners need layered edge controls, failover testing, and device hygiene to keep traffic floods from becoming business outages.

Key terms

• Distributed Denial-of-Service: A distributed denial-of-service attack uses many sources to send enough traffic to a target that legitimate users can no longer get through. The purpose is not theft but disruption, and the defender's problem is service exhaustion at the network or application edge.
• Botnet: A botnet is a collection of compromised devices that an attacker can remotely coordinate to carry out an attack. In DDoS scenarios, the devices act as distributed traffic generators, which makes the attack harder to block by source alone.
• Zombie Computer: A zombie computer is a device that has been infected and can be controlled without the owner's knowledge. It may appear to function normally while silently contributing resources to a botnet or other malicious activity.
• DNS Resilience: DNS resilience is the ability of naming and routing services to keep operating when traffic surges or parts of the infrastructure fail. It is a practical availability control because users cannot reach services if name resolution or edge routing breaks first.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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: What is a DDoS Attack? Read the original.