DNS Amplification Attack: How It Works, How to Stop It

The usual way people find out their server took part in an attack is an email from the hosting provider with a list of timestamps and a polite threat to suspend the machine. The cause is often a DNS resolver installed for a test years ago that still answers anyone who asks.

How a DNS amplification attack works

The idea fits in three observations, and you do not need any attack recipe to understand it.

DNS mostly runs over UDP, and UDP has no handshake, so the server never confirms the source address of a packet is real. A small query can trigger a large response, for example when many records or DNSSEC signatures come back. And the internet still has plenty of servers that answer everyone: open recursive resolvers and misconfigured authoritative servers.

Put those together. If the source address on a query is forged to be the victim’s IP, the resolver dutifully sends its large reply to the victim. The attacker sends a trickle, the victim receives a torrent. Because the replies come from thousands of legitimate servers, the victim cannot simply block one bad IP.

How much amplification are we talking about?

CISA’s alert TA14-017A lists bandwidth amplification factors for common UDP protocols:

Source: CISA, UDP-Based Amplification Attacks.

A factor of 50 means 1 Mbit/s of forged queries turns into roughly 50 Mbit/s arriving at the target. DNS is not the worst offender on the list, but DNS servers are everywhere, which keeps it popular. The table is also a reminder that an audit of exposed UDP services should cover far more than port 53.

For where reflection sits among other attack classes, see types of DDoS attacks.

Victim or reflector: two very different problems

As the victim, your own firewall is mostly useless, because the bottleneck is the link in front of it. Your provider has to filter before traffic reaches you. The first steps are covered in DDoS attack: what to do.

As the reflector, the fix is entirely in your hands, and every closed resolver is one fewer weapon available to someone else.

Finding an open resolver

Run this from a machine outside your network:

dig @192.0.2.53 example.com A

An open resolver returns NOERROR, an address in the answer section and the ra (recursion available) flag. A correctly locked-down server returns something like this:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41870
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

Here REFUSED and the warning are the good outcome. On the server, ss -ulpn | grep ':53 ' tells you which process is listening on port 53. It is often something nobody remembers installing.

Configs that close the door

BIND, authoritative only:

options {
    directory "/var/cache/bind";
    recursion no;
    allow-query-cache { none; };

    // Response Rate Limiting
    rate-limit {
        responses-per-second 10;
    };
};

BIND as a resolver for your own network:

acl internal { 127.0.0.1; ::1; 192.168.0.0/16; 10.0.0.0/8; };

options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
};

Unbound only accepts queries from localhost by default. If you open it to your LAN, do it explicitly:

server:
    interface: 0.0.0.0
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    access-control: 0.0.0.0/0 refuse

Validate with named-checkconf or unbound-checkconf, reload and rerun the external test.

Response rate limiting (RRL) caps how often an authoritative server sends the same answer to the same destination. Real resolvers rarely ask for the identical record ten times a second; a reflection attack does exactly that. Ten responses per second is a common starting value, then watch the logs and adjust.

The root cause: spoofed sources and BCP 38

None of this works without forged source addresses. BCP 38, published as RFC 2827, describes ingress filtering: a network only forwards packets whose source address actually belongs to that network. If every provider did it, spoofed reflection would disappear. Many do; not all.

If you operate your own network or announce your own prefixes, make sure you filter spoofed sources leaving it. On a rented server, that responsibility sits with the host, and it is a fair question to ask them.

Checklist

• External dig test against every public DNS IP returns REFUSED
• Authoritative servers run with recursion no;
• Resolvers allow recursion only for internal ranges
• Response rate limiting enabled on authoritative servers
• ss -ulpn shows no forgotten UDP services (NTP, SNMP, SSDP, Memcached)
• Alerting on outbound UDP from port 53
• HTTP-level limits handled separately, see rate limiting

DNSSEC and amplification, honestly

Signed zones produce bigger answers because signatures and keys travel with them, which makes them more interesting for reflection. The answer is to pair DNSSEC with RRL, not to drop DNSSEC. Without signatures, an attacker can feed resolvers forged records, and that tends to do more damage than a few minutes of extra load.

If someone else runs your zones, ask whether they use RRL, and keep the domain at a registrar with DNSSEC support that passes DS records to the registry correctly. To protect your authoritative servers against floods aimed at them, read DNS DDoS attacks.

A sensible next step is an inventory: list your domains, where their nameservers live and whether DNSSEC is on. The betadomain guides on domain security cover the registrar side, and the current price list shows what each extension costs per year.

Step by step

1. Decide what the server is forWork out whether the DNS server is authoritative for your own zones, a resolver for an internal network, or both. An authoritative-only server needs no recursion at all.
2. Test for open recursion from outsideFrom a machine on another network, run dig @your-ip example.com A. An answer with the ra flag and an IP address means the resolver is open. Status REFUSED is what you want to see.
3. Disable or restrict recursionIn BIND, set recursion no on authoritative-only servers, or limit allow-recursion to your own networks on resolvers. In Unbound, allow access-control only for internal ranges.
4. Enable response rate limitingOn authoritative BIND servers, add a rate-limit block with responses-per-second, for example 10, inside options.
5. Validate, reload and retestRun named-checkconf or unbound-checkconf, reload the service and repeat the external dig test.
6. Audit other UDP servicesList listening UDP sockets with ss -ulpn and close or firewall services such as NTP, SNMP, SSDP and Memcached that should not face the internet.