DNS amplification attacks expose the limits of open resolver control

At a glance

What this is: This is an analysis of DNS amplification attacks and the role of open or misconfigured DNS resolvers in turning small spoofed queries into large reflected floods.

Why it matters: It matters because DNS availability is part of service resilience, and teams that treat resolver configuration as a back-end detail can miss a direct path to outage.

By the numbers:

• DNS amplification attacks can multiply attack traffic by 50x or more.

Context

DNS amplification is a reflection-based DDoS technique that uses publicly reachable DNS infrastructure to magnify a small request into a much larger response. The security issue is not just attack volume, but the governance gap created when resolvers answer queries they should never have accepted in the first place.

For IAM and infrastructure teams, the relevant control problem is access scope for DNS services: who or what can cause a resolver to answer, and under what conditions. Open recursion, weak source-address filtering, and inconsistent response controls make the resolver a force multiplier rather than a bounded service.

The article frames this as an availability problem, but the underlying lesson is lifecycle governance for network identity surfaces. Resolver configuration has to be treated as an active control domain, not a one-time build step, because an exposed resolver becomes reusable attack infrastructure the moment it stays open.

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 such severe availability risk?

A: They create a multiplier effect. A small forged query can produce a much larger response, and repeated responses from many resolvers can exhaust bandwidth or overwhelm intermediate networks. The practical risk is that availability fails before traditional edge capacity planning has time to absorb the surge.

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: Should organisations prioritise resolver hardening or DDoS scrubbing first?

A: Resolver hardening should come first because it reduces the amount of attack traffic that can be generated in the first place. DDoS scrubbing is still valuable, but it is a compensating control. The strongest posture combines both, with source filtering and response limits preventing abuse upstream of mitigation.

Technical breakdown

How DNS amplification turns small queries into large floods

DNS amplification depends on a mismatch between request size and response size. An attacker spoofs the victim's IP address, sends a small query to an open resolver, and the resolver sends a much larger response to the victim. Techniques such as ANY queries, DNSSEC signatures, large TXT records, and EDNS0 can further increase the payload size, which is why the same attack pattern can scale dramatically without requiring much attacker bandwidth.

Practical implication: reduce response size and close recursion paths before a resolver can be abused as a multiplier.

Why open resolvers and spoofing make the attack work

The attack only succeeds when resolvers answer requests from any source and when source-address spoofing is possible upstream. Botnets can distribute the query load, but the real abuse path is the resolver's willingness to respond without access controls. In other words, the exploit is not DNS itself, but unauthorised use of DNS behaviour that was meant to serve legitimate recursion and resolution.

Practical implication: treat open recursion and spoofable ingress as access-control failures, not just networking issues.

How rate limiting and filtering blunt reflection abuse

Response rate limiting reduces repeated identical answers, while ingress and egress filtering blocks forged source addresses from entering or leaving a network. Those controls do not eliminate every DDoS threat, but they narrow the usable attack surface by preventing resolvers from amplifying arbitrary requests at scale. In operational terms, they move the problem from unconstrained reflection to controlled response handling.

Practical implication: combine response throttling with BCP 38-style filtering so amplified traffic cannot be generated or forwarded freely.

Threat narrative

Attacker objective: The attacker wants to overwhelm the victim's network with reflected DNS traffic while spending minimal bandwidth of their own.

1. Entry occurs when the attacker sends a spoofed DNS query to a public resolver that will answer requests from any IP address.
2. Escalation occurs when the resolver returns a much larger response than the original query, multiplying the traffic volume toward the victim.
3. Impact occurs when repeated reflected responses exhaust bandwidth and disrupt availability for the target and adjacent networks.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Open recursion is an exposure control problem, not just a DNS setting. A resolver that answers arbitrary external queries becomes reusable attack infrastructure the moment spoofed requests can reach it. That is why resolver governance belongs in the same conversation as service exposure, access scope, and network trust boundaries. Practitioners should stop treating recursive behaviour as harmless convenience and treat it as a controlled entitlement.

DNS amplification shows how availability collapses when the network is allowed to speak for you. The attack works because the resolver authenticates nothing about the requester and blindly returns a response that the attacker redirects. That is a governance failure around source trust, not merely a volumetric event. The practical lesson is that network services need explicit boundaries on who can trigger expensive responses.

Response-rate governance: the decisive control is not whether DNS can answer, but whether it can answer at scale without becoming a reflection weapon. RRL, filtering, and audit checks each constrain a different part of the abuse path. Taken together, they make the resolver's behaviour predictable enough to govern and hard enough to weaponize. Teams should measure whether their DNS estate still permits unconstrained amplification, not assume the platform will absorb the risk.

The most dangerous resolver is the one that is technically healthy but operationally open. Many teams focus on uptime, but an always-on resolver with permissive recursion and no spoofing controls can still be attacker-owned infrastructure. That means resilience reviews must include the conditions under which the resolver is allowed to respond, not just whether it is reachable. Practitioners should reclassify DNS exposure as a control issue, not only an availability metric.

What this signals

Resolver exposure is an availability governance issue. Teams that own DNS need to think in terms of authorised response, not just service uptime. If recursive behaviour is left open, the resolver can be turned into a traffic multiplier even when the underlying infrastructure is otherwise healthy.

Source-address filtering is the missing boundary in many reflection cases. BCP 38-style filtering matters because spoofed packets are what let small requests become victim-directed floods. Without that boundary, the rest of the DNS control stack is only reducing damage after the attack has already been shaped.

DNS control reviews should be continuous, not incidental. Recursion settings, response limits, and edge filtering drift over time as configurations change and services are added. Practitioners need to verify that the resolver still behaves like a bounded service after each operational change.

For practitioners

• Disable open recursion on authoritative resolvers Restrict recursive answers to trusted clients only, and verify that authoritative servers do not answer arbitrary external requests. Review the settings after every configuration change and include them in routine DNS audits.
• Enforce response rate limiting on high-risk DNS services Configure response rate limiting where the resolver software supports it, then tune thresholds so legitimate bursts are not suppressed. Test the setting in a controlled environment before production rollout.
• Apply source-address filtering at network boundaries Work with upstream providers to implement ingress and egress filtering that blocks spoofed packets from entering or leaving your environment. This is the control that prevents forged source addresses from being used in reflection attacks.
• Audit for exposed resolvers on a fixed schedule Use approved scanning and monitoring tools to identify resolvers that answer from any IP address, allow recursion where they should not, or produce unusually large responses. Track the findings as part of configuration governance.
• Validate DDoS mitigation coverage for DNS traffic Confirm that edge filtering, anomaly detection, and traffic scrubbing are in place for DNS service paths, not only for web traffic. Test how the service behaves when reflected UDP floods arrive in volume.

Key takeaways

• DNS amplification remains a practical outage path because open or misconfigured resolvers can magnify tiny spoofed queries into much larger floods.
• The attack succeeds by abusing resolver behaviour, not by breaking DNS itself, which is why access scope and response control matter so much.
• Organisations should harden resolvers, enforce source filtering, and test DDoS mitigation for DNS traffic as part of routine availability governance.

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.
• Source Address Filtering: A network control that blocks packets with forged source IP addresses from entering or leaving a network. For DNS amplification, this matters because spoofing is what lets attackers redirect large resolver responses toward a chosen victim.

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 building or maturing an IAM programme, it is worth exploring.