DNS Amplification Risk
Server vulnerable to DDoS amplification attacks
Critical Security Risk
Your DNS server can be exploited for amplification attacks, where attackers use your server to amplify attack traffic by 30-100x, potentially overwhelming targets and consuming your bandwidth.
Understanding DNS Amplification Attacks
DNS amplification attacks exploit the difference between the size of DNS queries and responses. Attackers send small DNS queries (around 60 bytes) with spoofed source IP addresses to DNS servers, which then respond with much larger answers (potentially several kilobytes) to the spoofed targets.
The attack is particularly effective because DNS responses can be 30-100 times larger than the original query, especially when requesting large DNS records like TXT records containing DKIM keys or SPF policies. This creates a massive amplification effect that can overwhelm the target's network infrastructure.
Impact on Your Infrastructure
Beyond enabling attacks against others, the amplification abuse directly affects your own infrastructure. When your DNS server is used in amplification attacks, you may experience degraded performance, increased bandwidth costs, and potential blacklisting by network operators who detect the abnormal traffic patterns. This makes immediate mitigation essential for both ethical and operational reasons.
These impacts make implementing comprehensive protection measures essential for both security and operational stability. The following solutions provide defense against amplification abuse while maintaining DNS functionality.
Response Rate Limiting
The most effective defense against amplification abuse is implementing response rate limiting. This automatically throttles suspicious query patterns while maintaining normal DNS functionality.
BIND Response Rate Limiting
Configure BIND with response rate limiting (RRL) to automatically throttle suspicious queries:
# BIND Response Rate Limiting (RRL) - basic amplification protection
options {
rate-limit {
responses-per-second 10; # Maximum responses per client per second (conservative)
window 5; # Time window for rate calculations (5 seconds)
log-only no; # Actually enforce limits (not just log violations)
qps-scale 250; # Burst allowance scale factor (higher = more bursts)
ipv4-prefix-length 24; # Group IPv4 clients by /24 subnet (ISP level)
ipv6-prefix-length 56; # Group IPv6 clients by /56 subnet (typical delegation)
slip 2; # Send every 2nd response truncated (forces TCP retry)
};
};This limits responses to 10 per second per client, with burst allowance scaled by overall query rate.
Custom Rate Limiting Rules
Enhanced RRL configuration for high-traffic environments:
// Enhanced BIND Response Rate Limiting (RRL) for amplification protection
rate-limit {
responses-per-second 5; // Max normal responses per client per second (conservative setting)
nxdomains-per-second 5; // Limit NXDOMAIN responses (prevents subdomain enumeration attacks)
errors-per-second 5; // Limit error responses like SERVFAIL, REFUSED (prevents error abuse)
referrals-per-second 5; // Limit referral responses (prevents delegation chain abuse)
window 15; // Time window for rate calculations (15 seconds for accuracy)
slip 2; // Send every 2nd response truncated (TC=1, forces TCP retries)
ipv4-prefix-length 24; // Group IPv4 clients by /24 subnet (ISP/org level)
ipv6-prefix-length 56; // Group IPv6 clients by /56 subnet (typical delegation)
qps-scale 250; // Scale factor for burst allowance (250 = moderate bursts)
all-per-second 10; // Emergency limit: total responses per client (safety net)
log-only no; // Actually enforce limits (set to 'yes' for testing)
exempt-clients { localhost; 192.168.0.0/16; }; // Exempt trusted networks from RRL
};Performance Note: The slip feature forces attackers to use TCP, significantly reducing amplification effectiveness while maintaining service for legitimate clients.
Access Control and Filtering
Beyond rate limiting, implementing access controls provides additional layers of protection against amplification abuse by restricting who can make recursive queries.
Source IP Filtering
Restrict recursive queries to authorized networks only:
// Access Control Lists - define trusted networks for DNS services
acl "trusted" {
localhost; // Local server (127.0.0.1/8, ::1/128) - always trusted
192.168.0.0/16; // RFC 1918 Class C private networks (home/office LANs)
10.0.0.0/8; // RFC 1918 Class A private networks (large enterprises)
172.16.0.0/12; // RFC 1918 Class B private networks (medium organizations)
// Add specific public IPs for legitimate remote access
// 203.0.113.100/32; // Example: specific trusted public IP
};
acl "internal_servers" {
192.168.1.10; // Internal DNS server #1
192.168.1.11; // Internal DNS server #2
10.0.0.53; // Primary internal resolver
// List all internal DNS infrastructure here
};
acl "blackhole" {
// Known amplification source networks (update from threat intelligence)
203.0.113.0/24; // Example bad network (TEST-NET-3 - RFC documentation)
192.0.2.0/24; // Example bad network (TEST-NET-1 - RFC documentation)
198.51.100.0/24; // Example bad network (TEST-NET-2 - RFC documentation)
// Add real threat intelligence sources:
// include "/etc/bind/blacklist.acl"; // External blacklist file
};
options {
// Recursion controls - critical for preventing open resolver abuse
allow-recursion { trusted; internal_servers; }; // Only authorized networks can recurse
allow-query-cache { trusted; internal_servers; }; // Only authorized networks access cache
allow-query { any; }; // Authoritative queries from any source
recursion yes; // Enable recursion (but only for trusted)
// Source address controls
allow-transfer { internal_servers; }; // Zone transfers only to internal servers
allow-notify { internal_servers; }; // Accept notifications from internal only
// Block known bad sources immediately
blackhole { blackhole; }; // Drop all packets from blacklisted networks
// Performance and DoS protection limits
max-cache-size 256m; // Cache size limit (adjust based on RAM)
clients-per-query 10; // Max clients per identical query
max-clients-per-query 100; // Absolute max clients for same query
recursive-clients 1000; // Max concurrent recursive queries
tcp-clients 100; // Max concurrent TCP connections
// Query complexity limits
max-recursion-depth 7; // Prevent infinite recursion loops
max-recursion-queries 75; // Max queries per recursion chain
fetches-per-zone 10; // Max concurrent zone fetches
// Additional anti-amplification measures
minimal-responses yes; // Reduce response sizes where possible
version "DNS Server"; // Don't reveal BIND version
hostname ""; // Don't reveal server hostname
};Query Type Filtering
Block or limit queries for record types commonly used in amplification:
// Query type filtering - block amplification-prone record types
view "restricted" {
match-clients { any; }; # Apply to all clients (global filter)
allow-query { any; }; # Allow queries but with restrictions
// Block or limit high-amplification record types
zone "." {
type static-stub; # Create static responses for filtering
server-addresses { }; # Empty server list blocks resolution
zone-policy policy-name { # Apply custom policy
policy-action drop; # Drop certain query types
query-type TXT; # Block TXT record queries (DKIM keys)
query-type ANY; # Block ANY queries (highest amplification)
query-type RRSIG; # Block DNSSEC signature queries
};
};
// Rate limit specific record types instead of blocking
rate-limit {
responses-per-second 2; # Stricter limit for high-risk types
window 10; # Longer window for persistent attacks
slip 3; # More aggressive truncation (every 3rd)
exempt-clients { localhost; 192.168.0.0/16; }; # Exempt trusted internal networks
};
};
// Alternative: Use RPZ (Response Policy Zone) for advanced filtering
zone "rpz.local" {
type master; # Master zone for RPZ rules
file "/etc/bind/db.rpz"; # RPZ rule file location
allow-query { localhost; }; # Restrict RPZ zone queries
allow-transfer { none; }; # Prevent zone transfers of RPZ data
};
qps-scale 100;
// Apply stricter limits to ANY queries
all-per-second 1;
};Firewall Integration
Use iptables or similar to add network-level protection:
# iptables rate limiting for DNS amplification protection
iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-upto 30/min \ # Allow 30 queries per minute per IP
--hashlimit-burst 10 \ # Allow burst of 10 queries initially
--hashlimit-mode srcip \ # Rate limit per source IP address
--hashlimit-name dns \ # Named rule for tracking state
--hashlimit-htable-expire 300000 \ # Hash table cleanup (5 minutes)
-j ACCEPT
# Block excessive queries (amplification attempts)
iptables -A INPUT -p udp --dport 53 -j DROP
# TCP DNS protection (separate chain for stateful connection tracking)
iptables -A INPUT -p tcp --dport 53 -m state --state NEW \
-m hashlimit --hashlimit-upto 10/min \ # Lower TCP rate (resource intensive)
--hashlimit-burst 5 --hashlimit-mode srcip \
--hashlimit-name dns-tcp -j ACCEPTMonitoring and Detection
Implement monitoring to detect and respond to attacks
Traffic Pattern Analysis
Monitor for signs of amplification abuse:
- • Sudden spikes in outbound DNS traffic
- • High volume of queries from single source IPs
- • Unusual patterns in query types (many ANY/TXT queries)
- • Responses significantly larger than queries
Automated Response
Set up automated blocking for suspicious patterns:
# Example fail2ban filter for DNS abuse
# Monitor for excessive queries from single IP
[Definition]
failregex = client .* query.*from <HOST>
ignoreregex =
maxretry = 100
findtime = 60
bantime = 3600Logging and Analysis
- • Enable detailed query logging for analysis
- • Monitor bandwidth usage and response patterns
- • Set up alerts for unusual traffic volumes
- • Regular review of blocked IP addresses and patterns
Last updated: January 8, 2026
