DNS Amplification Attacks Explained

What You Will Learn

• How DNS amplification attacks work, from spoofed queries to reflected floods
• What the amplification factor is and why DNS is particularly vulnerable to it
• The role open resolvers play in enabling amplification attacks
• Prevention techniques for DNS operators, network administrators, and authoritative server owners

What Is a DNS Amplification Attack?

A DNS amplification attack is a type of DDoS attack that exploits the Domain Name System to generate a massive volume of traffic directed at a victim. The attacker sends a small DNS query to a third-party DNS server, but spoofs the source IP address so the response is sent to the victim instead of the attacker.

The "amplification" comes from the fact that DNS responses are typically much larger than the queries that triggered them. A 40-byte query can produce a 3,000-byte response -- a 75x amplification factor. By sending thousands of these small queries per second, the attacker produces a flood of large responses that overwhelms the victim's network.

This is also called a reflection attack because the DNS server "reflects" its response toward the victim. The DNS server is an unwitting participant -- it received what looks like a legitimate query and sent back a legitimate response. The problem is that the response goes to the wrong place.

How DNS Amplification Works: Step by Step

Here is the complete flow of a DNS amplification attack:

Step 1: Attacker sends query with spoofed source IP
┌──────────┐    Query: "dig example.com ANY"    ┌──────────────┐
│          │    Source IP: [VICTIM's IP]          │              │
│ Attacker │ ──────────────────────────────────> │ Open         │
│          │    Packet size: ~40 bytes            │ Resolver     │
└──────────┘                                     └──────┬───────┘
                                                        │
Step 2: Resolver sends large response to victim's IP    │
                                                        │
┌──────────┐    Response: full record set        ┌──────┴───────┐
│          │    Destination: [VICTIM's IP]        │              │
│ Victim   │ <────────────────────────────────── │ Open         │
│          │    Packet size: ~3,000 bytes         │ Resolver     │
└──────────┘                                     └──────────────┘
 
Step 3: Multiply by thousands of resolvers
┌──────────┐         ┌─── Resolver 1 ───> 3KB response ──┐
│          │ ──40B──>├─── Resolver 2 ───> 3KB response ──┤  ┌──────────┐
│ Attacker │ ──40B──>├─── Resolver 3 ───> 3KB response ──├─>│  Victim  │
│          │ ──40B──>├─── Resolver 4 ───> 3KB response ──┤  └──────────┘
└──────────┘ ──40B──>└─── Resolver 5 ───> 3KB response ──┘
             160 bytes in                  15KB out = 93x amplification

The Four Steps in Detail

1. IP spoofing -- The attacker crafts DNS query packets with the source IP address set to the victim's IP. UDP-based protocols like DNS do not require a handshake, so the source address is never verified by the DNS server.

2. Query selection -- The attacker chooses a query type that produces the largest possible response. ANY queries, domains with many record types, and DNSSEC-signed zones produce the biggest responses.

3. Resolver exploitation -- The spoofed queries are sent to open recursive resolvers -- DNS servers that accept queries from any IP address on the internet. These resolvers process the query and send the response to the spoofed source IP (the victim).

4. Traffic flood -- The victim receives a massive volume of unsolicited DNS responses from thousands of resolvers simultaneously. The victim's network link becomes saturated, causing legitimate traffic to be dropped.

Understanding the Amplification Factor

The amplification factor is the ratio between the size of the DNS query and the size of the DNS response. Higher amplification means the attacker needs less bandwidth to generate a devastating flood.

Measuring Amplification with dig

You can measure the amplification factor for any domain using dig. The key metric is the response size compared to the query size.

# Simple A record query -- low amplification
dig example.com A
 
# Look at the bottom of the output:
;; MSG SIZE  rcvd: 56
# Query packet size is approximately 40 bytes
# Amplification factor: 56/40 = 1.4x (minimal)

# ANY query -- returns all record types, high amplification
dig example.com ANY
 
;; MSG SIZE  rcvd: 2847
# Amplification factor: 2847/40 = ~71x

# DNSSEC-signed domain -- signatures add significant size
dig example.com DNSKEY +dnssec
 
;; MSG SIZE  rcvd: 4215
# Amplification factor: 4215/44 = ~96x

# TXT records can be large (SPF, DKIM, verification strings)
dig example.com TXT
 
;; MSG SIZE  rcvd: 1287
# Amplification factor: 1287/40 = ~32x

Amplification Factors by Query Type

The ANY query type is the most commonly abused because it returns every record type for a name in a single response. A domain with A, AAAA, MX, TXT (SPF, DKIM, DMARC), NS, and SOA records can produce a response 50-100x larger than the query. This is why many authoritative servers now refuse or minimize ANY responses.

DNSSEC Makes Amplification Worse

DNSSEC adds cryptographic signatures (RRSIG records) to every record set. While DNSSEC is critical for DNS security, the signatures significantly increase response sizes. A DNSKEY response with multiple keys and signatures can easily exceed 4,000 bytes.

This creates a tension: DNSSEC is essential for preventing cache poisoning, but it also increases the amplification potential. The solution is not to disable DNSSEC, but to implement Response Rate Limiting on the authoritative server, which we cover below.

The Role of Open Resolvers

An open resolver is a recursive DNS server that accepts queries from any IP address on the internet. Open resolvers are the essential ingredient in amplification attacks -- without them, the attacker cannot reflect traffic toward the victim.

Why Open Resolvers Exist

Most open resolvers are not intentionally public. They result from:

• Misconfigured servers -- DNS software often defaults to accepting queries from all sources
• Forgotten infrastructure -- legacy servers that were never properly secured
• Home routers -- consumer routers with DNS forwarding enabled and no access control
• Cloud instances -- virtual machines with DNS services exposed to the public internet

How Many Open Resolvers Exist?

Estimates put the number of open resolvers on the internet at several million. Projects like the Open Resolver Project have worked to identify and notify operators, but the number remains high because new misconfigured servers appear constantly.

How to Check If Your Server Is an Open Resolver

If you operate a DNS server, verify that it does not respond to recursive queries from arbitrary sources.

# Test from an external machine (not on the same network as the server)
# Replace 203.0.113.10 with your server's public IP
 
dig @203.0.113.10 example.com A +recurse
 
# If you get a valid answer, your server is an open resolver.
# You should see REFUSED or no response if properly configured.
 
# Expected output for a properly secured server:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12345
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

# You can also check using an external service
dig @203.0.113.10 whoami.akamai.net TXT +recurse
 
# If this returns an answer, your server is resolving
# recursive queries from the public internet

If your server responds with an answer to recursive queries from external IPs, you have an open resolver. Close it by configuring allow-recursion (BIND), allow-from (PowerDNS Recursor), or the equivalent ACL in your DNS software to restrict recursion to your own networks.

Real-World Examples

DNS amplification has been used in some of the largest DDoS attacks ever recorded:

• Spamhaus (2013) -- A 300 Gbps amplification attack that was the largest recorded at the time, causing collateral damage to internet exchange points across Europe
• GitHub (2018) -- A 1.35 Tbps attack using memcached amplification (a related technique), demonstrating how amplification attacks scale
• AWS (2020) -- A 2.3 Tbps attack targeting AWS infrastructure, the largest volumetric attack publicly reported

These attacks demonstrate that amplification is not a theoretical risk. It is actively used because it is effective and requires minimal resources from the attacker.

The Economics of Amplification

DNS amplification is attractive to attackers because of the asymmetry:

• Attacker bandwidth needed: 1 Gbps
• Amplification factor: 50x
• Victim receives: 50 Gbps
• Cost to attacker: A few compromised machines or a cheap botnet rental
• Cost to victim: Potential complete outage of all services

Prevention for DNS Operators

Response Rate Limiting (RRL)

Response Rate Limiting is the most important defense an authoritative DNS server operator can deploy. RRL tracks how many identical (or near-identical) responses are sent to the same destination IP within a time window. When the rate exceeds a threshold, the server either drops the response or sends a truncated (TC-flagged) response that forces a TCP retry.

Normal traffic:
  Resolver A asks for example.com A → Answer sent
  Resolver B asks for example.com A → Answer sent
  Resolver C asks for example.com MX → Answer sent
 
Amplification attack (without RRL):
  Victim IP asks for example.com ANY → 3KB answer sent
  Victim IP asks for example.com ANY → 3KB answer sent
  Victim IP asks for example.com ANY → 3KB answer sent
  ... millions of times
 
Amplification attack (with RRL):
  Victim IP asks for example.com ANY → 3KB answer sent
  Victim IP asks for example.com ANY → 3KB answer sent
  Victim IP asks for example.com ANY → DROPPED (rate exceeded)
  Victim IP asks for example.com ANY → DROPPED
  Victim IP asks for example.com ANY → TC-flagged (truncated)

RRL is supported by all major DNS server software including BIND, PowerDNS, Knot DNS, and NSD.

Disabling or Minimizing ANY Queries

Since ANY queries produce the largest responses and have almost no legitimate use case, many authoritative servers now return minimal responses to ANY queries. RFC 8482 formally allows DNS servers to return only a subset of records (or an HINFO record) in response to ANY queries.

# A server implementing RFC 8482 minimal ANY response
dig @ns1.example.com example.com ANY
 
;; ANSWER SECTION:
example.com.    3600    IN    HINFO    "RFC8482" ""
 
;; MSG SIZE  rcvd: 65
# Instead of returning all records (~3000 bytes),
# the server returns a single HINFO record (~65 bytes)
# Amplification factor drops from ~75x to ~1.6x

BCP38 / Source Address Validation

BCP38 (RFC 2827) defines network ingress filtering -- verifying that packets leaving a network have a source IP address that actually belongs to that network. If all networks implemented BCP38, IP spoofing would be impossible and amplification attacks could not exist.

Unfortunately, BCP38 adoption is incomplete. Many networks -- particularly in regions with less mature internet infrastructure -- still allow spoofed packets to leave their network. This is a community-wide problem, not something an individual DNS operator can solve alone.

BCP38 is the only prevention measure that eliminates amplification attacks entirely. Every other defense mitigates the damage. If you operate a network, implementing BCP38 protects the entire internet, not just your own infrastructure. Check your network's compliance at CAIDA's Spoofer project.

Prevention for Authoritative Server Operators

If you operate authoritative DNS servers (as opposed to recursive resolvers), here are specific steps to reduce your servers' usefulness in amplification attacks.

1. Enable Response Rate Limiting

Configure RRL on your authoritative servers. This is the single most effective measure.

2. Minimize Response Sizes

• Return minimal responses to ANY queries (per RFC 8482)
• Avoid unnecessarily large TXT records -- keep SPF records consolidated
• Consider the response size implications when adding many record types to a single name

3. Monitor for Abuse

Watch for sudden spikes in query volume from single source IPs or subnets, particularly for ANY or DNSKEY query types. These patterns indicate your server is being used as an amplifier.

# You can test your own authoritative server's response sizes
# to understand your amplification exposure
 
# Check the largest responses your server produces
dig @your-ns.example.com example.com ANY +bufsize=4096
 
# Check DNSSEC response sizes
dig @your-ns.example.com example.com DNSKEY +dnssec +bufsize=4096
 
# Look at the MSG SIZE line to understand your amplification factor

4. Use Anycast

Operating your authoritative servers on an anycast network means that even if your servers are used in an amplification attack, the reflected traffic is distributed across multiple POPs rather than originating from a single source IP. This does not prevent your server from being an amplifier, but it reduces the impact.

How DNScale Prevents Amplification

DNScale's architecture addresses DNS amplification at multiple levels.

Not an Open Resolver

DNScale operates authoritative-only DNS servers. The nameservers do not perform recursive resolution for external queries. This eliminates the primary vector for amplification -- an attacker cannot send recursive queries to DNScale's nameservers and have them fetch and amplify responses from other domains.

# DNScale nameservers refuse recursive queries
dig @ns1.dnscale.com google.com A +recurse
 
;; ->>HEADER<<- opcode: QUERY, status: REFUSED
# Only queries for zones hosted on DNScale are answered

Response Rate Limiting

Every DNScale edge POP implements RRL. If an attacker attempts to use DNScale's authoritative servers as amplifiers by querying hosted zones with spoofed source IPs, the rate limiter detects the pattern and drops or truncates excessive identical responses to the same destination.

Anycast Absorption

DNScale's dual anycast networks (AS44794 for EU, AS62406 for global) mean that any amplified traffic reflected from DNScale servers is spread across multiple POPs. Combined with RRL, this makes DNScale's servers poor candidates for amplification -- the amplification factor is minimized by RRL, and whatever traffic does get reflected is distributed rather than concentrated.

Minimal ANY Responses

DNScale returns minimal responses to ANY queries, in line with RFC 8482. This reduces the maximum amplification factor for any query to DNScale's nameservers, regardless of how many record types a zone contains.

Using a managed DNS provider like DNScale means you benefit from these protections without configuring them yourself. Self-hosted DNS servers require manual RRL configuration, ongoing monitoring, and careful access control -- tasks that managed providers handle as part of their infrastructure.

Detecting If You Are Part of an Amplification Attack

You might be an unwitting participant in an amplification attack in two ways:

As the Reflector

Your DNS server is being used to amplify traffic toward a victim. Signs include:

• Sudden spike in inbound queries, particularly ANY or DNSKEY types
• High outbound bandwidth relative to inbound
• Queries for domains you do not host (if you are running a resolver)
• Many queries with source IPs from a single subnet or geographic region

As the Victim

You are receiving the amplified traffic. Signs include:

• Massive inbound DNS response traffic that you did not request
• Responses from thousands of different DNS server IPs
• All responses are for the same query (e.g., example.com ANY)
• Your network link is saturated with UDP port 53 traffic

# If you suspect you are receiving amplified traffic,
# check whether DNS responses are arriving unsolicited
 
# Look for inbound UDP port 53 traffic on your network
# (run on a server with tcpdump access)
# tcpdump -i eth0 -n 'udp src port 53' -c 100
 
# If you see hundreds of DNS responses per second from
# servers you never queried, you are likely a victim

Key Takeaways

• DNS amplification exploits the size difference between DNS queries and responses, plus UDP's lack of source verification, to flood victims with reflected traffic
• Amplification factors of 50-100x are achievable with ANY queries and DNSSEC-signed responses
• Open recursive resolvers are the primary enablers -- close yours if you have one
• Response Rate Limiting (RRL) is the most effective server-side defense
• BCP38 source address validation at the network level would eliminate amplification entirely
• DNScale prevents amplification by running authoritative-only servers with RRL, minimal ANY responses, and anycast distribution

Further Reading

• What Is a DDoS Attack? -- broader overview of all DDoS attack types
• What Is DNS? -- how the Domain Name System works
• DNS Record Types -- understanding the records involved in amplification
• Anycast DNS vs Unicast DNS -- why anycast matters for DDoS resilience
• DNSSEC and DNS Security -- securing DNS without increasing amplification risk
• What Is an NS Record? -- nameserver delegation and its role in DNS architecture
• DNS Attacks and Threats -- full catalogue of DNS attack vectors
• Managed DNS vs Self-Hosted DNS -- why managed DNS provides better protection