A denial-of-service attack that overwhelms DNS infrastructure with excessive queries.

DNS Flood - What It Means & How It Works

What is a DNS Flood Attack?

A DNS flood is a type of Distributed Denial of Service (DDoS) attack that overwhelms DNS infrastructure by sending massive volumes of DNS queries to DNS servers (authoritative nameservers or recursive resolvers). The goal is to exhaust server resources, making the DNS service unavailable and preventing legitimate users from resolving domain names.

Impact of DNS Flood Attacks

When DNS servers are overwhelmed:

Normal operation: User → DNS query → DNS server → Response → Website loads During DNS flood: User → DNS query → DNS server (overwhelmed, no response)

→ Website doesn't load (even though web server is fine)

Effects:

Websites become unreachable (even if web servers are operational)
Email delivery fails (MX record lookups fail)
APIs and services relying on DNS become unavailable
Collateral damage to shared DNS infrastructure

Types of DNS Flood Attacks

Direct DNS Query Flood

Attacker sends legitimate DNS queries at high volume:

Botnet → Millions of DNS queries → Target DNS server Query examples: example.com A www.example.com A random1.example.com A random2.example.com A

...millions more...

Characteristics:

Valid DNS queries (hard to filter)
Often for random subdomains (bypass caching)
Uses botnets for distributed attack

DNS Amplification Attack

Exploits recursive resolvers to amplify attack traffic:

1. Attacker sends small query to open resolver 2. Spoofs source IP as victim's IP 3. Resolver sends large response to victim

4. Attacker amplifies bandwidth 28-54x

Example:

Attacker sends: 60-byte query for TXT record (ANY query) Resolver sends: 3000-byte response to victim

Amplification: 50x

NXDOMAIN Flood

Queries for non-existent domains to bypass caching:

Query: random-12345.example.com (doesn't exist) Server must check authoritative zone every time Cannot be cached (NXDOMAIN responses often have low TTL)

Consumes more server resources than cached responses

Phantom Domain Attack

Queries legitimate domains that don't respond:

Attacker: Queries resolver for slow/non-responsive domains Resolver: Waits for timeout, consumes resources

Result: Resolver resource exhaustion

Random Subdomain Attack

Queries random subdomains to avoid cache hits:

Query: abc123random.example.com Query: xyz789random.example.com Query: def456random.example.com Each is unique → cache miss → authoritative query

Overwhelms authoritative nameservers

Attack Vectors and Techniques

Botnet-Driven Attacks

Compromised devices: IoT devices (cameras, routers) Infected computers Hacked servers Distributed attack:

10,000 bots × 100 queries/sec = 1 million queries/sec

Reflection Attacks

Attacker spoofs victim's IP Sends queries to many open resolvers Resolvers respond to victim with large answers

Victim receives amplified traffic

Application-Layer Floods

Legitimate-looking queries Difficult to distinguish from real traffic

May target specific resource-intensive query types

Detecting DNS Flood Attacks

Unusual Query Volume

Normal baseline: 10,000 queries/second

During attack: 500,000+ queries/second

Monitor:

# Check query rate (BIND)
rndc status | grep "queries resulted"

# Analyze query logs
tail -f /var/log/named/queries.log | wc -l

High NXDOMAIN Rate

Normal: 5-10% NXDOMAIN responses

Attack: 50-90% NXDOMAIN responses (random subdomain flood)

Source IP Distribution

Legitimate: Diverse source IPs, geographic spread

Attack: Concentrated sources, unusual geographic patterns

Query Patterns

Legitimate: Repetitive queries (common domains cached)
Attack: Unique queries (random strings, no cache benefit)

Response Time Degradation

Normal: < 50ms response time
Under attack: > 1000ms or timeouts

Mitigating DNS Flood Attacks

Infrastructure-Level Defenses

#### Anycast DNS

Distribute traffic across multiple geographic locations:

Single IP address (e.g., 1.2.3.4) announced from multiple locations Attack traffic automatically routed to nearest server Load distributed across global network

Harder to overwhelm all locations simultaneously

Benefits:

Automatic load distribution
Geographic resilience
Attack traffic absorption

Providers: Cloudflare, AWS Route 53, NS1, Dyn

#### Oversized DNS Infrastructure

Capacity: 10x normal peak traffic Reserves: Handle sudden spikes

Auto-scaling: Add capacity during attacks

#### Rate Limiting

# BIND rate limiting (response-rate limiting)
rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

Limits responses from same source to prevent amplification attacks.

#### Query Filtering

# Block ANY queries (common in amplification) # Block excessively long queries

# Block known-malicious patterns

BIND Example:

# Block ANY queries
match-query {
    type ANY;
    action drop;
};

DNS Provider-Level Defenses

#### DNSSEC

While not directly preventing floods, DNSSEC:

Prevents cache poisoning during attacks
Maintains integrity under attack conditions

#### Hidden Master Configuration

Master server (hidden):    10.0.0.1 (not publicly known)
Slave servers (public):    ns1.example.com, ns2.example.com

Attackers target slaves
Master remains operational
Can quickly update slaves if needed

#### DNS Firewall / IDS

Analyze queries in real-time Block suspicious patterns Whitelist known-good clients

Blacklist attack sources

Application-Level Protections

#### Response Rate Limiting (RRL)

Limit identical responses to same client Prevents amplification attacks

Slip mode: Occasionally allow queries through (to not break legitimate recursive resolvers)

BIND Configuration:

options {
    rate-limit {
        responses-per-second 5;
        referrals-per-second 5;
        nodata-per-second 5;
        nxdomains-per-second 5;
        errors-per-second 5;
        window 5;
    };
};

#### Cache Optimization

Increase cache size to absorb repeated queries Longer TTLs where appropriate (trade-off with agility)

Prefetch popular records

#### Query Filtering

# Drop queries for non-existent zones # Block queries from known-bad sources

# Rate-limit per-source queries

Network-Level Defenses

#### BGP Blackholing

Route attack traffic to null0 Sacrifice availability to preserve infrastructure

Last resort when attack overwhelms capacity

#### Upstream ISP Filtering

Coordinate with ISP to filter attack traffic Source IP validation (prevent spoofing)

Traffic scrubbing centers

#### DDoS Mitigation Services

Cloudflare, Akamai, AWS Shield Absorb attack traffic before reaching your servers

Global capacity to withstand large attacks

Best Practices for DNS Resilience

Use Multiple DNS Providers

Primary provider: Cloudflare Secondary provider: AWS Route 53 If one is attacked/down, other continues serving

Different infrastructure reduces single point of failure

Implement DNSSEC

Protects against DNS spoofing/cache poisoning Maintains integrity during attacks

Build trust even under attack conditions

Monitor DNS Performance

Real-time query rates Response times NXDOMAIN percentages Geographic distribution of queries

Error rates

Tools: Grafana + Prometheus, Datadog, AWS CloudWatch

Regular Capacity Testing

Load testing: Can infrastructure handle 10x traffic? Failover testing: Do secondary providers activate correctly?

Attack simulation: Test mitigation strategies

Disable Recursion on Authoritative Servers

# BIND
recursion no;

Authoritative nameservers should not act as recursive resolvers.

Restrict Zone Transfers

# BIND
allow-transfer { 10.0.0.2; 10.0.0.3; };  # Only specific slaves

Prevent attackers from dumping entire zone.

Keep Software Updated

Regularly update DNS server software Patch known vulnerabilities

Subscribe to security advisories

Responding to Active DNS Flood Attack

Immediate Actions

1. Verify attack is occurring

# Check query rate rndc status # Check load

top

2. Enable rate limiting

# BIND: Enable RRL if not already active

rndc addzone rate-limit

3. Contact DDoS mitigation provider

- Activate scrubbing services

- Redirect traffic through mitigation network

4. Analyze attack patterns

# Top query types
   grep "query" /var/log/named/queries.log | awk '{print $6}' | sort | uniq -c | sort -rn | head -20

   # Top queried domains
   grep "query" /var/log/named/queries.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

5. Block obvious attack sources

# Identify top source IPs
   grep "query" /var/log/named/queries.log | awk '{print $5}' | cut -d# -f1 | sort | uniq -c | sort -rn | head -50

   # Block at firewall
   iptables -A INPUT -s ATTACKER_IP -j DROP

Medium-Term Actions

1. Scale infrastructure

- Add more nameserver capacity

- Distribute via anycast if not already

2. Implement additional filtering

- Block query patterns specific to attack

- Whitelist known-good sources

3. Coordinate with providers

- ISP/hosting provider

- DNS provider

- DDoS mitigation service

4. Document attack

- Packet captures

- Logs

- Traffic graphs

- For post-incident analysis and legal purposes

Post-Attack Analysis

1. Review effectiveness of mitigations

2. Identify infrastructure weaknesses

3. Update incident response procedures

4. Consider long-term improvements (multi-provider DNS, larger capacity)

Legal and Reporting

Report to Authorities

FBI IC3 (U.S.): ic3.gov
Local cybercrime units
ISP abuse departments

Evidence Collection

# Packet captures tcpdump -i eth0 -w dns-attack.pcap port 53 # Full query logs tar -czf attack-logs-$(date +%Y%m%d).tar.gz /var/log/named/ # Traffic graphs/screenshots

# System resource usage

DNS flood attacks are a serious threat to online services, but with proper infrastructure, monitoring, and mitigation strategies, their impact can be minimized.

DNS Flood