DNS Open Recursion Vulnerability
Critical security misconfiguration enabling DDoS amplification attacks
Critical Security Alert
Your DNS server accepts recursive queries from any internet client, creating a serious security vulnerability. This configuration enables DDoS amplification attacks and allows unauthorized consumption of your server resources.
Understanding Open Recursion Attacks
Open DNS recursion represents one of the most dangerous misconfigurations in DNS infrastructure. When your DNS server processes recursive queries from any internet source, it becomes a powerful weapon in the hands of attackers seeking to amplify their DDoS attacks. The attack methodology is brutally effective because it exploits the fundamental trust relationships in DNS resolution.
Attackers send small DNS queries to your open recursive server using spoofed source IP addresses that point to their victims. Your server, believing it's helping a legitimate client, performs the full recursive resolution and sends large responses directly to the victim. This transforms your infrastructure into an unwitting participant in massive DDoS attacks, often generating 50-100 times more traffic than the original queries.
How Open Recursion Exploitation Works:
Query amplification occurs when attackers send queries that trigger large DNS lookups, such as requesting all records for a domain (ANY queries) or targeting domains with extensive DNSSEC signatures.
Resource exhaustion happens when your DNS server becomes overwhelmed processing queries from across the internet, degrading service for legitimate users and potentially causing complete service outages.
Cache poisoning opportunities multiply when external attackers can inject queries into your cache, potentially corrupting your DNS resolution with malicious records that affect all your users.
Immediate Defense Actions
Understanding the attack mechanism is only the first step - immediate action is required to protect your infrastructure. Start by immediately auditing your DNS server configuration to determine whether recursive queries are enabled and accessible from the internet. Test your servers from external networks to confirm they're not responding to recursive queries from unauthorized sources. This initial assessment will help you understand your current exposure and prioritize remediation efforts.
Configure your DNS servers to restrict recursive queries to only authorized clients within your network. For authoritative-only DNS servers that should never perform recursion, disable the feature entirely. For servers that must provide recursive services, implement strict access controls that limit queries to your internal network ranges and trusted sources.
Critical Actions:
- 🔍 Audit all DNS servers for open recursion vulnerability
- ⚡ Disable recursion on authoritative-only DNS servers
- 🛡️ Restrict recursive queries to internal networks only
- 🚦 Implement rate limiting for DNS queries
- 📊 Monitor DNS query patterns for abuse indicators
DNS Server Implementation Guide
With the threat understood and priorities established, it's time to implement the technical solutions. The specific configuration steps depend on your DNS server software, but the principles remain consistent: restrict recursion to authorized clients and disable it entirely for authoritative-only servers.
BIND Configuration
For authoritative-only servers, completely disable recursion in /etc/bind/named.conf. This configuration implements defense-in-depth by blocking recursion at multiple levels to prevent any possibility of exploitation.
The authoritative-only configuration disables recursion entirely and blocks cache access, transforming the server into a pure authoritative responder that only answers queries for domains it hosts. By setting minimal-responses and disabling additional record inclusion, the server reduces response sizes and eliminates potential amplification vectors. This configuration is ideal for public-facing authoritative servers that should never perform recursive lookups for external clients.
// BIND authoritative-only server configuration (maximum security)
options {
recursion no; // Disable recursive queries completely
allow-recursion { none; }; // Explicitly deny recursion to all clients
allow-query-cache { none; }; // Block cache access (no cache needed for auth-only)
additional-from-auth no; // Don't include additional records from authoritative data
additional-from-cache no; // Don't include additional records from cache
// Additional security hardening for authoritative servers
auth-nxdomain no; // Don't set AA bit on NXDOMAIN (RFC compliance)
minimal-responses yes; // Only return requested data (reduces response size)
dnssec-validation no; // Disable validation (not needed for auth-only)
};For recursive resolvers serving internal networks only, this configuration implements sophisticated access controls combined with rate limiting to prevent both unauthorized access and amplification attacks:
The Access Control List (ACL) defines trusted network ranges using RFC 1918 private address spaces, ensuring only internal clients can request recursive resolution. The rate limiting configuration provides multi-layered protection by capping responses per second, implementing slip responses that force legitimate clients to retry over TCP (which prevents spoofing), and grouping clients by subnet to prevent individual IP abuse. This approach maintains excellent service quality for authorized users while creating insurmountable barriers for attackers attempting to exploit the server.
# Access Control List - define trusted networks for recursive queries
acl "internal-networks" {
192.168.0.0/16; // RFC 1918 Private Class C networks (192.168.x.x)
10.0.0.0/8; // RFC 1918 Private Class A networks (10.x.x.x)
172.16.0.0/12; // RFC 1918 Private Class B networks (172.16-31.x.x)
localhost; // Local server access (127.0.0.1/::1)
localnets; // Automatically detected local subnets
};
options {
recursion yes; // Enable recursive queries (required for resolver operation)
allow-recursion { internal-networks; }; // Restrict recursive queries to trusted networks only
allow-query { internal-networks; }; // Restrict all queries to trusted networks
allow-query-cache { internal-networks; }; // Restrict cache access to trusted networks
rate-limit { // Prevent DNS amplification attacks
responses-per-second 20; // Max responses per client per second
window 5; // Time window for rate calculations (seconds)
slip 2; // Send every 2nd response truncated (forces TCP)
qps-scale 250; // Scale factor for burst allowance
ipv4-prefix-length 24; // Group IPv4 clients by /24 subnet
ipv6-prefix-length 56; // Group IPv6 clients by /56 subnet
};
auth-nxdomain no; // Don't set authoritative bit on NXDOMAIN responses
dnssec-validation auto; // Enable DNSSEC validation for security
};Security Best Practice: The combination of ACL restrictions and rate limiting provides layered protection against both unauthorized access and amplification attacks.
Security Note: This configuration allows recursion but restricts it to trusted internal networks only, preventing public DNS amplification attacks.
Unbound Configuration
Configure access controls in /etc/unbound/unbound.conf with Unbound's powerful network-based restrictions and performance-oriented rate limiting.
Unbound's access control system operates at the network interface level, binding only to internal interfaces and implementing explicit allow/refuse rules for different network ranges. The dual-layer rate limiting approach distinguishes between per-client and per-IP restrictions, providing fine-grained control over query volumes while the slip mechanism forces suspicious clients to use TCP connections that are harder to spoof. Security hardening features like identity hiding and DNSSEC validation work together to create a robust recursive resolver that serves internal networks reliably while remaining completely inaccessible to external attackers.
# Unbound recursive resolver configuration with access controls
server:
# Interface binding - listen on internal interface only
interface: 192.168.1.1 # Internal network interface (not 0.0.0.0)
do-not-query-localhost: yes # Don't query localhost (prevents loops)
# Access control - RFC 1918 private networks only
access-control: 192.168.0.0/16 allow # Class C private networks (allow recursion)
access-control: 10.0.0.0/8 allow # Class A private networks (allow recursion)
access-control: 172.16.0.0/12 allow # Class B private networks (allow recursion)
access-control: 0.0.0.0/0 refuse # Block all other IPv4 (internet clients)
access-control: ::0/0 refuse # Block all IPv6 (internet clients)
# Rate limiting - prevent amplification attacks
ratelimit: 1000 # Max queries per second per client
ip-ratelimit: 100 # Max queries per second per IP
ratelimit-slips: 2 # Send truncated responses (forces TCP)
ratelimit-size: 4m # Memory for rate limiting state (4MB)
# Security enhancements
hide-identity: yes # Don't reveal server identity
hide-version: yes # Don't reveal server version
harden-glue: yes # Validate glue records
harden-dnssec-stripped: yes # Reject responses without DNSSEC when expectedPowerDNS Configuration
For PowerDNS Authoritative server, disable recursion in /etc/powerdns/pdns.conf using PowerDNS's straightforward configuration approach that clearly separates authoritative and recursive functions.
PowerDNS uses distinct products for authoritative (pdns) and recursive (recursor) services, making it easier to maintain proper separation of concerns. The authoritative configuration explicitly disables any recursive behavior while restricting query sources to trusted networks. The recursor configuration focuses on performance-oriented rate limiting with max-qperq controlling queries per question and max-total-msec preventing resource exhaustion from complex queries. This architectural separation provides natural protection against configuration errors that might accidentally enable recursion where it shouldn't exist.
# Disable recursion completely for authoritative servers
recursion-desired=no
recursor=no
# Limit query sources
allow-from=127.0.0.0/8,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12For PowerDNS Recursor, restrict in /etc/powerdns/recursor.conf:
# Allow recursion only from internal networks
allow-from=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,127.0.0.0/8
# Network interface binding
local-address=192.168.1.1
# Rate limiting
max-qperq=60
max-total-msec=7000Cloudflare Configuration
For domains managed through Cloudflare, leverage Cloudflare's edge protection to prevent recursive query abuse through intelligent filtering and threat detection.
Cloudflare's proxy functionality creates a protective barrier between your origin servers and potential attackers by filtering malicious traffic at the edge. The firewall rules use threat intelligence scoring to identify suspicious DNS tooling and geographic patterns that indicate potential amplification attacks. This configuration combines Cloudflare's global threat intelligence with custom rules to block automated DNS reconnaissance tools while allowing legitimate traffic from trusted network ranges.
- • Navigate to DNS settings in Cloudflare dashboard
- • Enable "Proxy status" (orange cloud) for public-facing records
- • Use Access Control to restrict administrative subdomains
- • Configure Firewall Rules to block unauthorized recursive queries
Create a Firewall Rule to block suspicious DNS queries:
# Rule expression for blocking recursive query attempts
(http.request.uri.path contains "?type=" and
cf.threat_score gt 30) or
(http.user_agent contains "dig" and
not ip.src in {192.168.0.0/16 10.0.0.0/8})Verification Steps
After implementing these configurations, comprehensive testing from multiple network perspectives is essential to validate that access controls work correctly. Use tools like dig from various external IP addresses to verify proper access controls are in place.
The verification process should include testing from both external internet sources (which should be rejected) and internal network ranges (which should succeed for recursive servers). External tests should return either connection refused errors or REFUSED response codes, while internal tests should complete successfully. This dual validation ensures your configuration properly distinguishes between authorized and unauthorized query sources, confirming that your DNS infrastructure is protected against open recursion exploitation.
# Test from external network - should fail
dig @your-dns-server.com google.com
# Test from internal network - should succeed (if configured as recursive)
dig @192.168.1.1 google.comBuilding Long-term DNS Security
Establish comprehensive DNS security policies that prevent future misconfigurations and ensure ongoing protection against recursive query abuse. This includes regular auditing of DNS server configurations, implementing monitoring systems that detect unauthorized query patterns, and maintaining clear documentation of which servers should provide recursive services to which networks.
Consider implementing additional protective measures such as DNS query rate limiting, response rate limiting, and geographic restrictions that prevent your servers from being used in international DDoS attacks. Regular security assessments and penetration testing can help identify configuration drift and ensure your DNS infrastructure remains secure against evolving threats.
Last updated: July 25, 2025