Defend Against DNS Amplification DDoS Attacks (2026)

DNS amplification attacks exploit the open nature of DNS to flood a target with traffic, overwhelming its network resources.

Here’s how to defend against them:

dig @8.8.8.8 example.com

This command shows a normal DNS query response. An amplification attack response would be drastically larger.

The core idea of a DNS amplification attack is simple: an attacker sends a small DNS query to an open DNS resolver, spoofing the source IP address to be the victim’s IP. The resolver then sends a much larger DNS response to the victim, overwhelming them.

Common Vulnerabilities and Defenses:

Open DNS Resolvers: The most common vector. Any DNS server that accepts queries from the public internet and responds to spoofed IP addresses is a potential amplifier.
- Diagnosis: Scan your network’s public IP space for open DNS resolvers using tools like nmap with a DNS script:
```
nmap -sU -p 53 --script dns-recursion <your_network_range>
```
  Look for responses that indicate recursion is enabled.
- Fix: Configure your DNS servers to only respond to queries from trusted internal IP addresses or networks. For BIND, this looks like:
```
acl "trusted_clients" { 192.168.1.0/24; 10.0.0.0/8; localhost; localnets; };
options {
    recursion yes;
    allow-query { trusted_clients; };
    // ... other options
};
```
  This restricts who can ask your DNS server for recursive lookups.
- Why it works: By preventing external, untrusted clients from initiating recursive queries, you eliminate the attacker’s ability to use your server as an amplifier.
DNSSEC Validation: While not a direct defense against amplification, DNSSEC helps ensure the integrity of DNS responses. Attackers might try to inject forged responses, but DNSSEC makes this harder.
- Diagnosis: Check your DNS server configuration for dnssec-validation auto; (for BIND) or equivalent settings.
- Fix: Enable DNSSEC validation on your authoritative DNS servers and recursive resolvers. For BIND:
```
options {
    dnssec-validation auto;
    // ...
};
```
- Why it works: DNSSEC cryptographically signs DNS records. Validation ensures that responses are genuine and haven’t been tampered with, reducing the effectiveness of some spoofing techniques.
Rate Limiting DNS Responses: Limiting the number of DNS responses a server can send to a single IP address in a given time frame.
- Diagnosis: This is harder to diagnose directly on the server without specific logging. You’d look for patterns of high outbound UDP traffic on port 53 from your DNS servers to specific external IPs.
- Fix: Implement rate limiting on your firewall or load balancer. For example, on a Linux server using iptables:
```
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --set
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP
```
  This limits new UDP DNS requests from a single IP to 10 per minute.
- Why it works: This prevents a single client (even a spoofed one) from triggering an overwhelming flood of responses from your DNS server.
Source IP Address Verification (BCP 38): Internet Service Providers (ISPs) should implement BCP 38 (also known as ingress filtering) to drop packets with source IP addresses that do not originate from their allocated address space.
- Diagnosis: This is an ISP-level defense. You can test if your ISP has it implemented by attempting to send packets with spoofed source IPs from your network to a server that logs source IPs.
- Fix: Advocate for and ensure your ISP implements BCP 38.
- Why it works: If packets with spoofed source IPs are dropped by the upstream network before they even reach the DNS resolver, the attacker cannot successfully spoof the victim’s IP.
Response Rate Limiting (RRL) on Authoritative Servers: If you run authoritative DNS servers, you can configure them to limit the rate of responses to specific client IPs, particularly for wildcard or ANY queries which can generate large responses.
- Diagnosis: Monitor your authoritative DNS server logs for an unusually high number of responses to specific IP addresses, especially for ANY queries.
- Fix: Configure RRL in BIND:
```
zone "example.com" IN {
    type master;
    file "db.example.com";
    // ...
    response-rate-limiting {
        window 5; // 5 seconds
        max-வது-per-window 10; // Max 10 responses per window
        // ... more options for different query types
    };
};
```
- Why it works: This prevents your own authoritative servers from being used as an amplification vector for large, repetitive responses to a single spoofed IP.
Anycast DNS Infrastructure: Distributing your DNS servers across multiple geographic locations using Anycast.
- Diagnosis: Not a direct diagnostic, but the absence of an Anycast setup makes you more vulnerable to a single point of failure during a large attack.
- Fix: Implement an Anycast network for your DNS servers. This involves announcing the same IP prefix from multiple locations, so traffic is routed to the nearest available server.
- Why it works: Even if one server is overwhelmed, traffic will be redirected to other available servers, distributing the load and maintaining service availability.
DNS Firewall / Sinkholing: Using specialized security appliances or software to identify and block malicious DNS traffic or redirect it.
- Diagnosis: Monitor network traffic for patterns indicative of DNS amplification (e.g., unusually large UDP packets on port 53, high query volumes to specific DNS servers).
- Fix: Deploy a DNS firewall or security appliance that can detect and block traffic patterns associated with DNS amplification attacks. This might involve blocking queries to known malicious domains or rate-limiting responses.
- Why it works: These systems act as a dedicated defense layer, actively identifying and neutralizing attack traffic before it reaches your core network.

The next problem you’ll likely encounter after mitigating DNS amplification is a SYN flood attack, which targets the TCP handshake and requires similar but distinct rate-limiting and filtering strategies.