When a DNS server will resolve names for any address on the internet, anyone can make it deliver its answers to someone else. That is an open resolver, and the reflected DNS volume it produces is a vector a DDoS test should exercise without ever touching one. It accepts a recursive query on UDP port 53 from any source, looks up the answer, and returns it to whatever address the query claimed to come from. The bounce and the size gain are the shared mechanism of DNS amplification; this page is about what makes a resolver open, and how to tell whether one of yours is.
What makes a resolver open
A resolver is closed when it answers recursion only for the clients it was set up to serve. RFC 5358, published in 2008 as BCP 140, asks exactly that: recursive service limited to intended clients, and not offered to the world by default.
Current software follows it. BIND has limited recursion to local networks by default since the 9.4 releases, and Unbound refuses every client except localhost until an access-control line says otherwise. Most open resolvers are therefore edits, not defaults: an allow-recursion { any; }; added to fix a problem, or a server bound to a public interface it was never meant to listen on.
Many are not servers at all. Consumer routers that answer DNS on their WAN interface and forward the query to the ISP's resolver make up a large share of the pool, and firmware nobody updates keeps them there.
A stranger kind is the transparent forwarder, which relays the query upstream without rewriting its source address. The answer then comes back from the upstream resolver, not from the device that was asked, so a scan that only counts replies from the address it probed never sees it.
Why the pool never empties
The count has fallen a long way since 2013, when the Open Resolver Project found tens of millions, but it does not reach zero. Shadowserver scans for open resolvers daily and sends network owners a report of the ones on their ranges, which is how many get closed. New ones appear as devices are deployed, so the pool is a moving population rather than a fixed list.
Each one is a reflector with an ordinary reputation. Nothing about the device is compromised, and its owner usually has no idea it answers strangers.
What a DDoS test measures
Two things, in opposite directions.
Inbound, a test generates traffic shaped like reflected DNS from sources it controls: source port 53, large UDP answers, many distinct senders. It measures how much the edge absorbs before clean traffic degrades, and it never sends a query to a real open resolver to produce that traffic.
Outbound, it checks whether you are part of the pool. From a vantage point outside your network, send a recursive query for a name you control to every address in your ranges that answers on port 53, over UDP and TCP, on IPv6 as well as IPv4. REFUSED, or no reply, is closed. An answer with the recursion-available flag set is open.
Using a name whose authoritative server you run also catches transparent forwarders. The query reaches your authority from someone else's resolver, and the reply reaches your scanner from an address you never probed. Repeat the check after firmware updates and configuration changes, because that is when closed resolvers quietly reopen.
The same reasoning applies to the resolvers your own users depend on, which DNS DDoS Testing works through.