DNS amplification attack: how not to be the source or the target

DNS amplification attacks are among the most common volumetric vectors, and they have one characteristic that sets them apart from most others: the same network can be both the target and the weapon. The attacker does not send traffic to the victim directly: they use somebody else’s DNS servers to do it, multiplying the volume along the way.

This article covers both sides of the problem: how not to become the source of such an attack, and how to limit the damage when your own network is the target.

The mechanism in three sentences

The attacker sends a DNS query with a spoofed source address, substituting the victim’s address. The DNS server, having no way to verify the sender, returns the answer to that address. Because the answer can be many times larger than the query, and because the attacker sprays queries at thousands of servers at once, the victim receives traffic out of all proportion to what the attacker had to send.

Two practical conclusions follow. First, the traffic reaches the victim from a very large number of genuine, unspoofed addresses: these are real DNS servers, not bots. Second, the attack is only possible because somewhere along the path one party allowed the source address to be spoofed, and another exposed a server that answers strangers.

Part one: not being the source

This is the part that is easy to forget, because the problem does not hurt your own network. And yet: an open resolver in your address space means the network takes part in attacks on others, generates outbound traffic, loads your own links, and ends up on threat reports, from where it returns as restrictions imposed by transit providers.

Checking for open resolvers

The simplest approach is to scan your own prefixes for servers that answer recursive queries from outside. A test query sent from outside the network should be refused; if a valid answer comes back, the resolver is open:

dig @<server-address> +short example.com A

The same test is worth repeating across customer address space if you provide access services: open resolvers on subscriber routers are far more common than on operator servers.

Restricting recursion

A recursive server should answer its own users only, and an authoritative server should not provide recursion at all. In BIND the two roles are separated explicitly:

acl "trusted" { 10.0.0.0/8; 192.0.2.0/24; localhost; };

options {
    recursion yes;
    allow-recursion { trusted; };
    allow-query-cache { trusted; };
    additional-from-cache no;
};

If the server is authoritative, set recursion no; and leave allow-query { any; }; only for the zones it actually serves.

Limiting the response rate

An authoritative server that cannot be closed off from the world is protected with response rate limiting. It detects repetitive, identical queries from one range and starts omitting or truncating a share of the answers, which removes the economic sense of the attack:

rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

The values are matched to the traffic profile of the specific server: treat the above as a starting point for observation, not a finished recipe.

Blocking address spoofing at the source

This is the single most effective measure against the entire class of amplification attacks, and simultaneously the one most often skipped. If a network does not emit packets with source addresses outside its own space, a spoofed-source attack cannot be launched from it.

At the edge facing customers, enable source address validation against the routing table: in strict mode where traffic is unidirectional, and loose mode where routing can be asymmetric.

Juniper:  set interfaces ge-0/0/0 unit 0 family inet rpf-check
Cisco:    ip verify unicast source reachable-via rx

Part two: being the target

When your address is the target, the picture is different. Traffic arrives from genuine DNS servers scattered worldwide, so blocking by source address makes no sense: the list would be endless, and along the way you would cut off servers you actually rely on.

What can be filtered

What characterises this vector is a fixed source port 53 over UDP, with responses that are large and frequently fragmented. That is enough to build a filtering rule, provided you do not need to receive DNS answers on the attacked address at that moment.

A BGP FlowSpec rule matching that pattern acts on the edge router and drops the traffic before it enters the network. Once WanGuard detects the anomaly it generates such a rule automatically from the recognised vector, and the operator can narrow or widen it.

What cannot be filtered

It is worth knowing the limits of this method so as not to build false expectations. If the attack uses random source ports or mixes several vectors at once, the matching criteria stop being disjoint and filtering starts catching legitimate traffic. In that situation what remains is rate-limiting the pattern, or cutting the address off with a blackhole.

Fragmentation behaves similarly: non-initial fragments carry no layer-four headers, so a rule matching the source port will not cover them. They have to be handled separately.

Blackholing as a last resort

When the volume threatens the links, the only way out is to cut off traffic to the attacked address. Blackholing ends the attack at the cost of that one address, protecting the rest of the network. For it to work correctly, without loading the console or the router, the discard route must be configured properly, which we cover in a separate article on safe blackholing.

Checklist

• Prefixes scanned for open resolvers, including subscriber address space.
• Recursive servers answer their own users only.
• Authoritative servers have recursion disabled.
• Publicly exposed servers have response rate limiting enabled.
• Source address validation is active on subscriber links (and not in strict mode on transit boundaries).
• Detection thresholds cover the DNS vector, and filtering rules are prepared before an attack rather than during one.
• The blackholing procedure has been tested outside an attack.

The source address validation recommendations are based on BCP 38 (RFC 2827) and BCP 84 (RFC 3704).