DNS Is the Foundation
Every interaction on the internet begins with a DNS query. Before a browser loads a page, before an API call reaches its endpoint, before an email is delivered, a DNS lookup must succeed. When DNS fails, nothing else works. Users do not see a specific error message; they see timeouts, connection failures, and applications that simply refuse to load. The 2016 attack against Dyn proved this at scale: a single DDoS against one DNS provider made Twitter, Netflix, Reddit, Spotify, GitHub, and dozens of other major services unreachable for millions of users. The services themselves were running perfectly. Their DNS was not.
DNS infrastructure occupies a unique position in the attack surface hierarchy. It is always publicly reachable (authoritative servers must answer queries from the entire internet), it runs primarily over UDP (making source IP spoofing trivial), and its responses are often larger than its requests (creating natural amplification). These characteristics make DNS servers both attractive targets and attractive weapons. An attacker can target your DNS to take your services offline, or abuse your DNS servers as amplification reflectors to attack someone else.
Attack Types Targeting DNS
Query Floods
The simplest DNS attack sends a massive volume of legitimate-looking queries to a DNS server. Each query must be parsed, looked up, and answered. Authoritative servers handle this reasonably well for cached zones, but recursive resolvers must perform the full resolution chain for uncached domains, making them significantly more expensive to process per query. A query flood at 500,000 queries per second against a recursive resolver that must perform upstream lookups for each query will exhaust CPU, file descriptors, and upstream bandwidth simultaneously.
The effectiveness of query floods depends on whether the queried names exist. Queries for real records hit the cache and are cheap to answer. Queries for non-existent names require a full lookup that returns NXDOMAIN, which costs more CPU and generates negative cache entries that consume memory.
NXDOMAIN Floods
NXDOMAIN floods exploit the cost asymmetry between cached and uncached lookups. The attacker sends queries for random non-existent subdomains under a target domain (e.g., abc123.example.com, xyz789.example.com). Because each random string is unique, no query hits the cache. The recursive resolver must perform the full resolution chain for every single query, contacting root servers, TLD servers, and the authoritative server for example.com. The authoritative server must search its zone for a record that does not exist, return NXDOMAIN, and the resolver must cache each negative result separately. This floods both the resolver and the authoritative server simultaneously.
DNS Water Torture (Random Subdomain Attacks)
DNS water torture is a refined version of the NXDOMAIN flood specifically designed to overwhelm authoritative servers. The attacker distributes queries across thousands of open recursive resolvers worldwide. Each resolver receives only a small number of queries (staying below any per-source rate limit), but all queries target random subdomains of the victim's domain. The recursive resolvers dutifully forward these queries to the victim's authoritative servers, which see an enormous aggregate query rate from thousands of legitimate resolver IPs. This is exceptionally difficult to mitigate because the traffic arrives from real DNS resolvers, not from spoofed IPs, and blocking resolvers means blocking legitimate DNS resolution for their users.
Water torture attacks are particularly insidious because they bypass most upstream scrubbing services. The queries originate from resolvers worldwide, spread across thousands of source IPs, each sending a modest number of queries. The attack only becomes visible when you aggregate the query rate at the authoritative server and notice that 95% of queries are for non-existent random subdomains.
Reflection and Amplification Using Your Servers
If your DNS servers accept queries from the open internet (as authoritative servers must), attackers can use them as reflectors. The attacker sends queries with the victim's IP as the spoofed source, and your server sends the response to the victim. If the attacker requests large records (DNSSEC-signed ANY queries), the response is 28x to 54x larger than the request, making your server an unwitting amplification weapon. Beyond the ethical and reputational damage of participating in attacks, this consumes your server's resources and bandwidth. A server being used as a reflector experiences the same load as if it were the direct target of a query flood.
Authoritative vs. Recursive: Different Attack Surfaces
Authoritative and recursive servers face fundamentally different threats, and defending them requires different strategies.
Authoritative servers answer queries only for zones they host. They do not perform recursive lookups, which limits the per-query CPU cost. Their primary vulnerability is query volume: they must be publicly reachable and must process every incoming query to determine if it is for a zone they serve. Authoritative servers are the targets of water torture attacks and query floods. They are also the target when an attacker wants to take a specific domain offline.
Recursive resolvers accept queries from their configured clients (typically an ISP's subscribers or a network's internal users) and resolve them by querying the DNS hierarchy. Their per-query cost is much higher because each uncached query requires multiple upstream lookups. Recursive resolvers are vulnerable to cache poisoning, NXDOMAIN floods, and being abused as amplification reflectors if they are open to the internet. A recursive resolver serving an ISP's subscriber base is also a high-value target: taking it down disrupts internet access for all subscribers.
Anycast as a Defense Mechanism
Anycast is the most fundamental architectural defense for DNS infrastructure. With anycast, the same IP address is announced from multiple geographic locations. When a client queries the DNS server, the query is routed to the nearest anycast instance based on BGP path selection. This distributes both legitimate and attack traffic across all instances, meaning an attacker must generate enough traffic to overwhelm every instance simultaneously.
Anycast also provides natural geographic isolation. A botnet concentrated in one region will primarily hit the anycast instance serving that region, leaving other instances unaffected. Even if one instance is overwhelmed, the BGP routing system will withdraw that instance's announcement and redirect traffic to the next nearest instance. This self-healing behavior makes anycast DNS infrastructure remarkably resilient to localized attacks.
However, anycast is not a complete solution. A globally distributed botnet can overwhelm all instances simultaneously. And anycast does not help with application-layer attacks like water torture, where the query volume per instance may be modest but the aggregate cost of processing random subdomain queries is high.
DNS Rate Limiting Configuration
Response Rate Limiting (RRL)
Response Rate Limiting was developed specifically to prevent DNS servers from being used as amplification reflectors. RRL tracks the rate of identical or similar responses being sent to the same destination and throttles responses that exceed a threshold. This prevents an attacker from using your server to amplify traffic toward a victim, because repeated queries for the same large record from the same (spoofed) source IP will be rate-limited after the first few responses.
# BIND 9 RRL configuration
# /etc/named.conf options block
options {
rate-limit {
responses-per-second 5; # Max identical responses to one IP per second
nxdomains-per-second 5; # Max NXDOMAIN responses to one IP per second
errors-per-second 5; # Max error responses to one IP per second
window 15; # Tracking window in seconds
slip 2; # Send truncated response every Nth dropped query
ipv4-prefix-length 24; # Track by /24 source subnet
ipv6-prefix-length 56;
log-only no; # Set to yes for testing before enforcement
};
};
# PowerDNS Authoritative RRL configuration # /etc/pdns/pdns.conf enable-lua-records=yes lua-config-file=/etc/pdns/lua-config.lua # In /etc/pdns/pdns.conf max-qps-per-ip=50 max-ent-per-ip=20
The slip parameter is important. When RRL drops a response, it can optionally send a truncated (TC=1) response instead. This tells legitimate clients to retry over TCP, which proves they are not spoofing their source IP (TCP requires a handshake). Setting slip 2 sends a truncated response every second dropped query, balancing between preventing amplification and allowing legitimate clients to fall back to TCP.
Query Rate Limiting
Query rate limiting operates on the inbound side: it limits the number of queries accepted from a given source before they are processed. This protects the server's CPU and prevents query floods from consuming processing capacity. Unlike RRL, which limits outbound responses, query rate limiting drops inbound queries before expending resources on them.
# iptables: limit DNS queries per source IP # Allow 100 queries/sec per source, burst 150 iptables -A INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name dns_query \ --hashlimit-above 100/sec \ --hashlimit-burst 150 \ --hashlimit-mode srcip \ --hashlimit-htable-expire 10000 \ -j DROP # Separate limit for TCP DNS (lower, as TCP is more expensive) iptables -A INPUT -p tcp --dport 53 -m hashlimit \ --hashlimit-name dns_tcp \ --hashlimit-above 30/sec \ --hashlimit-burst 50 \ --hashlimit-mode srcip \ --hashlimit-htable-expire 10000 \ -j DROP
Monitoring DNS Query Rates for Anomalies
Effective DNS DDoS detection requires monitoring multiple metrics simultaneously. Query rate alone is insufficient because legitimate traffic can spike during events (a popular website launch, a breaking news story). The following metrics together provide reliable anomaly detection:
- Total query rate (QPS): The baseline. Most DNS servers have a predictable daily pattern with peak hours and quiet hours. A deviation of 3x or more from the rolling baseline warrants investigation.
- NXDOMAIN ratio: The percentage of queries that return NXDOMAIN. A healthy authoritative server typically sees less than 5% NXDOMAIN. During a water torture attack, this ratio spikes above 80%.
- Query name entropy: Random subdomain attacks produce query names with high entropy (random alphanumeric strings). Legitimate queries have lower entropy because they follow human-readable naming patterns. Monitoring the average entropy of queried names provides an early water torture signal.
- Source IP diversity: A sudden increase in the number of unique source IPs querying your authoritative server, especially if those IPs are all recursive resolvers, indicates a distributed attack.
- Response size distribution: If your outbound DNS response bandwidth suddenly spikes while your inbound query bandwidth remains stable, your server is being used for amplification.
Flowtriq monitors UDP port 53 traffic patterns on every node where its agent is deployed. Because DNS traffic is UDP, it is captured by the same kernel-level counters that Flowtriq uses for general UDP flood detection. A DNS server node that normally sees 10,000 UDP packets per second on port 53 and suddenly receives 500,000 packets per second triggers an immediate detection. The per-node architecture means each DNS server instance is monitored independently, providing visibility even when anycast distributes the attack across multiple locations.
DNS Attacks as Reconnaissance
DNS attacks frequently precede larger, more targeted campaigns. An attacker probing your DNS infrastructure learns several things: how much traffic your DNS can absorb before degrading, how quickly your team responds, whether you have anycast or single-site DNS, and which upstream providers serve your DNS traffic. This reconnaissance shapes the main attack. If the attacker discovers that your DNS is the weakest link, the main attack targets DNS directly. If DNS proves resilient, the attacker shifts to targeting the application layer or a different service.
Monitoring for DNS reconnaissance includes watching for abnormal patterns in query types. A sudden influx of ANY queries, AXFR (zone transfer) attempts from unauthorized sources, or systematic enumeration of subdomains suggests an attacker mapping your infrastructure. These patterns often appear days or weeks before the actual DDoS attack, providing a valuable early warning window.
The Dyn attack in October 2016 demonstrated that DNS is often the single point of failure people forget about. Organizations that depended on a single DNS provider lost all their internet-facing services, regardless of how resilient those services were.
Building a Resilient DNS Architecture
True DNS resilience requires multiple layers. At the architecture level, deploy authoritative DNS across at least three anycast sites in different geographic regions. Use at least two independent DNS providers (if your primary DNS fails, the secondary must be able to serve all your zones without delay). At the server level, configure RRL on every authoritative server, implement query rate limiting at the firewall, and run recursive resolvers as separate infrastructure from authoritative servers. At the monitoring level, track QPS, NXDOMAIN ratios, and UDP traffic rates per server with per-second granularity.
For organizations running their own DNS infrastructure, deploying Flowtriq agents on DNS server nodes provides the traffic-level monitoring layer. At $9.99 per node per month, monitoring a fleet of DNS servers is cost-effective even for small operators. The agent's per-second UDP counter tracking detects query floods and amplification abuse within seconds, complementing application-level metrics from BIND statistics or PowerDNS's built-in monitoring. When combined with Flowtriq's automated BGP mitigation, detected DNS floods can trigger FlowSpec rules that filter attack traffic at the network edge before it reaches the DNS server.
Monitor your DNS infrastructure with per-second precision
Flowtriq detects DNS query floods, amplification abuse, and water torture attacks by monitoring UDP/53 traffic patterns on every node. $9.99/node/month with a free 7-day trial.
Start your free trial →