A DNS amplification attack (aka DNS reflection attack) is a type of distributed denial of service (DDos) attack that takes advantage of the fact that a small DNS query can generate a much larger response. When combined with source address spoofing, an attacker can direct a large volume of network traffic to a target system by initiating relatively small DNS queries.
The amplification factor in this type of attack depends on the type of DNS query and whether or not a DNS server (used as a middleman in the attack) supports sending large UDP packets in a response, which is a feature intended to optimize DNS communications. If a DNS server does not support large (>512 bytes) UDP packets in a response, it can revert to TCP. This reduces the effectiveness of an amplification attack because TCP is much less vulnerable to source address spoofing.
An attacker who is planning a DNS amplification attack can take advantage of the following:
- Open recursion: Name servers on the Internet that have recursion enabled and provide recursive DNS responses to anyone are referred to as “open resolvers.” The number of DNS servers providing open recursion on the Internet have been estimated to be anywhere from several hundred thousand to several million. In a DNS amplification attack, the open resolver functions as the source of amplification, receiving a small DNS query and returning a much larger DNS response. These DNS servers are not normally compromised, but actually functioning as intended.
- Source address spoofing: Source address spoofing alters a packet’s return address so that the packet appears to have come from a source other than the sender. In a DNS amplification attack, the source address for the DNS query is spoofed with the target of the attack, similar to a “Smurf” attack. When an open resolver returns a DNS response, this response is incorrectly sent to the spoofed address.
- Botnets: Botnets are groups of online computers that have been compromised by an attacker. Botnets are used in a DNS amplification attack to send DNS queries to open resolvers.
- Malware: Malware can be used to gain access to botnet computers and provide a means to trigger DNS amplification attacks.
- EDNS0: Extension Mechanisms for DNS (EDNS0 as defined in RFC 2671) allow DNS requestors to advertise the size of their UDP packets and facilitate the transfer of packets larger than 512 bytes. Without EDNS0, a 64 byte query can result in (at most) at 512 byte UDP reply corresponding to an amplification factor of 512/64 = 8x.
- DNSSEC: DNSSEC adds security to DNS responses by providing the ability for DNS servers to validate DNS responses. DNSSEC prevents cache-poisoning attacks, but adds cryptographic signatures resulting in larger DNS message sizes. As a consequence, DNSSEC also requires EDNS0 support; therefore a server that supports DNSSEC will also support large UDP packets in a DNS response. Because of these reasons, DNSSEC has been criticized for contributing to DNS amplification attacks.
If the target of an attack is also a DNS server, a DNS amplification attack using queries for a DNSSEC-signed zone has the potential to increase processor usage due to the cryptographic work involved in validating DNSSEC signed resource records. DNS servers can also just ignore these packets. Note: DNS servers running Windows drop these packets and log them in performance and statistics counter under a packet category of unmatched response.
It is important to note that DNSSEC itself does not enable a successful DNS amplification attack. As previously stated, an 8x amplification factor is possible even without EDNS0 or DNSSEC. Successful DNS amplification attacks do not require EDNS0 or DNSSEC.
To demonstrate how an amplification attack works, and how it is affected by DNSSEC, assume that a very large TXT record has been created on a DNS server. Note that if the record is too large, the server will not use UDP even if EDNS0 is enabled. By default, a DNS server running Windows will fall back to TCP for records that are greater than 4000 bytes in size. This can be demonstrated using Network Monitor:
In the following example, two TXT records are created on a DNS server running Windows Server 8 Beta at 10.123.182.167. Each TXT record consists of lines of text that are 256 bytes in length.
- oktxt.contoso.com contains 15 lines: 15 x 256 = 3840 bytes.
- bigtxt.contoso.com contains 16 lines: 16 x 256 = 4096 bytes.
To issue a query for these records and specify that large UDP packets are allowed in the response, we can use dig (dig @10.123.182.167 oktxt.contoso.com any +edns=0) or the resolve-dnsname Windows PowerShell cmdlet available in Windows 8 Beta. The dnssecok flag tells the server that large UDP response packets are supported:
The queries above are issued from a client computer at 10.123.183.140. Network Monitor on the DNS server shows that bigtxt.contoso.com uses TCP whereas oktxt.contoso.com uses UDP:
Specifically, the frame details for these queries show that the largest UDP playload size is 4000 bytes, and in the case of the bigtxt.contoso.com record the size was 4096 bytes (over the limit):
Since the 4000 byte UDP limit was exceeded, the DNS server used TCP in the DNS response.
The 4000 byte limit can also be displayed on the DNS server using Windows PowerShell:
PS C:> (Get-DnsServer).ServerSetting.MaximumUdpPacketSize
The frame details for oktxt.contoso.com are below. Only UDP was used for this resource record of length 3840 bytes because it is under the 4000 byte limit:
Recall that UDP is important in DNS amplification attacks because source address spoofing is a critical part of the attack. The three-way handshake used by TCP makes spoofing much more difficult than when DNS responses use UDP. Therefore, an attacker will typically want to limit the size of response so that only UDP is used.
An attacker using the oktxt.contoso.com TXT record can theoretically use a minimum transmission unit size of 64 bytes to issue a query that returns a 3840 byte UDP response, giving an amplification factor of 3840/64 = 60x.
DNS Responses in Signed Zones
p>What happens if the zone is signed? Windows 8 supports zone signing using Windows PowerShell or using a DNSSEC zone signing wizard available in DNS Manager. This process adds several new resource records to the zone, and these records are returned with the query results. Does this increase the amplification factor in a DNS amplification attack?
After zone signing, a query for oktxt.contoso.com (the smaller TXT record) provides the following network conversations:
There is a TCP conversation in addition to the UDP one, similar to what happened previously with the larger TXT record, bigtxt.contoso.com.
Examination of frame details for the UDP exchange reveals that the same TXT record is sent over UDP as was sent before zone signing:
After zone signing, the additional TCP packet exchange includes the DNSSEC related records (RRSIG):
Signing a DNS zone and adding DNSSEC records to a DNS response increases the total size of a response, but does not increase the risk for DNS amplification past the existing limit placed on the server for UDP response size.
Since the TCP conversation cannot be easily spoofed, these additional records do not inherently increase the severity of DNS amplification attacks.
However, an amplification factor of 60 is not trivial, and DNS amplification attacks continue to be a risk on the Internet. Some things that you can do to help prevent DNS amplification attacks include:
- Do not place open DNS resolvers on the Internet. Limiting the clients that can access the resolver greatly decreases the ability of an attacker to use it maliciously. This can be accomplished using firewall rules, router IP access lists, or other methods.
- Prevent IP address spoofing by configuring Unicast Reverse Path Forwarding (URPF) on network routers. A router configured to use URPF (defined in RFC3074) limits an attacker’s ability to spoof packets by comparing the packet’s source address with its internal routing tables to determine if the address is plausible. If not, the packet is discarded.
- Deploy an intrusion prevention system (IPS) device or monitor DNSSEC traffic in some way. Large numbers of outgoing packets with the same target address, especially whose count suddenly spikes, is a good indicator of an active attack. Deploying filters to drop, limit, or delay the incoming suspect packets should lessen the impact of the attack on the local network and attack target. As previously mentioned, Windows DNS servers drop unmatched response packets and log them in performance and statistics counters. It is important to regularly monitor these counters.