What is a DNS amplification attack?

Reflection, then amplification

Most floods are simple: the attacker's machines send packets straight at you, and the attack is capped by how much bandwidth those machines have. Reflection attacks remove that cap by using someone else as the messenger.

The trick is IP address spoofing. UDP has no handshake — a server receiving a UDP query has no way to confirm that the source address in the packet is really where the packet came from. So the attacker sends a query to a public DNS server, writes your IP address in the source field, and the reply is dutifully delivered to you. You never exchanged a packet with the attacker. That is reflection.

Amplification is what makes reflection worth doing. DNS answers are much larger than DNS questions. A query of about 60 bytes asking for a domain's full record set can return an answer of 3,000–4,000 bytes, especially where DNSSEC signatures are attached. The attacker spends one unit of bandwidth and delivers sixty. Rent a modest botnet, point it at a list of a few hundred thousand open resolvers, and a few gigabits of attacker capacity arrives at your network as hundreds.

Amplification factors, by protocol

DNS is the best-known reflector but far from the worst. Any UDP service that answers a small request with a big response is a candidate, and attackers move between them as operators clean each one up.

The pattern is constant even as the protocols rotate: an unauthenticated UDP service, reachable from the whole internet, that replies with more than it was asked for.

What it looks like from where you sit

An amplification flood is a volumetric attack, so the failure is at the network layer rather than the application. Warning signs:

• Inbound bandwidth spikes to your link's ceiling within seconds, with no matching rise in application requests.
• Your traffic graphs show UDP from source port 53, 123, 389 or 1900 — services you never queried.
• Packet loss and latency climb for everything on the same link, including SSH, email and unrelated sites on the same host.
• The source addresses look entirely legitimate, because they are: they belong to real DNS resolvers, NTP servers and misconfigured devices around the world.

That last point is what makes the attack so awkward to handle in-house. There is no attacker IP to block. Blocking the reflectors means blocking a slice of the public DNS infrastructure, and the list rotates constantly. Meanwhile your own firewall is beside the point: even if it drops every single packet perfectly, the packets already crossed your link to get to it. Once the traffic arrives, the damage is done. Filtering has to happen upstream of the pipe you are trying to protect.

Why the usual defenses do not apply

Application-layer defenses are the wrong tool here, and it is worth being precise about why. Rate limiting works on requests your application receives; an amplification flood never reaches your application. A WAF inspects HTTP; this traffic is not HTTP. Autoscaling adds application capacity behind a link that is already saturated — you pay more and stay down.

What does work operates on packets, upstream, before the last mile:

• Absorption capacity. The flood has to land somewhere with room for it. This is the one part of DDoS defense that genuinely is about raw scale.
• Anycast dispersion. When one address is announced from many locations, a global flood splits across all of them instead of concentrating on one.
• Stateless packet filtering. Unsolicited UDP responses to a service that never sent a query are droppable on sight — cheaply, in hardware, at line rate.
• Protocol-aware scrubbing. Malformed and clearly forged packets are discarded while legitimate traffic on the same address keeps flowing.

Make sure you are not part of someone else's attack

Reflection attacks are only possible because of two widespread misconfigurations. Both are worth fixing on your own infrastructure — the internet gets quieter, and you avoid the bandwidth bill and abuse reports that come with being an unwitting amplifier.

1. Do not run an open resolver. A recursive DNS server should answer only your own networks. Authoritative servers should not recurse at all.
2. Do not expose UDP services you are not using. Firewall NTP, memcached, CLDAP and SSDP to the hosts that actually need them. memcached in particular should never face the internet.
3. Enable response rate limiting (RRL) on authoritative DNS servers, so a single spoofed source cannot pull unlimited replies out of you.
4. Filter spoofed source addresses on egress. Networks that implement BCP 38 drop outbound packets whose source address does not belong to them. Universal adoption would end reflection attacks outright, which after two decades is a good indication of how the incentives run.
5. Audit what you expose. Point an external scanner at your own address space; the reflectors used in these attacks are, without exception, someone who did not know a service was open.

How Itnetic absorbs amplification floods

Volumetric attacks are handled before traffic reaches our filtering edge, not after. Frankfurt and Beauharnois sit behind X4B, a network with 3 Tbps of mitigation capacity, and Singapore runs on OVHcloud with OVHcloud's own network-level protection — so an amplification flood is soaked up in the carrier network rather than at your server's uplink. Our edge points of presence then handle the Layer 7 side: the requests that are shaped like real visitors and cannot be filtered by packet inspection.

Two things matter as much as the capacity number. First, your origin has to be unreachable except through the protection network — otherwise attackers simply address the flood to your real IP and the mitigation never sees it. That checklist is in how to hide your origin IP address. Second, attack traffic is never metered against your bandwidth quota, so being reflected at does not turn into an invoice — the rest of that arithmetic is in how much a DDoS attack costs.

Setup is two DNS records and takes about five minutes, on the free Starter plan as much as on a paid one. If you are currently under attack, work through how to stop a DDoS attack first — it is written for the incident, not the reading.