A Domain Name Server (DNS) amplification attack is a distributed denial of service (DDoS) that uses publically accessible open DNS servers to overwhelm a victim system with DNS response traffic.
The primary technique consists of an attacker sending a DNS name lookup request to an open DNS server with the source address spoofed to be the target’s address. When the DNS server sends the DNS record response, it is sent instead to the target. This creates a denial of service to the target.
Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. In most attacks of this type the spoofed queries sent by the attacker are of the type, “ANY,” which returns all known information about a DNS zone in a single request.
The size of the response is considerably larger than the request, the attacker is therefore able to increase the amount of traffic directed at the victim. By leveraging a botnet to produce a large number of spoofed DNS queries, an attacker can create an immense amount of traffic with little effort and very little of their own bandwidth. Additionally, because the responses are legitimate data coming from valid (allbeit open to query) DNS servers, it is extremely difficult to prevent these types of attacks. While the attacks are difficult to stop, network operators can apply several possible mitigation strategies.
While the most common form of this attack involves DNS servers configured to allow unrestricted recursive resolution for any client on the Internet, attacks can also involve authoritative name servers that do not provide recursive resolution. The attack method is similar to open recursive resolvers, but is more difficult to mitigate since even a server configured with best practices can still be used in an attack. In the case of authoritative servers, mitigation should focus on using Response Rate Limiting to restrict the amount of traffic.
In a typical recursive DNS query, a client sends a query request to a local DNS server requesting the resolution of a name or the reverse resolution of an IP address. The DNS server performs the necessary queries on behalf of the client and returns a response packet with the requested information or an error. The DNS specification does not allow for unsolicited responses. In a DNS amplification attack, the main indicator is a query response without a matching request.
Due to the massive traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based distributed denial-of-service attack.
Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to appear as the victim’s system, the first step to reducing the effectiveness of DNS amplification is for Internet Service Providers to reject any DNS traffic with spoofed addresses. The Network Working Group of the Internet Engineering Task Force released Best Current Practice 38 document in May 2000 and Best Current Practice 84 in March 2004 that describes how an Internet Service Provider can filter network traffic on their network to reject packets with source addresses not reachable via the actual packet’s path. The changes recommended in this document would cause a routing device to evaluate whether it is possible to reach the source address of the packet via the interface that transmitted the packet. If it is not possible, then the packet obviously has a spoofed source address. This configuration change would substantially reduce the potential for most popular types of DDoS attacks. As such, we highly recommend to all network operators to perform network ingress filtering if possible.
In some cases the above may not be possible or practical. The only other option is to ‘throw’ more bandwidth at the problem, which is a ‘finger in the dam’ approach. The only way to overcome this effectively is to use a cloud based DDOS service such as Akamai Prolexic. However unless the victim is BGP connected this won’t be possible as Prolexic uses BGP to protect a BGP connected network. For example if the customer only has a small IP range (/30 or /28) they can’t be BGP connected to Prolexic. This would necessitate them having an ‘upstream’ clean pipe service, but even then the ISP or carrier would be also flooded by DDOS attack and would then need protecting themselves. The problem shifts up the food-chain.
At the point the query makes it to your (now spoofed) server it’s already too late. Your server will waste its resources trying to do something with the packets and the requests. Even if you have something like
iptables or a stateful firewall drop all connections it’s still going to use up all of the bandwidth on the server inbound. Redirecting all traffic someplace else eats up your outbound bandwidth and propagates the network failure between your server and the now new target.
It’s a network infrastructure issue. Not a server issue (unless it’s an open recursive resolver). The traffic needs to be handled (killed) further up the pipe. Other mitigation techniques for resolvers include enforcing a minimum TTL (which also helps against poisoning) and a reasonable maximum payload size for responses sent using UDP. Google DNS are using a 512 bytes limit for this reason. Theoretically it’s important to use some combination of response-rate limiting or upstream measures. Technically you could use egress-filtering on edge routers to block outgoing packets that originated on a different link/interface than the route to the spoofed destination, but on simple networks (ie with a single Internet link) that’s not feasible.
The problem is that you need to drop the traffic before it reaches your network. So even when dropping packets at your server is way too late. The best way to reduce risk is to use packet scrubbing services like Akamai who have DDoS mitigation techniques in place to prevent this traffic from reaching your network.
There are two criteria for a good amplification attack vector: 1) query can be set with a spoofed source address (e.g., via a protocol like ICMP or UDP that does not require a handshake); and 2) the response to the query is significantly larger than the query itself. DNS is a core, ubiquitous Internet platform that meets these criteria and therefore has become the largest source of amplification attacks.
DNS queries are typically transmitted over UDP, meaning that, like ICMP queries used in a SMURF attack, they are fire and forget. As a result, their source attribute can be spoofed and the receiver has no way of determining its veracity before responding. DNS also is capable of generating a much larger response than query.