What is DNS Amplification? How DNS Reflection Attacks Work

A DNS amplification attack is a volumetric DDoS technique that exploits open DNS resolvers to generate large amounts of traffic directed at a victim. The attacker sends small DNS queries using the victim’s spoofed IP address as the source; the DNS resolvers send large responses to the victim, amplifying the attacker’s bandwidth by a factor of 28 to 70 times.

Last updated: 2026-08-24

TL;DR: DNS amplification uses open DNS resolvers and IP spoofing to flood a victim with traffic the attacker never sent directly. A 60-byte DNS query returns a 4,000-byte response—an amplification factor of ~70x. Mitigation requires network ingress filtering (BCP38), DNS response rate limiting (DNS RRL), and cloud-based DDoS scrubbing with sufficient capacity to absorb amplified volumes.

How DNS Amplification Works

The attack exploits two properties of DNS: it runs over UDP (connectionless—no handshake required to validate source IPs) and certain DNS responses can be many times larger than the query.

Attack flow:

Step 1: Attacker sends small DNS query with spoofed source IP (victim's IP)
Attacker → Open Resolver: "ANY example.com?" (60 bytes, source IP = victim)

Step 2: Open resolver sends large response to the spoofed source (victim)
Open Resolver → Victim: DNS response (4,000 bytes)

Step 3: Attacker sends millions of queries using thousands of open resolvers
10,000 resolvers × 1,000 queries/sec × 4,000 bytes = 40 Gbps to victim

Attacker's bandwidth used: 10,000 × 1,000 × 60 bytes = 600 Mbps
Amplification: 40 Gbps / 600 Mbps ≈ 67x

Why UDP enables this attack:

TCP requires a three-way handshake (SYN → SYN-ACK → ACK) that validates the source IP before data transfer. A spoofed SYN packet receives the SYN-ACK at the real victim, but the victim responds with RST, closing the connection before data flows. UDP has no handshake—the resolver immediately responds to whoever the source IP claims to be, with no verification.

Amplification Factors by Protocol

DNS amplification is one of several UDP-based amplification attacks. The amplification factor represents how many bytes of response are generated per byte of query:

DNS amplification is not the highest amplification factor—Memcached attacks in 2018 reached amplification factors of 50,000x—but DNS amplification remains common because millions of open resolvers are accessible on the public internet.

Role of Open DNS Resolvers

An open DNS resolver is a DNS server configured to answer queries from any IP address, not just its own users. Open resolvers are misconfigured infrastructure—they were intended to serve specific networks but were left accessible to the entire internet.

In 2024, the Open Resolver Project estimated that between 2 and 15 million open resolvers remain accessible on the public internet. Each can be used as an amplifier without the resolver operator’s knowledge or consent.

What makes a DNS query large:

• ANY queries request all record types for a domain—A, AAAA, MX, NS, TXT, SOA, etc.—returning the maximum amount of data
• DNSSEC-signed domains include digital signatures in responses, increasing response size by 3–10x
• EDNS0 (Extension Mechanisms for DNS, RFC 6891) allows responses up to 4,096 bytes, compared to the original 512-byte limit

In 2023, RFC 8482 deprecated the DNS ANY query type because it was primarily used for amplification attacks. Modern resolvers that implement RFC 8482 return a minimal response to ANY queries, reducing their utility as amplifiers.

Historical Attacks

The 2013 Spamhaus attack, then the largest DDoS ever recorded at 300 Gbps, used DNS amplification almost exclusively.

Mitigation Strategies

Network Level

BCP38 / Ingress Filtering (RFC 2827)

BCP38 requires ISPs to drop packets leaving their network with source IPs outside the ISP’s assigned range. This prevents attackers from spoofing victim IPs—without IP spoofing, DNS amplification does not work because responses return to the actual attacker rather than the victim. Widespread BCP38 adoption would eliminate DNS amplification.

Impact: CAIDA’s Spoofer Project estimated in 2024 that approximately 25–30% of Autonomous Systems (ASes) still allow source IP spoofing, down from ~35% in 2018 but still representing millions of potential attack sources.

DNS Server Level

DNS Response Rate Limiting (DNS RRL)

DNS RRL, implemented in BIND 9.10+ and Unbound, limits the rate at which a resolver responds to queries from any single source IP. This reduces how many amplified responses a resolver will send per second, limiting its utility as an amplifier without affecting normal query rates.

Restrict recursive queries to authorized users

Configure DNS resolvers to answer recursive queries only from specific IP ranges (your own customers or network), not from arbitrary internet IPs. This converts an open resolver to a closed resolver.

BIND named.conf example:
options {
    allow-recursion { 192.168.0.0/16; 10.0.0.0/8; };
};

Implement RFC 8482 (ANY query deprecation)

Modern DNS servers should return minimal responses to ANY queries rather than all record types, eliminating the high amplification factor.

DDoS Protection Service

Cloud-based DDoS mitigation services absorb amplified traffic before it reaches your network. Because amplified attacks can exceed the capacity of your uplink, protection must be upstream—at the scrubbing center or distributed edge network.

Azion’s distributed network absorbs DDoS traffic across edge locations with sufficient aggregate capacity to handle amplification attacks. Traffic is mitigated before reaching your origin.

Frequently Asked Questions

What is a DNS amplification attack? A DNS amplification attack is a DDoS technique where an attacker sends DNS queries with the victim’s spoofed IP to open resolvers, which respond with large DNS packets to the victim. This amplifies the attacker’s bandwidth by up to 70 times, flooding the victim without requiring the attacker to generate equivalent traffic.

What is an open DNS resolver? An open DNS resolver is a DNS server that answers recursive queries from any IP address on the internet, not just from its own network or customers. Open resolvers are misconfigured servers that are exploited as amplifiers in DNS reflection attacks. Properly configured recursive resolvers should only answer queries from authorized users.

What is the amplification factor in a DNS attack? The amplification factor is the ratio of response bytes to query bytes. A DNS ANY query of 60 bytes can generate a response of up to 4,000 bytes—an amplification factor of approximately 67x. This means the attacker generates 67 times more traffic toward the victim than the bandwidth the attacker uses.

How does IP spoofing work in DNS amplification? UDP allows packets to be sent with an arbitrary source IP address without any handshake to verify the source. The attacker sends DNS queries with the victim’s IP as the source. The DNS resolver, unaware of the spoofing, sends its response to the victim IP. The attacker never receives the response; the victim receives all the amplified traffic.

Does DNSSEC make DNS amplification worse? DNSSEC makes individual DNS responses larger because responses include digital signatures. DNSSEC-signed domains produce responses 3–10x larger than unsigned domains, increasing the amplification factor for attacks against DNSSEC-signed zones used as query targets. DNSSEC itself is important for authentication but does increase amplification risk when open resolvers answer queries for signed zones.

What is BCP38 and does it prevent DNS amplification? BCP38 (RFC 2827) is a network filtering practice that instructs ISPs to drop packets leaving their network with spoofed source IPs. Because DNS amplification requires IP spoofing to redirect responses to the victim, BCP38 prevents the attack from working when implemented by the attacker’s ISP. However, BCP38 adoption is incomplete, leaving many networks as potential spoofing origins.

Can DNS amplification attacks be mitigated without BCP38? Yes. DNS response rate limiting (RRL) on DNS servers reduces the amplification output per resolver. Cloud DDoS protection absorbs amplified traffic at scale. However, these are reactive—they manage the impact rather than preventing the attack mechanism. BCP38 is the only solution that prevents spoofing at the source.

What replaced ANY queries to reduce amplification? RFC 8482 (January 2019) deprecated the DNS ANY query type. Rather than returning all record types, compliant resolvers return a minimal response (HINFO record or minimal data). This eliminates the high-amplification use of ANY queries. Adoption is growing but not universal.

How to Implement on Azion

Azion’s globally distributed network absorbs DNS amplification attacks before they reach your infrastructure:

• DDoS Protection provides always-on mitigation with no configuration required, absorbing amplified UDP traffic at the edge
• Network Layer Protection applies network-level rules to identify and block amplification attack patterns
• Edge Firewall enables custom rules for traffic filtering at the network layer

For DNS infrastructure specifically, ensure your authoritative DNS servers implement DNS RRL and restrict recursive queries to authorized networks.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is DDoS Protection and Mitigation?
• Azion DDoS Protection
• Azion Network Layer Protection

Sources:

• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
• IETF. “Extension Mechanisms for DNS (EDNS(0)).” RFC 6891. 2013.
• IETF. “Minimal Responses for DNS Queries with QTYPE=ANY.” RFC 8482. 2019.
• ISC BIND. “DNS Response Rate Limiting.” ISC Knowledge Base, 2024.
• CAIDA. “Spoofer Project Results.” 2024.
• CISA. “UDP-Based Amplification Attacks.”
• IETF. RFC 5358: “Preventing Use of Recursive Nameservers in Reflector Attacks.”
• US-CERT. “DNS Amplification Attacks.” 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.