DNS Amplification Attack: The Maths and the Fixes

A DNS amplification attack turns other people's DNS servers into a weapon aimed at your server. The attacker sends small queries with your IP address forged as the source, the servers send their much larger replies to you, and the flood fills your port before your firewall can do anything about it. This guide covers both halves: why only upstream filtering stops a flood bigger than your port, and how to keep your own DNS server from being a reflector.

How a DNS amplification attack works

CISA's alert TA14-017A describes the mechanism. It needs three things:

A forged source address. UDP is connectionless and does not validate the source IP, so the attacker writes the victim's address into each packet.
A server that answers anyone. It replies to the forged address: yours.
A reply much larger than the request. CISA's DNS alert, TA13-088A, says most attacks it saw used ANY queries, which ask for every record at a name, and most went to servers offering recursion to anyone.

RFC 5358 (BCP 140), the IETF's best current practice for resolvers, explains why open ones suit it: each fetches a large record once, caches it and sends it to the forged address for every spoofed query, in volumes too low for its operator to notice. Authoritative servers can be used too, with much less amplification, though DNSSEC makes their answers larger.

CISA's amplification factors

CISA's bandwidth amplification factor is the UDP payload bytes a server sends in reply divided by the UDP payload bytes of the request. Its table, credited to research by Christian Rossow, includes:

Protocol	UDP port	CISA factor	Fix on your own server
DNS	53	28 to 54	Recursion off or limited by ACL; RRL if authoritative
NTP	123	556.9	ntpd 4.2.7 or later, or `noquery` on `restrict default`
CLDAP	389	56 to 70	Don't expose UDP 389 to the internet
SSDP	1900	30.8	Disable it, or block it at the firewall
CharGEN	19	358.8	Disable it
Memcached	11211	10,000 to 51,000	1.5.6 or later: UDP is off unless enabled with `-U`

Ports are from the IANA registry (CLDAP uses UDP 389, per RFC 1798). The NTP fixes come from CISA's alert TA14-013A, memcached's from its February 2018 release notes; for the rest, CISA says to disable unwanted services or deny internet access to them.

Mind the caveats. The factors compare payloads, not whole packets. The alert is archived, last revised 18 December 2019, under a notice that the archive contains outdated information. Other methods give other numbers: in 2008 RFC 5358 put the factor for an open resolver supporting EDNS0 at around 80, as response packet size over query packet size. Treat every figure as an order of magnitude, not a constant.

The arithmetic: small input, full port

If a protocol's factor is F and an attacker sends X Gbps of spoofed queries, up to F × X Gbps arrives at the victim. For DNS, 1 Gbps of queries becomes up to 28 to 54 Gbps. Turned round, a 1 Gbps port fills at 1 ÷ 54 = 0.0185 Gbps, about 18.5 Mbps, of queries, or 1 ÷ 28 = 35.7 Mbps at the low factor. Reaching the 100 Gbps tier NexonHost includes with every dedicated server and VPS takes 100 ÷ 54 = 1.85 to 100 ÷ 28 = 3.57 Gbps.

Spoofed input (factor)	Fills 1 Gbps	Fills 10 Gbps	Reaches 100 Gbps
DNS (28 to 54)	18.5–35.7 Mbps	185–357 Mbps	1.85–3.57 Gbps
NTP (556.9)	1.8 Mbps	18 Mbps	180 Mbps
Memcached (10,000 to 51,000)	0.02–0.1 Mbps	0.2–1 Mbps	2–10 Mbps

At a given factor these are ceilings: headers pull the real multiplier below the payload ratio, and the attacker needs enough reflectors. The direction holds: a few hundred megabits of spoofed DNS queries can fill a 10 Gbps port.

Why your own firewall can't stop it

A reflected flood is real DNS replies from real servers, arriving from source port 53, and CISA's DNS alert concedes that against a large-scale DNS amplification attack there is often little the victim can do. Your firewall drops them only after they have crossed your port, and once it is full, clean traffic has nowhere to go. The packet arithmetic is in Gbps vs Mpps; how the port and the upstream filter relate is in VPS DDoS protection. NexonHost's DDoS protected dedicated server page lists "UDP, ICMP and amplification floods" among the attacks its included 100 Gbps Layer 4 tier covers, and says floods are dropped upstream, before they reach your port. A website DDoS proxy carries HTTP(S), not DNS, so if you run authoritative DNS, your protection has to be at the network level. Under attack now? Start with what to do when your server is under DDoS attack.

The root fix belongs to networks

Spoofing is the precondition, and BCP 38 (RFC 2827, May 2000) is the standing fix: a network drops customer traffic whose source address lies outside the prefixes that customer is meant to use, so packets forged with outside addresses never leave it. RFC 5358 calls wide-scale deployment of ingress filtering "the only real solution". You can't deploy it on the attacker's network, but you can keep your own server from being a reflector.

Don't be a reflector: lock down recursion

RFC 5358 says name servers should not offer recursion to external networks by default, authoritative-only servers should turn it off completely, and the two roles are best kept apart where practical.

Authoritative only, BIND. CISA's DNS alert gives these global options:

options {
    allow-query-cache { none; };
    recursion no;
};

A resolver for your own machines, BIND. Name the clients (option names per the BIND 9.20 manual):

acl mynets { 127.0.0.1; ::1; 192.0.2.0/24; };
options {
    allow-recursion { mynets; };
    allow-query-cache { mynets; };
};

Replace 192.0.2.0/24, a documentation range, with your own addresses, and set both lines. The manual says a missing allow-recursion is taken from allow-query-cache, then allow-query, so an allow-query { any; }; written for public zones can leak into recursion. Don't lean on the default localnets either: it matches every host on any network the server has an interface on.

Unbound is closed by default: only 127.0.0.0/8 is allowed and it listens on localhost until you add interface: lines. Open it with access-control: 192.0.2.0/24 allow, never 0.0.0.0/0.

PowerDNS Recursor answers only loopback, RFC 1918 private and other non-public ranges by default (incoming.allow_from); an empty value lets everyone in.

Authoritative servers: rate-limit and trim ANY

An authoritative server must answer anyone, but it can be a poor amplifier.

Response Rate Limiting (RRL). BIND's rate-limit counts identical responses per client block (a /24 for IPv4, a /56 for IPv6, by default) and drops the excess. With the default slip 2, every other limited request gets a small reply that tells a real client to retry over TCP or with a DNS cookie. responses-per-second defaults to 0, no limit, so RRL does nothing until you set a rate. The manual recommends no value (20 is from its qps-scale example), so test with log-only yes; first, then remove that line:

options {
    rate-limit {
        responses-per-second 20;
        log-only yes;
    };
};

The manual says RRL is meant for authoritative servers; on a resolver it can slow mail and web clients, and closing an open resolver is better. Knot DNS ships RRL as mod-rrl, enabled with global-module: mod-rrl in the default template, at 50 UDP queries a second per address by default.

Minimal ANY. RFC 8482 lets a server answer ANY with one record set, or a single synthesised HINFO record. In BIND, minimal-any yes; (default no) does this over UDP; on a resolver, Unbound's deny-any: yes returns an empty answer.

Other UDP services. Work through the table above; the new server security checklist covers listening ports and bind addresses.

Check from outside that you're not an open resolver

Test from a machine on another network, such as a laptop at home; a test on the server itself proves nothing, because localhost is usually allowed. With 203.0.113.10 standing in for your address:

dig @203.0.113.10 example.com A

dig asks for recursion by default, and your server is not authoritative for example.com. Read the header:

Closed: no ra flag and no answer for example.com, usually with status: REFUSED and dig's "recursion requested but not available" warning. No reply at all is also closed: PowerDNS Recursor ignores clients it doesn't allow.
Open: status: NOERROR, the ra (recursion available, RFC 1035) flag, and example.com's addresses in the answer. Fix the ACLs and test again.

Repeat against the server's IPv6 address; an IPv4 firewall rule doesn't cover it. Query only servers you run.

Protecting a server that runs DNS

Closing your resolver keeps you out of someone else's DNS amplification attack. It does nothing for one aimed at you; that needs filtering upstream of your port. NexonHost's DDoS protected dedicated server page lists amplification floods under the 100 Gbps Layer 4 protection included with every build, from €129 a month, and every Linux VPS includes the same 100 Gbps from €9 a month on monthly billing. Paid tiers run to 500 Gbps (€149 a month), 1 Tbps (€499), 2 Tbps (€999), 5 Tbps (€2,499) and 10 Tbps with Layer 7 (€4,499), per server or VPS. Ask any provider, us included, what happens when an attack exceeds the tier; the entry build is covered in cheap DDoS protected dedicated server. Start on a one-month term.

Prices as of 26 October 2026, in euros excluding VAT. Check the product page before you order.