The first warning usually is not a monitoring alert. It is an abuse notice from an upstream transit provider, politely informing a hosting company that machines in one of its /24s have been firing answers at a stranger’s network for the past six hours. Someone pulls the logs, and there it is: a handful of customer VPS images that shipped with recursion enabled and no access control list, now serving as a small amplifier farm. Nobody attacked that hosting provider. It became the weapon. That split is the thing most writing on DNS amplification attack protection skips, and it matters, because the fixes for the two roles have almost nothing in common.
Distributed denial-of-service (DDoS) attacks using Domain Name System (DNS) reflection have been documented since the mid-2000s. They still work. Understanding why they survive a decade of advisories is the fastest route to knowing which controls actually close the hole and which are expensive theatre.
Why DNS amplification still works after a decade of warnings
The mechanics take one paragraph. An attacker sends a small UDP query, typically 60 to 80 bytes, to a DNS server, but forges the source address so it carries the victim’s IP. The server answers the victim with a response many times larger. There is no handshake, no connection state to exhaust or reset, and no return path for the victim to refuse. CISA’s alert on UDP-based amplification attacks (TA14-017A) puts DNS’s bandwidth amplification factor in the range of 28 to 54, meaning a modest upstream connection on the attacker’s side can land tens of times that volume on the target.
Where does the amplification come from? Three places, mostly. ANY queries that ask a server to return every record it holds for a name; DNSSEC-signed zones, where DNSKEY and RRSIG records push responses into kilobytes; and TXT records stuffed with the verification strings that modern email authentication and SaaS onboarding leave behind. A zone with four mail vendors, two site verification tokens and a signed delegation is a more useful reflector than its owner realises.
The attack persists for unglamorous reasons. Open and misconfigured resolvers remain cheap to find at internet scale. Source address spoofing is still possible on any network that has not implemented ingress filtering. And the attacker’s own bandwidth stays small, which is the whole point. The March 2013 attack on Spamhaus, widely reported at around 300 Gbps, was driven through open resolvers by an actor with nothing like that capacity of their own. It remains the clearest demonstration of the asymmetry.
What has changed is distribution. Booter and stresser services now list reflection vectors as menu items alongside everything else, which is why the UK’s National Crime Agency keeps turning up in international takedown operations against them. A teenager with a card payment reaches volumes that once merited a research paper. For context on who actually buys this capability, the overview of the DDoS-for-hire market in the UK is worth reading alongside this piece.
Target or reflector? Work out which problem you are solving first
Before buying anything, establish which end of the attack you are standing on.
Signs you are the reflector: outbound UDP/53 spikes with no matching inbound customer demand; abuse complaints from networks you have never knowingly served; a transit bill that moves in a direction nobody can explain; query logs full of ANY or large TXT lookups for domains you do not host.
Signs you are the target: inbound UDP/53 and oversized response traffic arriving from thousands of otherwise legitimate resolvers; saturated transit ports; and name resolution failing before your web servers show any strain at all. That last symptom catches people out. The application tier looks healthy on every dashboard while customers cannot reach it, because the lookup never completes.
The fixes point in opposite directions. A scrubbing contract does precisely nothing about the first problem, since the traffic leaving your network is technically well-formed DNS answering a query it received. Closing the reflector role is configuration work on your own servers and filtering at your own edge.
Then there is the awkward middle. Hosting providers, colocation operators and ISPs are frequently both at once: targets of inbound floods and, through customer-managed servers they do not administer, reflectors in somebody else’s attack. If that describes you, the controls below need to be paired with contractual terms and scanning of customer ranges, not just your own. The colocation DDoS protection checklist covers where that responsibility boundary usually sits in writing.
Check your own exposure before you buy anything
Testing from inside your own network tells you very little, because your own access control lists are permissive towards you. Measure from outside.
- Query every public range you own from vantage points on other networks: ask what answers recursion, what answers an ANY query, and what response size comes back.
- Subscribe to free external signals rather than relying on internal monitoring alone. The Shadowserver Foundation publishes daily open resolver reporting to network owners at no charge, and your upstream’s abuse desk is a signal too, if someone reads the mailbox.
- Inventory every authoritative name server, including the forgotten secondary still running at a provider you left three years ago and the appliance quietly doing recursion on a management VLAN.
- Record the actual response sizes your zones return for their largest record sets. That figure is the amplification factor an attacker will use against a third party, and it is also the number you should be reducing.
Server-side controls that close the amplifier
These are the measures that take you out of the reflector business. RFC 5358 set out the principle back in 2008: recursive servers should not be usable by arbitrary third parties.
- Separate recursive and authoritative roles. One daemon doing both is the oldest misconfiguration in the book. Restrict recursion to known client ranges explicitly rather than trusting a distribution’s defaults, and audit customer templates and golden images, because that is where recursion-enabled builds propagate quietly.
- Response rate limiting (RRL) on authoritative servers. RRL caps identical responses per client per second and is the single most effective server-side control against reflection. Tune the slip and window values so legitimate retries still succeed: a slip value of 2 sends every second over-limit response as a truncated answer, which nudges a real client to retry over TCP while giving a spoofed victim nothing useful.
- Minimal responses to ANY. RFC 8482, published in 2019, lets a server return a small synthesised answer to ANY queries instead of the entire record set. There is no operational reason to hand out a full zone dump to an anonymous UDP query.
- EDNS buffer sizing. The DNS Flag Day 2020 recommendation is to lower the advertised EDNS UDP buffer size to 1232 bytes, keeping responses inside the IPv6 minimum MTU and pushing larger answers to TCP rather than fragmenting them.
- Source address validation at the edge. BCP 38 (RFC 2827) and BCP 84 (RFC 3704) describe ingress filtering so spoofed packets never leave your network in the first place. It does nothing for your own exposure and everything for everyone else’s; that is exactly why it remains patchily deployed.
Staying reachable when the flood is aimed at you
Now the other end. Defending authoritative DNS as a target is a question of where capacity sits and how fast it engages.
Headline terabits-per-second numbers tell you almost nothing here. Reflected UDP/53 traffic arrives wherever routing sends it, so the figure that matters is capacity at the location serving your region and how many anycast nodes answer your zones, not a global aggregate across a provider’s whole estate. A flood sourced from European resolvers lands on European nodes. Capacity in Singapore is irrelevant that afternoon. The breakdown of what Tbps scrubbing capacity claims actually mean goes further into how those numbers are assembled.
On-demand mitigation and DNS are a poor fit, and this is the point worth arguing about. BGP diversion, route propagation and tunnel establishment are measured in minutes. A reflection flood saturates a transit port in seconds. Read the time-to-mitigate clause closely and ask what the clock starts from: detection, notification to you, your authorisation, or traffic genuinely being cleaned. Those four definitions can differ by a quarter of an hour, which is an eternity for name resolution. Our sector talks about always-on versus on-demand as a cost decision; for authoritative DNS it is closer to a reachability decision.
Two self-inflicted outages account for a depressing share of DNS incidents. The first is remote triggered blackholing of your own prefix under pressure, which completes the attacker’s work for them. The second is dropping port 53 wholesale at a firewall. Both stop resolution, and with it email delivery, API calls and anything else depending on lookups. Flowspec and blackholing are legitimate tools; they are also the quickest way to turn a degradation into a total outage if deployed without thought about what else rides on that prefix.
Finally, the box in front of DNS often fails before the pipe does. Stateful firewalls and intrusion-prevention appliances track UDP pseudo-sessions, and a reflection flood exhausts that state table long before the circuit saturates. If an appliance sits in the path of authoritative DNS, assume it is the weakest link and plan to move filtering upstream of it. How cloud scrubbing services handle traffic in practice is useful background for that conversation.
The three surfaces, and the one most buyers leave unmanaged
Protection should be assessed across three surfaces: network and transport, the application layer, and authoritative DNS. Most organisations have the first two covered by contract and can name who does it. The third is routinely orphaned, which is awkward, given it is the surface amplification attacks both abuse and target.
ISP-level protection generally defends your transit pipes. That is the scope. If your authoritative name servers sit with a registrar, a managed DNS provider or a cloud platform, that path is outside the ISP contract entirely, and nobody tends to notice until the delegation stops answering. The limits are set out in more detail in the guide to what UK ISP DDoS protection covers and does not cover. Map each surface to a named supplier and get it in writing; if a surface has no owner, that is your gap.
Secondary DNS with a second, genuinely independent provider is the cheapest resilience most organisations still skip. Two providers, two anycast networks, zone transfers or API-driven sync, and a target’s chance of being wholly unreachable drops sharply. Reflection attacks against hosted DNS are not new; the EveryDNS outage made the point years ago, and the lesson has not aged.
Registrar and registry controls round it out: plan TTLs so you can move delegation at speed without a day-long cache tail, keep the domain lock status documented, and know exactly who is authorised to change NS records at 03:00 on a Sunday. Discovering that the only person with registrar credentials left the company is a common and entirely avoidable complication.
Six questions for providers, and how to price the protection honestly
Ask these before signing, and ask for the answers in the contract rather than the sales deck:
- What is per-location capacity for UDP floods at the sites serving our regions, not the global total?
- How many anycast nodes will answer our zones, and where are they?
- How is mitigation triggered: always-on inspection, automatic detection, or a phone call from us?
- What is the time-to-mitigate commitment, and what event starts the clock?
- Is authoritative DNS explicitly in scope, including the name servers we do not host ourselves?
- What happens to clean traffic during diversion: added latency, dropped TCP sessions, loss of source IP visibility?
UK managed DDoS pricing is usually built from a clean traffic commitment measured in Mbps or Gbps, with burst and overage charged above the band. Watch for per-event mitigation fees, onboarding and integration charges, and minimum terms, all of which sit below the headline monthly figure. Prices move, so treat any quote as current only on the day it was issued.
Build the case from downtime cost, not attack size. Take average order value per hour for the affected channel, multiply by a realistic outage window, then add the knock-on cost of DNS failure on transactional email, partner APIs and internal services, which is the part that gets underestimated. Set that figure against the commitment, the per-event charges and the onboarding fee as separate lines. The board-ready DDoS protection business case model sets out that calculation in a form finance teams accept. The UK’s National Cyber Security Centre also publishes denial of service guidance worth reading before any procurement conversation.
Effective DNS amplification attack protection is so two jobs, not one: configuration discipline that stops your servers amplifying for someone else, and capacity plus engagement speed that keeps your zones answering when the flood points your way. Work out which problem you have first, then go back through the related guides on scrubbing capacity claims and ISP coverage limits before anyone signs anything.
Frequently Asked Questions
What is a DNS amplification attack, in plain terms?
An attacker sends small DNS queries with the victim’s IP address forged as the source, so every answer goes to the victim instead of the sender. Because responses are far larger than queries, CISA’s alert TA14-017A puts the amplification factor at roughly 28 to 54 for DNS, a small amount of attacker bandwidth turns into a flood. The servers doing the amplifying are usually innocent third parties with permissive configurations.
How do I know if my DNS servers are being used as an amplifier?
Look for outbound UDP/53 traffic that does not correspond to any inbound demand you can account for, and for repeated queries for domains you do not host. Query your own public ranges from an external vantage point to see what still answers recursion. The Shadowserver Foundation’s free daily reports to network owners will often flag open resolvers in your space before your own monitoring does.
Does response rate limiting break legitimate DNS queries?
Not if it is tuned. RRL counts identical responses to the same client prefix, and real resolvers rarely repeat the same query fast enough to trip a sensible threshold. The slip parameter matters: setting it so a proportion of over-limit responses return truncated lets genuine clients retry over TCP, while a spoofed victim receives nothing it can use. Start permissive, watch your logs, then tighten.
Will my ISP’s DDoS protection cover a DNS amplification attack?
It will usually protect your transit circuits, which helps if the flood is aimed at addresses inside your own network. If your authoritative name servers are hosted with a registrar, a managed DNS provider or a different cloud platform, that traffic never touches your ISP’s pipes and sits outside the contract. Check the scope line by line and confirm in writing which surfaces are covered.
Is always-on mitigation necessary for DNS, or is on-demand enough?
For authoritative DNS, on-demand is a weak fit. Diversion and tunnel setup take minutes while a reflection flood saturates a port in seconds, so the resolution failure happens before mitigation engages. Always-on inspection, or anycast-hosted DNS with per-location capacity in the regions you serve, closes that window. Either way, read the time-to-mitigate clause and establish what event starts the measurement.