DNS amplification attacks expose the limits of open resolver control

At a glance

What this is: This is an explanation of how DNS amplification attacks use open resolvers and spoofed source addresses to turn small queries into oversized reflection floods.

Why it matters: It matters because DNS is part of the control plane for every IAM, NHI, and autonomous workload environment, and a resolver weakness can disrupt authentication, service reachability, and identity-dependent operations.

By the numbers:

• Although data from DigiCert's UltraDDoS Protect biannual analyst report shows that DNS amplification accounted for just 4.44% of DDoS vectors observed in the first half of 2025.
• With the ability to multiply attack traffic by 50x or more, DNS amplification can cripple networks in minutes if left unchecked.
• For example, a 60-byte query that triggers a 4,000-byte response yields an amplification factor of roughly 66x.

👉 Read DigiCert's explanation of DNS amplification attacks and mitigation

Context

DNS amplification is a reflection attack that uses public DNS infrastructure to turn a small spoofed query into a much larger response sent to the victim. The security problem is not just bandwidth consumption, but the fact that open recursion and poor source-address validation let third parties weaponise infrastructure that should only answer legitimate lookups.

For identity and access teams, this is an availability and trust issue as much as a network issue. DNS outage or degradation can interrupt SSO, federation, certificate validation, API reachability, and machine identity workflows, so resolver hardening belongs in the same operational conversation as IAM resilience.

Key questions

Q: What breaks when DNS resolvers are open to recursion from any source?

A: Open recursion turns your DNS infrastructure into a reflection tool that can be abused by attackers to amplify traffic toward a victim. It increases bandwidth consumption, raises outage risk, and can disrupt DNS-dependent services such as authentication, certificate validation, and API lookups. The fix is to restrict recursion to intended clients and verify it stays that way after changes.

Q: Why do DNS amplification attacks cause so much damage from such small requests?

A: They exploit the difference between a tiny spoofed query and a much larger DNS response. Because the response is sent by the resolver, not the attacker, the victim absorbs traffic it did not request. The result is a low-cost attack for the adversary and a high-cost outage risk for the target.

Q: How can security teams tell whether DNS amplification is happening in real time?

A: Look for unusual spikes in UDP port 53 traffic, high volumes of responses that do not match legitimate query patterns, and repeated resolver replies from sources that should not be serving that workload. Baselines matter because normal DNS traffic is usually stable, while amplification creates abrupt, asymmetric changes in response volume.

Q: Who is accountable when a DNS amplification attack takes a service offline?

A: Accountability usually spans network operations, DNS platform owners, and the provider or ISP that can enforce anti-spoofing and edge mitigation. The practical question is whether the organisation had clear ownership for resolver hardening, response limits, and source-address validation before the outage occurred. That ownership model should be documented before an incident tests it.

Technical breakdown

How spoofed queries turn DNS into a reflection vector

DNS amplification depends on source IP spoofing and on resolvers that answer requests from arbitrary addresses. The attacker forges the victim's IP in a small query, often from a botnet, and the resolver sends the larger response to the victim instead of the requester. The amplification comes from the protocol itself, especially when queries elicit large record sets such as ANY responses, DNSSEC signatures, or oversized TXT records. The attacker spends little bandwidth, while the victim absorbs the flood.

Practical implication: block spoofed source addresses with ingress and egress filtering and disable recursion where it is not required.

Why open resolvers and large responses increase blast radius

An open resolver is any DNS server that will answer queries from any source without tight access controls. That makes it a ready-made reflection amplifier. Response size matters because the attack scales with the ratio between query and reply, so features like EDNS0, DNSSEC, and large record sets can make one request far more expensive than the attacker input. The risk is not only the resolver itself, but also the downstream networks that can be saturated by repeated reflected responses.

Practical implication: audit authoritative and recursive DNS roles separately, then cap response size and response rates where the software supports it.

How DNS detection and mitigation work at the network edge

Detection starts with baselining normal DNS behaviour and looking for sudden spikes in UDP port 53 traffic, large response volumes without matching query volumes, and repeated responses from resolvers that should not be serving that pattern. Mitigation then moves to rate limiting, traffic filtering, and anycast or scrubbing capacity that can absorb or divert the flood before it reaches the target. DNS monitoring alone is not enough if the resolver estate remains open to abuse.

Practical implication: tie DNS telemetry to DDoS response playbooks and test whether your provider can absorb reflection traffic before you need it.

Threat narrative

Attacker objective: The attacker aims to deny service by overwhelming the victim's network and DNS-dependent operations with reflected traffic.

1. Entry begins when the attacker spoofs the victim's source IP in a DNS query and sends it to open resolvers.
2. Escalation occurs when those resolvers return large responses, multiplying the attack volume through reflection.
3. Impact follows when repeated amplified responses exhaust bandwidth, degrade name resolution, and push services offline.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Open recursion is not a nuisance setting. It is a standing trust decision. DNS amplification succeeds because some resolvers still answer queries from any source, effectively volunteering to amplify third-party traffic. That is a governance failure, not just a configuration lapse, because it expands the attack surface of the whole environment. The practitioner conclusion is that resolver admission policy belongs in the same risk register as other externally reachable identity services.

DNS availability is part of identity resilience. If resolver capacity collapses, authentication flows, certificate checks, API calls, and service-to-service lookups can fail even when core IAM platforms remain up. That means DNS hardening must be treated as a dependency control for human identity, NHI, and autonomous workloads alike. The practitioner conclusion is to map which identity workflows fail when DNS degrades, then prioritise those paths in resilience planning.

Amplification factors create an identity blast radius problem. A small misconfiguration can be turned into a disproportionate outage because attackers exploit the gap between request size and response size. That is the same structural pattern identity teams see when a single over-permissive service account or token can be reused at scale. The practitioner conclusion is to treat blast radius as a first-class control objective across both DNS and NHI governance.

Source-address validation is a prerequisite for trustworthy network behaviour. BCP 38 style filtering matters because spoofing is what lets reflection attacks evade accountability and misroute the response. Without it, defenders are left to absorb traffic that was never meant for them. The practitioner conclusion is to verify that upstream providers and internal networks actually enforce anti-spoofing controls, not merely document them.

DNS hardening is a lifecycle problem, not a one-time fix. Open recursion, response size, and rate-limit settings drift over time as zones change, services are added, and operations teams move fast. That makes ongoing audit discipline essential. The practitioner conclusion is to embed DNS review into change management and access governance so the configuration stays aligned with intended trust boundaries.

From our research:

• 19% of organisations give AI systems dramatically more access than human employees, according to the 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• For the wider governance angle, see OWASP NHI Top 10 for how runtime identity risks are framed across agentic systems.

What this signals

Identity teams should treat DNS resilience as part of workload governance. DNS failures do not stay confined to networking when service discovery, federation, and certificate flows depend on them. That is why availability planning for identity infrastructure has to include resolver hardening, anti-spoofing enforcement, and edge mitigation capacity, not just IAM policy design.

Reflection attacks and agentic access share the same blast-radius lesson. A small control failure can cascade into a large-scale operational event when the attacker, or the workload, can multiply the effect of one action. With 19% of organisations giving AI systems dramatically more access than human employees, per the 2026 Infrastructure Identity Survey, the broader lesson is that trust boundaries are only useful when they are enforced at runtime.

Teams need to watch for trust drift in infrastructure that is assumed to be stable. Open recursion, oversized responses, and misaligned provider settings often survive because they sit outside normal IAM review cycles. That creates a governance gap between what the architecture assumes and what the environment actually permits.

For practitioners

• Disable open recursion on authoritative servers Separate authoritative and recursive roles, then confirm that authoritative servers do not answer arbitrary external recursion requests. Re-test after every zone or platform change, because misconfiguration often returns during maintenance.
• Enforce ingress and egress source filtering Apply BCP 38 style anti-spoofing controls with your ISP and internal network teams so forged source addresses cannot enter or leave your environment. This directly reduces the ability to launch reflection traffic from your assets.
• Set response rate limits and size controls Tune RRL and review whether DNSSEC, ANY queries, and oversized TXT records are creating avoidable amplification potential. Validate that legitimate traffic still resolves cleanly under normal load.
• Baseline DNS traffic and alert on reflection patterns Watch for sudden spikes in UDP port 53 traffic, responses without corresponding legitimate queries, and repeated resolver responses from unexpected sources. Feed those signals into your DDoS playbook before services start degrading.
• Audit DNS exposure on a fixed cadence Schedule recurring reviews of public resolvers, access controls, recursion settings, and provider mitigation capabilities. Treat the audit trail as evidence that the DNS trust boundary is still intentional.

Key takeaways

• DNS amplification works because open resolvers and spoofed source addresses let attackers convert small queries into large reflected floods.
• The scale of the threat comes from protocol asymmetry, with amplification factors reaching 50x or more and some cases much higher.
• Defence depends on resolver hardening, anti-spoofing, response limits, and continuous DNS auditing rather than edge capacity alone.

Key terms

• DNS Amplification Attack: A DNS amplification attack is a reflection-based denial of service technique that uses small spoofed queries to trigger much larger DNS responses toward a victim. The attacker spends little bandwidth while the target absorbs the resulting traffic flood, often through open resolvers or misconfigured DNS infrastructure.
• Open Resolver: An open resolver is a DNS server that answers queries from arbitrary sources instead of limiting recursion to approved clients. That behaviour makes the server easy to abuse in reflection attacks because it will generate responses for spoofed requests that were never meant for it.
• Response Rate Limiting: Response rate limiting is a DNS control that caps how many identical responses a server can send in a given period. It reduces the usefulness of DNS infrastructure as a traffic amplifier by limiting how much repeated response volume an attacker can force from the resolver.
• Ingress And Egress Filtering: Ingress and egress filtering block packets with spoofed source addresses from entering or leaving a network. In DNS security, these controls are critical because they stop attackers from forging the victim IP address needed to redirect amplified responses away from the real requester.

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 DNS Amplification Attack? Read the original.