DNS Amplification Attack
A DNS amplification attack is a reflection-based distributed denial-of-service (DDoS) attack that exploits open DNS resolvers to multiply attack traffic by factors of 28-54x. The attacker sends small DNS queries (typically 60 bytes) with the victim's spoofed source IP address, causing resolvers to send their much larger responses (up to 4,000+ bytes) to the victim, saturating network bandwidth with legitimate-looking DNS traffic that is difficult to filter.
How DNS Amplification Attack Works
DNS amplification combines three techniques: IP spoofing, reflection, and amplification. The attacker sends DNS queries to open recursive resolvers — publicly accessible DNS servers that accept queries from any IP — with the source IP spoofed to the victim's address. The query is crafted to produce the largest possible response: an ANY query for a domain with extensive records (TXT, DNSSEC, MX, NS, SOA) can return 2,000-4,000 bytes from a 60-byte query. The resolver, behaving normally, sends this large response to what it believes is the requestor — the victim. With 30,000+ open resolvers available on the internet, an attacker with 1 Gbps of outbound capacity can generate 28-54 Gbps aimed at the victim. The reflected traffic originates from thousands of legitimate DNS servers worldwide, making source-based filtering nearly impossible without also blocking real DNS responses.
Scan for open recursive DNS resolvers
The attacker scans the internet for DNS servers that accept recursive queries from any source IP address. Tools send DNS queries to port 53 across IP ranges and record servers that respond with full recursive resolution. Despite years of guidance to restrict recursion, surveys consistently find 2-3 million open resolvers globally. The attacker builds a list of thousands of resolvers, prioritizing those with high bandwidth connections and low response latency — typically resolvers hosted in data centers, universities, and ISP networks.
Craft queries that maximize response size
The attacker selects DNS query types that produce the largest amplification factor. The ANY query type requests all record types for a domain and can return responses 28-54x larger than the query. Domains with extensive DNSSEC records (RRSIG, DNSKEY, DS) produce even larger responses because the cryptographic signatures add significant data. The attacker may register their own domain and configure it with dozens of TXT records containing maximum-length strings (255 bytes each), artificially inflating the response size to 4,000+ bytes — achieving amplification factors exceeding 70x.
Flood resolvers with spoofed-source queries
Using raw sockets or a botnet, the attacker sends the crafted DNS queries to all collected resolvers with the UDP source IP address set to the victim's IP. Since DNS uses UDP, which has no handshake or connection verification, the resolvers have no way to validate that the query actually came from the victim's IP. Each resolver processes the query normally — performing recursive resolution if the answer isn't cached — and sends the full response to the spoofed source address. The attacker distributes queries across thousands of resolvers to avoid triggering rate limits on any individual server.
Overwhelm the victim with amplified reflected traffic
The victim receives massive DNS responses from thousands of legitimate DNS servers simultaneously. An attacker with a modest 1 Gbps botnet generating 60-byte queries across 30,000 resolvers can produce 28-54 Gbps of attack traffic directed at the victim. The victim's network link saturates, dropping both attack traffic and legitimate traffic indiscriminately. Because the traffic originates from real, legitimate DNS servers worldwide, the victim cannot simply blackhole the source IPs without also losing access to DNS resolution.
Sustain and adapt the attack
The attacker maintains the flood by rotating through resolver lists, switching query types if resolvers begin rate-limiting ANY queries, and adjusting packet rates to stay just above the victim's capacity. Some attackers combine DNS amplification with other vectors (NTP amplification, SSDP reflection, SYN floods) to create multi-vector attacks that are harder to mitigate because each vector requires different filtering strategies. The attack persists until the resolver operators detect abuse, the attacker's botnet is disrupted, or the victim deploys upstream scrubbing that can absorb the volume.
Real-World Examples
Spamhaus attack — DNS amplification enters mainstream awareness
In March 2013, a dispute between Spamhaus (an anti-spam organization) and the Dutch hosting provider CyberBunker escalated into the largest DDoS attack recorded at the time: 300 Gbps of DNS amplification traffic. The attacker used approximately 30,000 open DNS resolvers to amplify queries, achieving roughly 100x amplification through carefully crafted ANY queries for domains with large zone files. The attack was so massive it caused measurable congestion at major Internet Exchange Points in London, Amsterdam, and Frankfurt, briefly slowing internet traffic across Western Europe.
Brazilian banking sector DNS amplification campaign
A sustained DNS amplification campaign targeted multiple major Brazilian banks during a peak business period, generating attacks exceeding 500 Gbps. The attackers exploited thousands of misconfigured DNS resolvers across Latin American ISPs to amplify traffic directed at the banks' public-facing infrastructure. Online banking portals, payment processing APIs, and ATM networks that depended on DNS-reachable services were disrupted for hours across multiple institutions, affecting millions of customers and causing significant financial transaction failures.
Taiwanese government and infrastructure attacks
During heightened geopolitical tensions in August 2022, Taiwanese government websites, transportation systems, and financial institutions faced coordinated DDoS attacks that included significant DNS amplification components. The presidential office, defense ministry, and foreign affairs ministry websites were taken offline, while convenience store chains and railway station displays were defaced. Attack volumes exceeded 20 Gbps against individual targets, leveraging open resolvers across the Asia-Pacific region.
Impact & Risk Assessment
DNS amplification attacks are among the most effective volumetric DDoS techniques because they combine high amplification ratios (28-54x, up to 70x with crafted zones) with virtually unlimited reflector infrastructure — millions of open resolvers exist worldwide. The attack requires no botnet for the amplification itself; a single server with spoofing capability can generate hundreds of gigabits of reflected traffic. Impact extends beyond the immediate target: upstream ISP links saturate, affecting all customers sharing the same network segment; collateral damage to DNS infrastructure occurs as resolvers struggle under query loads; and the victim's IP reputation may be damaged as resolvers begin blacklisting the victim's address for generating 'excessive' traffic (the reflected responses). Financial impact includes bandwidth overage charges (cloud providers bill for inbound DDoS traffic in some configurations), emergency mitigation costs, SLA violations, and lost revenue during downtime. For organizations relying on UDP-based services (VoIP, gaming, streaming), DNS amplification is particularly devastating because filtering requires careful protocol-aware inspection to avoid dropping legitimate DNS responses.
How to Detect DNS Amplification Attack
Monitor the ratio of inbound DNS responses to outbound DNS queries — during normal operation this ratio is approximately 1:1, while during an amplification attack the victim receives thousands of DNS responses without having sent corresponding queries. Set alerts for unsolicited DNS responses (source port 53, destination random high ports) arriving at rates exceeding baseline. Analyze DNS response sizes: legitimate DNS responses average 100-500 bytes, while amplification attack traffic contains responses of 2,000-4,000+ bytes, skewing the size distribution dramatically. Track unique source IPs of inbound DNS traffic: a sudden increase from dozens to thousands of unique DNS server IPs indicates reflection. Deploy NetFlow or sFlow analysis at the network edge to identify DNS-heavy traffic patterns before they saturate the link — flow data can reveal amplification signatures (UDP port 53, high byte-to-packet ratios, diverse sources) even when individual flows appear legitimate. For DNS operators: monitor your own resolver for abuse by tracking query rates per source IP, detecting queries with source IPs outside your expected client range, and alerting on sudden spikes in ANY or DNSSEC record queries.
How to Prevent DNS Amplification Attack
For attack targets: deploy upstream DDoS mitigation (cloud-based scrubbing services or BGP-based traffic diversion) that can absorb amplified traffic volumes before they reach your network. Configure your border routers to rate-limit inbound DNS responses if your network does not host public DNS services — legitimate DNS responses should only arrive in proportion to queries you sent. Implement BCP 38 (RFC 2827) source address validation on your network edge to prevent your own infrastructure from being used as an attack source. For DNS operators: disable open recursion immediately — configure your resolver to only accept recursive queries from authorized client networks. Implement Response Rate Limiting (RRL) to throttle identical responses to the same destination, which directly counters amplification abuse. Drop or restrict ANY queries (RFC 8482 recommends returning minimal responses to ANY). Enable DNSSEC validation but be aware that DNSSEC responses are larger and increase amplification potential — combine with RRL. For the internet community: widespread adoption of BCP 38 by ISPs would eliminate IP spoofing and make DNS amplification impossible, but adoption remains incomplete decades after the standard was published.
Code Examples
# /etc/named.conf — BIND 9 configuration to prevent resolver abuse
acl "trusted-clients" {
192.168.0.0/16;
10.0.0.0/8;
172.16.0.0/12;
# Add your legitimate client networks here
};
options {
directory "/var/named";
listen-on { any; };
# CRITICAL: Only allow recursion for trusted clients
# This single setting prevents your server from being an open resolver
recursion yes;
allow-recursion { trusted-clients; };
allow-query-cache { trusted-clients; };
# Allow anyone to query authoritative zones (if you host zones)
# but deny recursive resolution to the world
allow-query { any; };
# Response Rate Limiting — throttle identical responses to same destination
# Directly counters amplification by limiting how many times
# the same answer is sent to the same IP per second
rate-limit {
responses-per-second 5; # Max 5 identical responses/sec to same /24
nxdomains-per-second 2; # Limit NXDOMAIN responses
referrals-per-second 5; # Limit referral responses
errors-per-second 2; # Limit error responses
window 5; # 5-second sliding window
log-only no; # Enforce, don't just log
};
# Minimize ANY responses (RFC 8482)
# Modern BIND can return minimal responses to ANY queries
minimal-any yes;
# Disable zone transfers to unauthorized servers
allow-transfer { none; };
# DNSSEC validation (verify responses, don't just relay)
dnssec-validation auto;
};
import subprocess
import time
import logging
from collections import defaultdict
logger = logging.getLogger('dns_amplification_monitor')
def get_dns_traffic_stats(interface='eth0', duration=10):
"""Capture DNS traffic and analyze for amplification indicators"""
# Count inbound DNS responses (source port 53) vs outbound queries (dest port 53)
result = subprocess.run(
['timeout', str(duration), 'tcpdump', '-i', interface, '-n',
'-c', '50000', 'udp port 53', '-q', '--immediate-mode'],
capture_output=True, text=True, timeout=duration + 5
)
inbound_responses = 0 # src port 53 → we're receiving DNS answers
outbound_queries = 0 # dst port 53 → we're sending DNS queries
response_sources = set()
total_bytes = 0
for line in result.stdout.strip().split('\n'):
if not line.strip():
continue
# tcpdump output: "IP src.port > dst.port: UDP, length N"
if '.53 >' in line and 'UDP' in line:
inbound_responses += 1
# Extract source IP
parts = line.split()
for p in parts:
if '.53' in p and '>' not in p:
src_ip = p.rsplit('.', 1)[0]
response_sources.add(src_ip)
# Extract packet length
for p in parts:
if p.isdigit() and int(p) > 0:
total_bytes += int(p)
break
elif '> ' in line and '.53:' in line:
outbound_queries += 1
return {
'inbound_responses': inbound_responses,
'outbound_queries': outbound_queries,
'unique_sources': len(response_sources),
'total_bytes': total_bytes,
'avg_response_size': total_bytes / max(inbound_responses, 1),
'duration': duration
}
def monitor_amplification(check_interval=30):
"""Continuous monitoring for DNS amplification indicators"""
while True:
stats = get_dns_traffic_stats()
ratio = stats['inbound_responses'] / max(stats['outbound_queries'], 1)
avg_size = stats['avg_response_size']
sources = stats['unique_sources']
# Indicator 1: Receiving far more DNS responses than queries sent
if ratio > 10 and stats['inbound_responses'] > 100:
logger.critical(
f'DNS AMPLIFICATION LIKELY: response/query ratio={ratio:.0f}:1, '
f'{stats["inbound_responses"]} responses from {sources} unique servers, '
f'only {stats["outbound_queries"]} queries sent'
)
# Indicator 2: Abnormally large DNS responses
if avg_size > 2000 and stats['inbound_responses'] > 50:
logger.warning(
f'Large DNS responses detected: avg {avg_size:.0f} bytes '
f'(normal: 100-500 bytes), possible amplification payload'
)
# Indicator 3: Many unique DNS server sources
if sources > 200:
logger.warning(
f'DNS responses from {sources} unique servers — '
f'consistent with reflection attack pattern'
)
time.sleep(check_interval)
if __name__ == '__main__':
logging.basicConfig(level=logging.INFO)
monitor_amplification()
# Rate-limit inbound DNS responses (source port 53)
# Only useful if your server is NOT a public DNS resolver
# These rules limit the damage from amplification hitting your network
# Create a chain for DNS response filtering
iptables -N DNS_AMPLIFICATION
# Only process inbound UDP packets from source port 53 (DNS responses)
iptables -A INPUT -p udp --sport 53 -j DNS_AMPLIFICATION
# Allow DNS responses at a reasonable rate (legitimate traffic)
# A typical server sends ~10-50 DNS queries/sec
iptables -A DNS_AMPLIFICATION -m hashlimit \
--hashlimit-above 100/sec \
--hashlimit-burst 200 \
--hashlimit-mode srcip \
--hashlimit-name dns_response_limit \
-j DROP
# Drop oversized DNS responses (amplification payloads > 1500 bytes)
# Legitimate DNS responses rarely exceed 512 bytes (without EDNS0)
# or 1232 bytes (with EDNS0 DNS Flag Day recommendation)
iptables -A DNS_AMPLIFICATION -p udp --sport 53 \
-m length --length 1500:65535 -j DROP
# Log and drop DNS responses that exceed rate limits
iptables -A DNS_AMPLIFICATION -m limit --limit 5/min \
-j LOG --log-prefix "DNS-AMP-BLOCKED: " --log-level 4
# Accept everything else (normal DNS responses)
iptables -A DNS_AMPLIFICATION -j ACCEPT
# Anti-spoofing: enable reverse path filtering
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1
# Verify your resolver is not open (test from external network)
# dig @YOUR_SERVER_IP google.com ANY +short
# If it responds with full recursion, your server is an open resolver
PowerWAF automatically blocks DNS Amplification Attack at the edge.
Deploy in minutes. No code changes required. Free plan available.
Free plan spots are limited