The reflector was named as a building block of denial of service in 2001, when Vern Paxson's paper "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks" pointed out that any internet host which answers a packet can be aimed at a victim by forging that packet's source. A reflector is that host: a third-party server the attacker never owns, and the one piece of attack infrastructure a DDoS test should imitate rather than use. It still matters because the internet is full of servers that answer strangers by design, and every one of them is a candidate.
Who the reflectors are
How the bounce works is described under reflection attack, and how much bigger the reply gets is the amplification factor. This page is about the machines themselves.
They are ordinary servers doing their job. A DNS resolver open to the whole internet, an NTP daemon that still answers monitoring queries, a home router answering SSDP discovery, any TCP server answering a SYN: none of them is compromised, and the owner rarely knows it took part. That is the line between a reflector and a bot in a botnet. A bot is someone's machine under the attacker's control. A reflector is under nobody's control but its owner's, and it is simply answering.
The pool is large, and it has been counted. The Open Resolver Project found roughly 28 million open DNS resolvers in 2013. The flood against Spamhaus that year, around 300 Gbps and a record at the time, was reflected off more than 30,000 of them.
Lists of reflectors are cheap to keep current. ZMap, released the same year, can sweep the whole IPv4 space on one port in under an hour from a single well-connected machine, so a reflector that closes is replaced by the next scan.
Why it matters under attack
Reflectors defeat per-source thinking. Each one contributes a small share, often below any per-address rate limit a defender would dare to set, and only the total hurts. A limit tuned to catch one noisy source never fires on thirty thousand quiet ones.
They also arrive with good reputations. A blocklist built from a reflected flood soon contains public resolvers, NTP pool members and university hosts, some of which the defender's own systems rely on. Blocking them by address trades one outage for another, which is why mitigation keys on the protocol and source port of unsolicited replies rather than on who sent them.
The fixes that last are on the reflector's side, and a few work well. DNS Response Rate Limiting, built into BIND in 2013, caps how many identical answers an authoritative server sends to one client prefix, so the server stops being a useful bounce point without refusing real clients. NTP removed its monlist command. Each fix shrinks one protocol's pool; none retires the idea.
What a DDoS test measures
A lawful test never bounces traffic off real third-party reflectors. That would load servers nobody gave permission to use, and their owners and upstream providers would rightly treat it as abuse. The test instead generates reflected-style traffic from sources it controls, matching the properties that matter: source ports, reply sizes, and above all the number of distinct source addresses.
That last property is the reflector-specific measurement. The same total volume from a handful of sources and from thousands answers two different questions. A few sources test capacity. Thousands test whether any control in the path depends on counting per source, and how much of the flood gets through while each source stays under its threshold.
One outward check belongs in scope too: anything in your own ranges that answers UDP queries from anyone is a reflector for someone else, whatever the inbound results say. Keeping a test inside the systems you are authorised to load is the same discipline, and running a DDoS test without disrupting production works through it.