Notifications
Clear all
Topic starter
23/06/2026 7:14 pm
TL;DR: DNS amplification attacks exploit open or misconfigured DNS resolvers to multiply small spoofed queries into traffic floods that can exceed the original request by 50x or more, according to DigiCert. The practical lesson is that availability depends on resolver hygiene, source-address filtering, and response controls, not just edge capacity.
NHIMG editorial — based on content published by DigiCert: What is a DNS Amplification Attack?
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Disable open recursion on authoritative servers Separate authoritative and recursive roles, then confirm that authoritative servers do not answer arbitrary external recursion requests.
- 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.
- Set response rate limits and size controls Tune RRL and review whether DNSSEC, ANY queries, and oversized TXT records are creating avoidable amplification potential.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step DNS troubleshooting checks using dig, nslookup, and Nmap scripts for exposed resolvers.
- Configuration examples for disabling recursion, tuning response rate limits, and validating DNSSEC impact on response size.
- Detection guidance for UDP port 53 anomalies, edge filtering, and provider-side mitigation capabilities.
- Practical hardening checklist for auditing authoritative and recursive DNS roles after changes.
👉 Read DigiCert's explanation of DNS amplification attacks and mitigation →
DNS amplification and open resolvers: are your controls keeping up?
Explore further
25/06/2026 3:09 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: DNS amplification attacks expose the limits of open resolver control
