DNS Amplification Attacks: What They Are and How to Stop Them

DNS Amplification Attacks: What They Are and How to Stop Them

DNS amplification takes advantage of two things we often overlook: DNS replies can be far larger than the tiny queries that trigger them, and UDP doesn’t verify the sender before a server ships a response; mix those and an attacker can forge a victim’s address and redirect oversized replies toward the target.

Because DNS routinely includes additional data, signatures, and glue, the size ratio—or amplification factor—can hit tens of times the query on the wire; even a ~60–80 byte request can elicit multi-kilobyte answers when zones are signed or responses include many records, which is why this technique remains a go-to move for volumetric floods.

The tool of choice for the adversary is the “open resolver,” a recursive server that should serve only known clients but instead answers the entire internet; attackers harvest huge lists of these and cycle through them to build reflection capacity, while also abusing publicly reachable authoritative servers that return identical answers again and again.

How DNS Amplification Actually Works

The attack is reflection: a bot forges the source IP of a DNS query to the victim’s address; because UDP has no handshake, the server replies to that spoofed source and the answer lands on the target; repeated across thousands of reflectors, the victim sees a torrent of unsolicited UDP/53 responses that dwarf the input traffic that provoked them.

Amplification Mechanics

Amplification is just reply size divided by query size; adversaries choose names that produce big answers—ANY (when not suppressed), DNSSEC-heavy names carrying RRSIG and DNSKEY, records with many TXT strings, or responses with fat additional sections; EDNS(0) allows large UDP payloads, so operators cap the advertised size and trim answers with minimal-response behavior to push very large packets into TCP fallback where a handshake exists.

Why DNSSEC Can Inflate Replies

Signatures and keys add bytes, sometimes a lot; that doesn’t make signing unsafe, it only means misused open resolvers become better amplifiers; the fix is keeping resolvers closed to the public, returning minimal content, and setting conservative UDP size ceilings so oversized answers truncate and retry over TCP.

Why Open Resolvers Make It Worse

An open resolver accepts recursive queries from anyone on the public internet; this is rarely intentional—defaults, CPE gear, images, or cloud builds often leave recursion exposed; measurement projects find large populations of these nodes at any time, which attackers reuse, rotate, and retire as operators shut them down.

Authoritative Servers Aren’t Immune

Authoritative servers must be globally reachable, which makes them candidates for reflection too; repeating the same answer at high rates to look-alike queries is exactly what response rate limiting (RRL) is built to dampen, often with an option to slip truncated replies that force TCP for some requests during suspicious bursts.

Mitigations You Can Deploy Today

You don’t need a forklift upgrade to blunt most of the risk; fence recursion, limit repetitive responses, right-size UDP, and make spoofing hard at your borders; those four measures remove the attacker’s leverage in the majority of real-world incidents.

Shut Down Open Recursion (or Fence It)

Restrict recursion to trusted clients and deny everyone else; in BIND, define ACLs and bind recursion and queries to them; in Unbound, add access-control rules; on Windows Server DNS, use recursion policies by client subnet; always test from an external vantage point to confirm strangers can’t fetch recursive answers.

BIND Example (Recursive)

acl "trusted" { 10.0.0.0/8; 192.0.2.0/24; }; options { recursion yes; allow-recursion { trusted; }; allow-query { trusted; }; minimal-responses yes; max-udp-size 1232; };

Unbound Example (Recursive)

server: interface: 0.0.0.0 access-control: 10.0.0.0/8 allow access-control: 0.0.0.0/0 refuse minimal-responses: yes edns-buffer-size: 1232

Rate-Limit and Right-Size Authoritative Answers

Enable RRL on authoritative servers so identical or near-identical answers to look-alike sources are throttled; start conservatively—about 5–10 responses per second per client prefix with a short window and slip enabled—then tune while watching legitimate latency; also enable minimal responses and cap the EDNS UDP ceiling (a practical default is 1232 bytes) to avoid fragmentation and nudge bulky answers into TCP.

BIND Example (Authoritative)

options { minimal-responses yes; max-udp-size 1232; rate-limit { responses-per-second 5; window 5; slip 2; }; };

Block Spoofing so Reflections Can’t Start

Stop forged sources with ingress/egress source address validation at borders; enable uRPF (strict where paths are symmetric, loose where they aren’t) and drop egress traffic whose source doesn’t belong on the interface; ask upstreams for ingress filtering on your aggregates if you multihome customers.

Prepare for Volumetric Events

Anycast authoritative footprints so load spreads across sites; arrange remote-triggered blackholing (RTBH) or BGP FlowSpec with transit providers to rate-limit abusive UDP/53 patterns near their origin; keep a scrubbing option ready if you host critical zones; rehearse playbooks that include temporarily lowering EDNS ceilings, enforcing minimal responses, and prioritizing essential records.

Detection, Triage, and Tracing Abuse

DNS amplification reveals itself in the shape of traffic: one target IP receives a surge of UDP/53 responses from thousands of unique servers, with average packet sizes well above baseline; flow telemetry exposes the fan-out of reflector IPs and the dominance of certain QNAME/QTYPE pairs, while packet captures confirm the forged source and the specific response patterns attackers repeat.

Spotting the Pattern

Expect repetitive answers for the same names across diverse sources, often including signatures or many TXT strings; reflector IPs will span multiple providers as bots rotate lists of exposed resolvers and reachable authorities; grouping top talkers by network helps you focus remediation where it pays off fastest.

Attribution and Next Steps

You can’t trust spoofed sources, so shift to the reflectors and the names being abused; notify operators of open resolvers with timestamps, sampled queries, and evidence that their servers answered recursive requests from the public; coordinate with upstreams to rate-limit attack signatures for a short window while you remediate and verify fixes from an external host.

IPv6 Considerations

The mechanics don’t change with IPv6; mirror ACLs on resolvers, enable RRL on authorities, keep EDNS ceilings conservative, and apply anti-spoofing to v6 interfaces alongside v4; validate behavior over both families after each change window so attackers can’t pivot to the path you didn’t test.

Operations Checklist

Use this quick checklist during audits and right after change windows to confirm defenses stay effective.

Testing and Ongoing Assurance

From an external host, probe your resolvers to confirm recursion is blocked to non-trusted clients; under controlled load, watch for truncated replies causing TCP fallback and verify latency for legitimate users remains acceptable; ensure RRL counters increment during synthetic floods without collateral damage; document the exact commands, escalation contacts, and rollback steps so on-call engineers can act in minutes instead of improvising.

DNS amplification will persist because brute force is cheap, but it loses teeth when you close recursion, constrain repetitive answers, right-size UDP, and remove spoofing; these controls are simple to deploy, easy to audit, and powerful in combination, turning a potentially crippling flood into noise you can ride out.

DNS Amplification Attacks: Key Answers (FAQ)

From an external host, query your resolver’s IP for a name you don’t serve and confirm recursion is refused; you can also sanity-check behavior with a trusted DNS Lookup to ensure it isn’t answering the whole internet.

Use a conservative baseline of 5–10 identical responses per second per client prefix, a short window (5–15 seconds), and slip enabled; load-test, watch latency, and raise gradually until legitimate users no longer notice throttling.

No; authoritative servers must accept UDP/53 and TCP/53 globally; instead, fence resolvers with ACLs, turn on RRL for authorities, and coordinate upstream filtering (RTBH/FlowSpec) during live attacks.

Yes; cookies add a lightweight return-routability signal, and truncated replies push large answers to TCP, which requires a handshake; still, you need border anti-spoofing to remove the root cause.

Export flow logs, group source addresses by provider, and map them using an ASN Lookup; then send time-bounded samples and evidence to the right abuse desks.

Set the ceiling around 1232 bytes to avoid fragmentation for common paths; if timeouts appear, step down temporarily (e.g., 1200 or 1024) and verify TCP fallback remains healthy.

No; mirror the same controls—ACLs on resolvers, RRL on authorities, conservative EDNS sizing, and border anti-spoofing—then use an IP Geolocation Map during incidents to visualize reflector clusters and prioritize outreach.

Absolutely; keep zones signed for integrity but close public recursion, enable minimal responses, and cap UDP so oversized packets truncate and retry over TCP.