What is DNS Amplification? How DNS Reflection Attacks Work

In March 2013, an attack against Spamhaus generated approximately 300 Gbps of traffic — a record at the time — using public DNS servers as amplifiers. The attacker sent small DNS queries with the victim’s IP address forged as the source, and servers around the world delivered amplified responses directly to Spamhaus. This is the principle of DNS Amplification.

A DNS Amplification attack is a reflection DDoS attack that abuses the DNS protocol, normally transported over UDP, to generate volumetric traffic against a victim. Although the exploited protocol belongs to the application layer, the predominant impact typically falls on bandwidth, packets per second, and network capacity in the lower layers. The attack uses IP spoofing to direct third-party responses toward the target.

DNS Amplification vs. DNS Flood — conceptual difference

Before deepening the mechanism, it is useful to differentiate two attacks that are frequently confused:

EDNS(0) (RFC 6891) — how it enables larger responses

The original DNS protocol specification (RFC 1035) limits the maximum UDP message size to 512 bytes. EDNS(0) (Extension Mechanisms for DNS, RFC 6891) introduced an extension mechanism that allows the client to announce a larger maximum UDP payload size, through an OPT pseudotype record in the additional section of the query.

The size actually used depends on the client-announced value, server configuration, network path, and policies to avoid fragmentation. Although larger values, such as 4,096 bytes, have been common in some configurations, many operators adopt smaller limits — often around 1,232 bytes — to reduce fragmentation issues.

EDNS(0) can significantly increase the amplification potential by allowing UDP responses larger than 512 bytes. However, DNS reflection does not depend exclusively on EDNS(0): smaller queries can still trigger larger responses, and the actual factor depends on the query type, the zone, server configuration, DNSSEC use, and response size policies.

When a response must be delivered over TCP, the reflection potential is reduced because establishing the connection requires the three-way handshake. An attacker forging the victim’s IP does not receive the SYN-ACK and, under normal conditions, cannot complete the connection needed to obtain the TCP response. EDNS(0) keeps the amplification vector operational over UDP by enabling larger responses without requiring a connection.

How DNS reflection and amplification works

The attack combines IP spoofing with the size asymmetry between query and response over UDP. The mechanism occurs in chained steps:

In the first step, the attacker sends DNS queries with the source IP forged — replacing their own address with the victim’s address. The query is small and may declare EDNS(0) support with a larger payload size. The chosen record type is one that tends to generate a larger response.

In the second step, the DNS server responds to the source IP address present in the UDP datagram. Because UDP requires no handshake and the source address may have been forged, the response is sent to the victim indicated by the attacker.

In the third step, the victim receives responses it never requested. When the attacker uses multiple DNS servers in parallel, responses converge simultaneously to the victim, generating volumetric traffic that can pressure its network capacity.

Amplification potential by query type

The amplification factor varies considerably with query type, server, zone, DNSSEC use, response configuration, UDP limits, and the network path. The descriptions below are qualitative, not universal.

RFC 8482 — minimal responses for ANY queries

Historically, ANY queries were a relevant DNS amplification vector because they could return multiple record sets associated with the queried name, generating larger responses. RFC 8482, published in 2019, defines minimal responses for ANY DNS queries, reducing the historical practice of responding with all available RRsets for the queried name. An implementation may respond with a synthesized HINFO record or another minimal set of data, according to the adopted policy.

This behavior reduces the amplification potential associated with ANY queries in implementations that adopt it. It does not eliminate other query types or sources of large DNS responses, such as queries for DNSSEC, DNSKEY, or TXT records, depending on configuration and zone. Adoption is not universal, and the effective behavior depends on the implementation and the operator’s policy.

Open resolvers and authoritative servers as reflectors

An open DNS resolver is a DNS server configured to answer recursive queries from any IP address on the internet — not just authorized clients. This configuration turns the server into a potential amplifier for DNS Amplification.

Historically, open resolvers were an important amplification source because they accept recursive queries from any origin. However, publicly accessible authoritative servers can also be used as reflectors when they respond to queries with a forged source IP. Exposure and defense measures differ between recursive and authoritative services.

The number of exposed and permissive resolvers varies over time and depends on the measurement methodology. Scanning projects and DNS operators continuously identify open recursive servers on the internet, but global numbers should be presented only with a verifiable source, date, and methodology.

Variations: other UDP protocols used in reflection

DNS Amplification is the most documented case, but the principle of reflection and amplification over UDP applies to other protocols:

NTP Amplification: exploits the NTP protocol. The monlist command (associated with legacy or misconfigured servers) historically returned large client lists in response to a small request. Less prevalent today because modern, updated NTP servers generally disable this behavior by default.

SSDP Amplification: uses the UPnP/SSDP protocol present in IoT devices. Devices that expose SSDP on the internet can be abused as reflectors. The vector persists due to the large number of unnecessarily exposed IoT devices.

CLDAP Amplification: uses the CLDAP (Connectionless LDAP) protocol. Exposed LDAP servers can be abused as reflectors. Less documented but possible in networks with publicly accessible LDAP servers.

Mitigation techniques

BCP 38 — IP spoofing filtering at the source

RFC 2827 (BCP 38) guides ISPs to filter packets with invalid or impossible source addresses leaving their networks. If a client sends a packet with a source IP that does not belong to the IP block allocated to them, the ISP can discard that packet before forwarding it to the internet.

Wide and correct adoption of source filtering would drastically reduce reflection attacks that depend on IP spoofing on the public internet. It does not eliminate DDoS attacks carried out by botnets with real IPs, nor does it replace other defense layers.

Adoption of source filtering remains incomplete and uneven across networks. Projects such as the CAIDA Spoofer Project provide evidence that IP spoofing is still possible from part of the internet, but their results must be interpreted according to coverage and measurement methodology — not generalized as definitive global percentages.

Response Rate Limiting (RRL) on DNS servers

RRL limits the issuance of repetitive or similar DNS responses according to criteria defined by the implementation and the operator’s policy. It is especially useful on authoritative servers to reduce the potential for abuse in reflection and amplification.

RRL does not replace disabling open recursion, anti-spoofing filtering, or infrastructure sizing. Its parameters need to be tested to avoid impact on legitimate clients and in scenarios of high real demand.

Disabling open recursion on resolvers

DNS resolvers should be configured to respond only to authorized clients through IP-based ACLs. An example configuration in BIND for restricting recursion:

options {
    allow-recursion { trusted-clients; };
    allow-query-cache { trusted-clients; };
};

This example assumes the trusted-clients ACL is already defined and that the server is intended only for resolution for authorized networks. Before applying changes in production, validate the configuration according to the BIND version in use, the separation between recursive and authoritative services, and the needs of legitimate clients. Legitimate public resolvers have a different operational model and must not simply apply this restriction without proper planning.

Anycast for traffic distribution

With Anycast, the same IP prefix is announced via BGP from multiple points of presence. BGP policies can direct different sources to different points, helping to distribute traffic and bring mitigation closer to part of the origins.

The actual distribution is not necessarily uniform or based solely on geographic proximity: it depends on routing policies, peering, capacity, and topology. Therefore, Anycast should be combined with adequate capacity, telemetry, and mitigation mechanisms at each point of presence.

Scrubbing centers and upstream filtering

Scrubbing centers are specialized infrastructure for inspection and filtering of volumetric traffic. In parts of the network that observe both queries and responses, controls can correlate received DNS responses with previously observed queries and reduce unsolicited traffic.

This correlation depends on bidirectional visibility, route asymmetry, NATs, DNS resolution architecture, and timeout policies. UDP port 53 in isolation is not sufficient evidence of an attack — it also carries legitimate DNS traffic.

Detection with NetFlow, sFlow, and network telemetry

Detecting DNS Amplification requires network telemetry analysis. NetFlow and sFlow typically provide flow metadata — addresses, ports, volume, PPS, duration — but not DNS payload content. To identify EDNS(0), QTYPE, OPT records, or specific DNS content, DPI, packet capture, DNS sensor, or specialized appliance telemetry is needed.

In networks with bidirectional visibility of UDP/53 queries and responses, legitimate DNS traffic tends to show temporal correlation between sent queries and received responses. The ratio is not necessarily 1:1, since cache, retransmissions, timeouts, DNSSEC, NATs, multiple resolvers, and other factors can alter the pattern. The most indicative signal of amplification is high volume of UDP responses with source port 53 without corresponding visible outbound queries.

Operational detection signals

Common mistakes and guidance

Blocking all inbound UDP traffic on port 53: this also blocks legitimate DNS responses from external resolvers. Use controls that correlate responses to queries sent by the network to distinguish solicited traffic from unsolicited reflected responses.

Relying only on blackhole routing to mitigate the attack: blackhole routing discards all traffic to the victim’s IP, including legitimate traffic — completing the attacker’s objective. Use selective scrubbing where possible.

Not configuring RRL on your own authoritative DNS server: even if not an open resolver, an authoritative DNS server can be used in reflection attacks if it accepts queries from any source. RRL can limit the volume of repetitive or similar responses according to criteria defined by the implementation and the operator’s policy, reducing reflection potential. Configuration requires tuning to avoid affecting legitimate clients.

Ignoring IoT devices as potential SSDP amplifiers: segment IoT devices in isolated VLANs and evaluate blocking outbound SSDP traffic to the public internet. Devices with UPnP enabled and exposed may be recruited as amplifiers.

Frequently asked questions

Why is UDP used instead of TCP in DNS Amplification? UDP does not require a handshake, so the attacker can send queries with a forged IP without establishing a real connection. EDNS(0) allows UDP responses larger than 512 bytes, increasing the available asymmetry. With TCP, the three-way handshake would make IP spoofing much harder: the server would send the SYN-ACK to the victim’s IP, which would never complete the handshake, and the attacker would not receive the amplified response.

What is the role of EDNS(0) in the attack? EDNS(0) can increase amplification potential by allowing UDP responses larger than 512 bytes. The actual factor depends on the query, server, announced size, DNSSEC, response configuration, and network path. DNS reflection existed before EDNS(0) — smaller queries can still trigger larger responses in certain scenarios.

Does RFC 8482 completely eliminate the ANY query vector? In implementations that apply minimal responses to ANY queries, the usefulness of that query type as an amplification vector is significantly reduced. This does not eliminate other query types or sources of large DNS responses. The effective behavior depends on the implementation and the operator’s policy.

Does DNS Amplification only affect open resolvers? No. Publicly accessible authoritative servers can also be used as reflectors when they respond to queries with a forged source IP. The ultimate target of the attack is the victim whose link is saturated — DNS servers are used as intermediaries, not as targets.

Does BCP 38 completely solve the problem? Wide and correct adoption of source filtering would drastically reduce reflection attacks that depend on IP spoofing on the public internet. It does not eliminate DDoS attacks carried out by botnets with real IPs, nor does it replace other defense layers. Adoption remains incomplete and uneven, which keeps the vector operational and makes complementary measures such as RRL, Anycast, and scrubbing necessary.

How do you distinguish a legitimate DNS traffic spike from a reflected attack? The distinction is made by the flow pattern. In networks with bidirectional visibility, legitimate DNS traffic tends to show correlation between sent queries and received responses. A reflected attack may generate high volume of UDP responses with source port 53 without previously observed outbound DNS queries matching the expected flow. This correlation depends on bidirectional visibility, NAT, route asymmetry, and state timeouts. Confirming EDNS(0), QTYPE, and the actual response size requires packet capture or DPI.

How to implement on Azion

Azion can compose a mitigation strategy against DNS reflection and amplification attacks, according to contracted products, published protocols, and configured policies.

1. Distributed network controls: a distributed architecture can help absorb and filter anomalous UDP traffic before it reaches the origin. The effective behavior depends on topology, capacity, routes, and applied policies.

2. Volumetric traffic mitigation: DDoS protection resources and network policies can help detect increases in PPS and bandwidth associated with reflection attacks, applying controls according to the observed traffic profile.

3. DNS service protection: for published DNS services, configuration controls, response limiting, and access policies can reduce the risk of resolvers or authoritative servers being abused as reflectors, according to enabled resources.

4. Observability: logs, metrics, and network telemetry can help identify anomalous UDP traffic, volume changes, source distribution, and link pressure during an incident.

Effective coverage depends on the DNS architecture, published services, enabled products, configured policies, and the attack profile.

Learn more in the Azion DDoS Protection documentation.