What is a DNS amplification attack?

02Why the factor matters so much

Amplification factor is the ratio between what the attacker sends and what the victim receives. A query for ANY against a zone with many records, or for a large signed record set, can produce a response dozens of times the size of the request, and some protocols are far worse. The figures below are the bandwidth amplification factors CISA published in its alert on UDP-based amplification; the wider family is covered in amplification attacks explained.

03DNS amplification is not a DNS flood

The two are easy to confuse and need different defences. Cloudflare's report for the first half of 2026 draws the line clearly: a DNS flood aims a botnet's raw request volume directly at a victim's authoritative DNS servers, while DNS amplification sends small spoofed queries to open resolvers, which reply to the victim with much larger records.

Both are common. In the same report DNS-based attacks made up 34.3% of network-layer activity in the first half of 2026, and CLDAP, another reflection vector, rose 580% quarter on quarter to become the third most common vector in the second quarter.

04Recognising it on the wire

Reflection is unusually easy to recognise, because the victim receives answers to questions it never asked. The filters below isolate the three tells: DNS responses arriving from port 53, oversized responses and fragments. If those replies do not match queries your own resolver sent, you are the target of reflection, and what you capture is only the share that made it through your link.

# DNS responses (QR bit set) arriving from port 53, IPv4 only
tcpdump -ni eth0 -c 100 'udp src port 53 and udp[10] & 0x80 != 0'

# packets from port 53 of 1,000 bytes or more
tcpdump -ni eth0 -c 100 'udp src port 53 and greater 1000'

# IPv4 fragments, which large amplified replies often arrive as
tcpdump -ni eth0 -c 100 'ip[6:2] & 0x3fff != 0'

05Defending as the victim

There is nothing you can configure on your own server to stop it: the traffic is already at your uplink, and it comes from thousands of legitimate resolvers. Defence has to happen upstream, on a network with more capacity than the attack.

• Filtering upstream: reflection traffic is recognisable, since it is replies you never asked for
• Enough capacity to absorb the flood while it is being discarded, which is what DDoS mitigation services exist to provide
• An origin address the attacker cannot reach directly, so the filtered path is the only path; see how to hide your origin IP
• Never block by source address: those are innocent servers, and there are far too many

06Not being part of someone else's attack

The other half of the problem is that these attacks depend on misconfigured servers. If you run infrastructure, a few checks keep you from being conscripted.

Each common amplifier has a documented fix. BCP 140 (RFC 5358) says nameservers should not offer recursive service to external networks by default. RFC 8482 lets DNS servers answer ANY queries with a minimal response, explicitly to make them less attractive amplifiers. ISC describes Response Rate Limiting in BIND as a mitigation for DNS amplification. Memcached disabled UDP by default in version 1.5.6, and CISA's advice for NTP is to upgrade to 4.2.7 or later, which disables monlist, or to add noquery to the restrict lines.

To check whether a resolver you run is open, query it from a network outside your own: a refused query is what you want, and the port 53 open-resolver test shows real open and closed replies side by side. A browser-based DNS lookup shows what your public records return.

• Do not run an open recursive resolver: restrict recursion to your own networks
• Rate limit responses (DNS RRL) on authoritative servers
• Never expose memcached, NTP monlist or CLDAP to the public internet
• Implement source address validation (BCP 38) so forged packets cannot leave your network

dig @203.0.113.53 www.example.com A

# good: status: REFUSED, or no answer at all
# bad:  status: NOERROR, flags include "ra", and an ANSWER section