Respond to a Detected DNS Amplification Attack (2026)

A DNS amplification attack works by exploiting open DNS resolvers to flood a target with DNS response traffic that is much larger than the initial query.

Here’s how it unfolds in practice:

Imagine a malicious actor wants to Drown your server in traffic. They can’t just send traffic from their own machines because that would be easily traceable. Instead, they use a technique called IP spoofing. They craft DNS queries that have your server’s IP address as the source IP address. These spoofed queries are sent to publicly accessible, misconfigured DNS resolvers.

These resolvers, bless their hearts, are designed to be helpful. When they receive a query, they look up the answer and send it back to the source IP address specified in the query. Because the source IP is spoofed to be yours, the resolver sends the DNS response to your server.

Now, here’s the "amplification" part. The attacker doesn’t send a simple query like "What’s the IP for example.com?". They send a query for a record type that generates a large response, like ANY or TXT records, or they query for a domain that has a very large DNS zone file. The attacker also makes sure the query is for a domain that the resolver has to look up recursively, meaning the resolver will have to query other DNS servers to get the full answer.

So, the attacker sends a small, spoofed query (say, 60 bytes) to a DNS resolver. The resolver, thinking the query came from your server, performs the lookup and sends back a much larger response (potentially several thousand bytes) to your server. Since the attacker can enlist thousands or even millions of these open DNS resolvers, your server gets overwhelmed by a massive flood of these amplified DNS responses, effectively causing a Denial of Service.

This is why you’re seeing your network saturated with UDP traffic on port 53, and it’s all originating from various public DNS servers, but with your IP address as the apparent source in the packet headers.

To combat this, you need to implement a multi-pronged approach focusing on blocking illegitimate traffic and reducing your attack surface.

1. Rate Limiting DNS Responses on Your Recursive Resolvers:

Diagnosis: Check your internal DNS servers (if you run them) for excessive UDP traffic on port 53, specifically responses to queries that originate from your network but are not destined for your internal clients. Tools like tcpdump or Wireshark can help identify the volume and source/destination of this traffic. Look for a disproportionate number of UDP packets on port 53 going out from your resolvers to external IPs, especially if the response size is significantly larger than the query size.
Fix: On your BIND DNS servers, you can implement response rate limiting (RRL) in your named.conf file. For example, to limit responses for a specific domain to 100 per second per client IP, you’d add:
```
response-rate-limit default {
    rate 100;
    window 1;
    log yes;
    ; uncomment the next line to enable rate limiting
    ; rrl-type wildcard;
};
```
Then, in your zone definition or globally, apply it:
```
zone "example.com" {
    type master;
    file "zones/db.example.com";
    response-rate-limit {
        rate 100;
        window 1;
        log yes;
    };
};
```
This mechanically limits the number of DNS responses a resolver will send to a given IP address within a time window, preventing a single client from being overwhelmed by responses from a compromised resolver.
Why it works: This directly throttles the amplification factor. Even if an attacker spoofs your IP and sends queries to many resolvers, your internal DNS servers will only send a limited number of responses back to any single spoofed source IP, diffusing the attack’s impact.

2. Block DNS Recursion from External Sources:

Diagnosis: Use firewall logs to identify any UDP port 53 traffic originating from the internet and destined for your internal DNS servers that are not intended for recursive lookups for your internal clients. The key is to differentiate between legitimate queries from your clients and unsolicited queries from the outside.
Fix: Configure your perimeter firewall to block all inbound UDP traffic on port 53 from the internet, except for traffic destined for your authorized external DNS servers (if you have any, and even then, it should be specific). If your internal DNS servers are only for internal use, ensure they do not accept recursive queries from external IP addresses. For example, on a Cisco ASA firewall, you might use:
```
access-list EXTERNAL_IN extended deny udp any interface outside eq domain
access-list EXTERNAL_IN extended permit ip any interface outside
access-group EXTERNAL_IN in interface outside
```
(This is a simplified example; actual implementation depends on your firewall vendor and existing ruleset.)
Why it works: This prevents attackers from using your DNS servers as part of the amplification chain by making them listen to external recursive requests.

3. Implement IP Source Verification (BCP38):

Diagnosis: This is a preventative measure, but if you suspect your network is being used as a source of spoofed traffic (though less common for amplification attacks originating from you), you’d look for outbound UDP port 53 traffic where the source IP does not belong to your network block.
Fix: Work with your Internet Service Provider (ISP) to implement ingress filtering on their network. This is a best practice (RFC 2827/BCP 38) where ISPs filter traffic entering their network, dropping packets with source IP addresses that do not belong to the customer’s assigned IP block. You should also implement egress filtering on your own network edge to prevent spoofed packets from leaving your network. For example, on Cisco routers, you might use:
```
ip verify unicast source reachable-via rx
```
applied to interfaces.
Why it works: This stops IP spoofing at the source. If the attacker’s ISP or your own network drops packets with spoofed source IPs, the DNS resolvers won’t receive the spoofed queries, and thus won’t send amplified responses to the target.

4. Use a DNS Sinkhole:

Diagnosis: Monitor network traffic for large volumes of UDP port 53 traffic destined for known malicious or suspicious IP addresses, or for queries to domains associated with known botnets or attack infrastructure.
Fix: Configure a dedicated DNS server (or a firewall rule) to act as a sinkhole. Any DNS query destined for a known malicious domain or IP address is redirected to this sinkhole server, which simply drops the request or returns a null response. For example, you can configure dnsmasq or BIND to return a specific IP address for certain domains:
```
# In dnsmasq.conf
address=/malicious-domain.com/127.0.0.1
```
Or using BIND’s rpz (Response Policy Zones) feature:
```
zone "malicious-domain.com" {
    type master;
    file "zones/rpz.malicious-domain.com";
};
```
And in zones/rpz.malicious-domain.com:
```
$TTL 300
@       IN      SOA     localhost. root.localhost. (1 3H 1H 1W 1H)
        IN      NS      localhost.
*       CNAME   .
```
Why it works: This intercepts and neutralizes DNS requests that might be part of an amplification attack infrastructure or attempts to resolve malicious domains, preventing them from reaching external resolvers or returning useful (amplified) data.

5. Filter Out Large DNS Responses at the Edge:

Diagnosis: Analyze traffic logs to identify unusually large UDP packets on port 53 originating from external DNS servers and destined for your network.
Fix: Configure your edge firewall or Intrusion Prevention System (IPS) to drop UDP packets on port 53 that exceed a certain size threshold. A common threshold might be 512 bytes, as legitimate, non-EDNS0 DNS responses are typically limited to this size. For example, on an iptables firewall:
```
iptables -A INPUT -p udp --dport 53 -m length --length :512 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
```
(This is a simplified example; you’d want to ensure legitimate EDNS0 traffic isn’t blocked).
Why it works: Many amplification attacks rely on sending responses larger than standard DNS packets. By dropping these oversized packets, you discard the amplified traffic before it can saturate your network.

After implementing these measures, the next attack you might face, or the next symptom you’ll see if these measures aren’t perfect, is a SYN flood against your web servers or other critical services, as attackers pivot their methods when amplification is no longer effective.