DNS Amplification Attacks: How Open Resolvers Are Abused

A direct flood needs the attacker to own the bandwidth it delivers. A reflection attack does not. The attacker sends a modest stream of small requests to many third-party servers, and those servers send the large replies to the victim. DNS has been a favorite for this for years, because DNS servers answer anyone and answers can be much larger than questions. This article explains the mechanism, shows how much amplification researchers measured, and covers the defences the IETF documents.

The mechanism in three steps

1. 1

   Forge the source address

   The attacker sends a small DNS query over UDP and writes the victim's address as the sender. UDP has no handshake, so nothing along the way checks that claim.

2. 2

   Ask for something large

   A query for type ANY with EDNS(0) can return every record a name holds, up to 4,096 bytes over UDP. Rossow (2014) notes that an attacker can even configure a domain they control so that its authoritative server returns exactly 4,096-byte answers. Resolvers cache these for the TTL, so the attacker's own server barely notices the load.

3. 3

   Let the resolver do the sending

   Each resolver answers the forged address. Thousands of resolvers together flood the victim with valid-looking DNS responses from legitimate servers, and the real attacker stays hidden.

How much amplification?

Rossow defines the bandwidth amplification factor (BAF) as the UDP payload bytes an amplifier sends to the victim divided by the UDP payload bytes the attacker sent to it, with Ethernet, IP and UDP headers left out. Ordinary lookups for A or MX records amplify little. The figures below are for the ANY-based abuse of DNS, next to three other protocols measured in the same 2014 study. “Top 10%” is the average over the tenth of amplifiers that respond with the largest answers.

DNS is neither the largest amplifier nor the only one, but it is the best known. Rossow estimated about 7.8 million open resolvers by extrapolating from a scan of a random sample of one million IPv4 addresses, and he identified at least 255,819 authoritative servers, a lower bound, so the pool of potential reflectors was enormous. The authoritative figure in the table was measured on the 1,404 of those servers that deploy DNSSEC for at least one domain, and he measured the open-resolver figure with a domain he controlled. His own analysis covered more than 130 real-world attacks, and he cites three large incidents: 167 Gb/s in May 2012, 300 Gb/s against Spamhaus in March 2013 and 100 Gb/s in August 2013. In each, attackers abused open DNS resolvers with ANY requests. These are measurements from 2013 and 2014; the numbers move, the mechanism does not.

The arithmetic of leverage

Because the factor divides what the victim receives by what the attacker sends, the bandwidth an attacker needs is the target divided by the factor. At the average of 28.7 for open resolvers, a flood of 1 Gb/s needs roughly 35 Mb/s of spoofed queries. At the 98.3 figure for the top tenth of authoritative servers, it needs about 10 Mb/s. For NTP's top figure of 4,670, Rossow's abstract puts it at 0.02 percent of the bandwidth the attacker wants the victim to receive. The factor ignores packet headers, so real traffic differs somewhat, but the leverage is the point: a modest uplink becomes a flood.

Why the root cause is spoofing

A reflection attack only works if forged packets can leave the attacker's network. Kührer and colleagues (2014) studied this directly. Their remote test revealed up to 2,692 autonomous systems that lack egress filtering, and Rossow cites the Spoofer Project's finding that 25 percent of autonomous systems allowed address spoofing as of July 2013. The same study reports that, during a notification campaign run with the security community, the number of NTP servers vulnerable to monlist amplification fell by more than 92 percent, although the authors say they cannot prove the campaign was the cause.

Three layers of defence

• Stop forged packets leaving the network. BCP 38 (RFC 2827) describes ingress filtering to defeat denial-of-service attacks that use forged source addresses, and BCP 84 (RFC 3704) extends it to multihomed networks. This is the fix that removes the cause.
• Do not run an open resolver. BCP 140 (RFC 5358) recommends serving recursion only to the intended clients, using an access list by source address, the incoming interface, or signed queries (TSIG or SIG(0)). RFC 5358 notes that choosing clients by incoming interface suits small-office and home routers with embedded recursive resolvers, which should not answer the whole internet.
• Make the answers less useful. RFC 8482 gives guidance for answering ANY queries with minimal responses instead of everything the server holds. DNS Cookies (RFC 7873) give servers a lightweight way to verify clients and limit abuse by off-path attackers. RFC 7766 notes that the TCP handshake generally prevents address spoofing, which makes TCP useful against reflection and amplification, and that TCP is now widely used in response rate limiting. Rossow cautions that carefully crafted attacks can evade poorly designed rate limiting, so it complements filtering of spoofed traffic and does not replace it.

Checking whether your resolver is open

Test from a network that is not the resolver's own, by asking it to resolve a name it does not serve. If you get an answer, it serves outsiders. An authoritative-only server will typically refuse recursive queries about other zones with REFUSED (the response codes are in Inside a DNS message).

dig @192.0.2.53 www.example.com A

Sources and further reading

• Christian Rossow, Amplification Hell: Revisiting Network Protocols for DDoS Abuse, NDSS Symposium, 2014
• Marc Kührer, Thomas Hupperich, Christian Rossow and Thorsten Holz, Exit from Hell? Reducing the Impact of Amplification DDoS Attacks, 23rd USENIX Security Symposium, 2014, pp. 111-125
• RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (Ferguson and Senie, 2000)
• RFC 3704: Ingress Filtering for Multihomed Networks (Baker and Savola, 2004)
• RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks (Damas and Neves, 2008)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• RFC 7873: Domain Name System (DNS) Cookies (Eastlake and Andrews, 2016)
• RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (Abley et al., 2019)