UDP Reflection and DNS Amplification: when a query becomes a flood

Infrastructure can become unavailable without an attacker managing to execute code on it. In reflection and amplification attacks, network-accessible services are used as intermediaries to direct traffic at a target. DNS is one of the best-known examples of this combination.

For a Red Team, understanding this mechanism helps investigate two exposures: whether the organization can act as a reflector and whether it can respond to a volumetric attack. Each hypothesis requires different evidence and its own rules of engagement.

Reflection and amplification are different things

Reflection happens when a service’s response is sent to a third party whose address was presented as the source of the request. Amplification is the increase in volume between a request and the responses it provokes. Reflection can occur without a significant size increase; together, the techniques allow more traffic to be directed at the target than the sender originally transmitted.

UDP, defined in RFC 768, does not establish a connection with a handshake confirming the sender’s reachability before a response. Without additional controls, a service may reply to the source address stated in the packet, even if it was forged. Applications can add validation mechanisms, so using UDP alone does not make every service an amplifier. CISA describes this combination in its alert on UDP-based amplification attacks.

How DNS enters the chain

The DNS reflection flow, discussed in RFC 4732 on denial of service, has three participants:

1. Sender: sends a DNS query over UDP with the source address forged to match the target’s address.
2. Reflector: receives the query and sends the response to the address indicated as the source.
3. Target: receives responses it did not request; when volume exceeds its capacity, availability can be affected.

The volume gain depends on response size relative to query size. Distributing the process across multiple reflectors makes traffic converge from multiple sources. The target does not need to operate a DNS server: it only needs to receive traffic addressed to it. Cloudflare’s DNS amplification analysis explains this behavior.

The intermediary server does not need to be compromised either. An open recursive resolver accepting requests from external clients without proper restrictions can be abused through its normal functionality. Authoritative servers can also participate in reflection without offering recursion. Distinguishing these roles is essential to choosing the fix, as RFC 5358 explains.

The amplification factor is not a fixed number

CISA defines the bandwidth amplification factor using the UDP payload bytes sent in responses relative to the request’s payload bytes:

Amplification factor = response payload bytes ÷ query payload bytes.

In a purely educational example, an 80-byte query provoking an 800-byte response has a factor of 10 under this metric. This is not a measurement of a real server and does not include headers from other layers.

The historical table in the CISA alert should not be treated as a promise of current performance. Queried records, implementation, and configuration affect responses. A technical report must record what it measured, in what context, and which limitations prevent extrapolation.

Three simplifications that hinder analysis

“Any ANY query returns all records.” This expectation is inappropriate. RFC 8482 describes minimal responses to ANY queries, including only a subset of records. An explanation based on consistently enormous responses may not represent the assessed server.

“Just close recursion.” Restricting recursion is central for private resolvers, but a public authoritative DNS server must keep answering for its zones. RFC 5358 already recognizes that authoritative servers can be used as reflectors. They require controls appropriate to the public service they offer.

“The target’s firewall solves it alone.” If the incoming link is already saturated, dropping packets after that point does not recover lost capacity. Protection must consider the provider and paths before the bottleneck. Cloudflare discusses this limitation of local mitigations.

What to assess in a Red Team exercise

An assessment starts with a testable question. For example: “does our private resolver accept recursion from a network that should have no access?” or “does the team recognize unsolicited DNS responses and contact the correct provider?”

Rules of engagement must identify permitted assets, the window, responsible people, traffic limits, and stopping criteria. Authorizing a security assessment does not imply authorization for denial-of-service tests; any availability test must be expressly included.

An assessment can follow this sequence:

1. Map service roles. Identify private resolvers, authoritative servers, exposed interfaces, and expected access controls.
2. Review configurations and access. Check whether clients outside the authorized set can use recursion, with targeted low-volume checks on in-scope assets.
3. Observe asymmetry in a lab. Use your own clients, servers, and destinations on an isolated network to compare message sizes and capture the flow. If the exercise includes spoofed sources, keep it contained within that network and authorized in scope.
4. Validate visibility. Check which events reach monitoring, whether alerts distinguish asset roles, and who receives the report.
5. Repeat after the fix. Compare the same scenarios and confirm legitimate clients can still resolve names.

The record should include the hypothesis, topology, relevant configuration, times, evidence, and expected result. Demonstrating exposure does not require saturating the service. A low-volume demonstration also does not prove resistance to a volumetric attack; that capability requires a specific assessment.

Which signals help investigation?

At the target’s edge, a DNS reflection hypothesis may start with an increase in UDP responses with source port 53, from multiple servers, without corresponding observed queries. At a potential reflector, compare received queries, emitted responses, destinations, and volume growth.

These signals are correlation clues, not isolated proof. Partial captures, asymmetric routes, or telemetry loss can hide legitimate queries. The investigation must relate flows, DNS contents when available, link metrics, and service behavior.

The exercise gains value when it records time to detection, triage quality, and time to initiate mitigation. These are proposed assessment criteria: acceptable limits should be defined by the organization according to its services and operational capability.

Layered mitigation

At the private resolver: limit recursion to authorized clients and review exposure on all relevant interfaces. RFC 5358 recommends that servers not offer recursion to external networks by default.

At authoritative DNS: assess Response Rate Limiting (RRL) and response policies compatible with the service. The BIND 9 documentation describes controlling excessive, similar UDP responses. It also warns that using this on recursive resolvers can harm legitimate applications; restricting open recursion remains preferable in that case.

At the source network: apply source address validation to reduce the departure of forged packets. BCP 38, published as RFC 2827, establishes the filtering practice that combats this spoofing.

On the path to the target: maintain a mitigation plan with the provider or DDoS protection service, including contacts and activation conditions. Indiscriminately blocking DNS traffic can interrupt legitimate resolution, and control must occur where capacity remains to handle the volume.

Each layer acts on a different part of the chain. The Red Team report should show which exposure was confirmed, which control was assessed, and what still requires validation. This link between mechanism, evidence, and correction turns studying DNS amplification into a verifiable security improvement.

As a next step, choose a resolver under your responsibility and document who should be able to use it. Compare the configuration against that expectation and record an authorized low-volume check before considering any availability exercise.