DNS Amplification Attacks

An attacker sends a 60-byte question to a DNS server. The server sends a 4,000-byte answer—but not to the attacker. To someone else entirely. Someone who never asked.

Multiply this by thousands of servers, millions of queries, and you have DNS amplification: a way to turn modest bandwidth into overwhelming floods. The attacker whispers; the victim drowns in screams.

The Mechanics of Amplification

DNS amplification exploits two properties of how DNS works.

First, asymmetry. DNS queries are small, but responses can be enormous. Ask for a domain's TXT records—SPF policies, DKIM keys, domain verification strings—and you might get back 50 to 100 times more data than you sent.

Second, blind trust. DNS traditionally runs over UDP, which doesn't verify who's actually asking. When a query arrives, the server sees a source IP address and believes it. If that address is forged—spoofed to be the victim's address—the server dutifully sends its large response to the victim.

The attacker never sees the response. They don't need to. They've converted their bandwidth into the victim's problem, multiplied through servers trying to be helpful.

Open Resolvers: The Unwitting Weapons

The attack requires DNS servers willing to answer queries from anyone. These are called open recursive resolvers.

Some exist intentionally—public DNS services like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. But hundreds of thousands more exist by accident: home routers with default settings, corporate DNS servers that were never locked down, forgotten infrastructure still humming away in data centers.

The resolver is trying to be helpful. It receives a question, it sends an answer. It has no way to know that its helpfulness is being weaponized—that the "questioner" is a lie and the "answer" is a weapon.

This distributed nature makes the attack nearly impossible to stop at the source. There's no single server to secure, no single organization to contact. The amplifiers are scattered across the globe, owned by thousands of different entities, most unaware they're participating.

Why DNS Is Especially Vulnerable

UDP is the core problem. Unlike TCP, which requires a handshake before data flows—proving you can actually receive responses at the address you claim—UDP just sends. The server has no way to verify the source address is real.

This made sense when DNS was created. The Internet was smaller, more trusted, and TCP's overhead seemed unnecessary for simple lookups. But that trust model doesn't survive contact with adversaries.

DNS also maximizes availability by design. Resolvers answer queries from anywhere because that's what makes the system work smoothly. Restricting access requires explicit configuration, and many operators never bother—or don't realize their servers are exposed.

The Scale of Modern Attacks

In October 2024, Cloudflare blocked a 5.6 Tbps DDoS attack—at the time, the largest ever recorded. By mid-2025, that record fell to 7.3 Tbps. Attacks exceeding 1 Tbps now happen daily.

At this scale, you're not attacking a server. You're attacking a pipe. The victim's Internet connection itself becomes the bottleneck, saturated with traffic that legitimate requests can't penetrate.

The economics favor attackers absurdly. A few hundred dollars rents enough botnet capacity to generate traffic that would cost millions to absorb. These attacks have disrupted financial institutions, major Internet services, and critical infrastructure. They're used for extortion, competitive sabotage, and nation-state operations.

DNS amplification accounted for 55% of all amplified attack traffic in 2024—down from 88% in 2023 as attackers diversify into other protocols, but still the dominant vector.

How Defense Works

The most fundamental defense doesn't happen at the victim—it happens at the source. BCP38, also called ingress filtering, requires Internet providers to verify that traffic from their customers carries legitimate source addresses. If you claim to be sending from an IP you don't own, your ISP drops the packet.

If every ISP implemented BCP38, amplification attacks would essentially disappear. Spoofed queries would never reach resolvers. But adoption remains incomplete—too many networks still allow spoofed traffic to pass.

Resolvers can defend themselves with Response Rate Limiting (RRL). When a server sees hundreds of identical queries for the same record, apparently from the same source, it throttles responses. The attacker gets diminishing returns as resolvers recognize the pattern.

Victims defend through absorption and distribution. Traffic scrubbing services filter attack traffic before it reaches the target. Anycast routing spreads incoming traffic across multiple geographic locations, so no single pipe drowns. Massive bandwidth overprovisioning provides headroom—though you can't economically buy enough capacity to absorb a determined attacker.

Protocol improvements help at the margins. DNS cookies let resolvers verify that queries come from sources capable of receiving responses. DNS over HTTPS and DNS over TLS introduce TCP's connection requirement, making spoofing harder. But these changes roll out slowly, and legacy UDP-based DNS will exist for years.

What Organizations Should Do

Start with your own infrastructure. If you operate DNS servers, ensure they're not open resolvers—restrict recursive queries to authorized clients only. Authoritative nameservers that publish your domain's records should never offer recursion.

Implement egress filtering on your network. Don't let your systems send traffic with spoofed source addresses. You're not the target—but you could be unwittingly participating in attacks on others.

Monitor for unusual DNS traffic patterns. Sudden spikes in queries, especially for records you don't recognize, may indicate your infrastructure is being probed or weaponized.

Build relationships with your ISP and DDoS mitigation providers before you need them. When an attack starts, you want established channels and pre-negotiated response plans, not cold calls.

Design your DNS architecture for resilience: anycast distribution, geographic redundancy, adequate capacity. The goal isn't to stop the attack—it's to survive it while legitimate traffic continues flowing.

Sources