TA13-088A: DNS Amplification Attacks

["US-CERT" <US-CERT () public govdelivery com>]

US Computer Emergency Readiness Team banner graphic

National Cyber Awareness System:

TA13-088A: DNS Amplification Attacks [ https://www.us-cert.gov/ncas/alerts/TA13-088A ] 03/29/2013 02:26 PM EDT 
Original release date: March 29, 2013 | Last revised: July 22, 2013

Systems Affected

  * Domain Name System (DNS) servers 

Overview

A Domain Name Server (DNS) amplification attack is a popular form of distributed denial of service (DDoS) that relies 
on the use of publically accessible open DNS servers to overwhelm a victim system with DNS response traffic.

Description

A Domain Name Server (DNS) Amplification attack is a popular form of Distributed Denial of Service (DDoS), in which 
attackers use publically accessible open DNS servers to flood a target 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. Attackers will typically submit a request for as much zone information as possible to maximize the 
amplification effect. In most attacks of this type observed by US-CERT, 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. Because the size of the 
response is considerably larger than the request, the attacker is 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. Additionally, because the responses are legitimate data coming from valid 
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 that US-CERT has observed 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.

Impact

A misconfigured Domain Name System (DNS) server can be exploited to participate in a distributed denial of service 
(DDoS) attack.

Solution

DETECTION

While it is not easy to identify authoritative name servers used in DNS reflection attacks as vulnerability is not 
caused by a misconfiguration, there are several freely available options for detecting open recursive resolvers.  
Several organizations offer free, web-based scanning tools that will search a network for vulnerable open DNS 
resolvers.  These tools will scan entire network ranges and list the address of any identified open resolvers.

"Open DNS Resolver Project"
http://openresolverproject.org
The Open DNS Resolver Project has compiled a list of DNS servers that are known to serve as globally accessible open 
resolvers. The query interface allows network administrators to enter IP ranges in CIDR format [1].

"The Measurement Factory"
http://dns.measurement-factory.com
Like the Open DNS Resolver Project, the Measurement Factory maintains a list of Internet accessible DNS servers and 
allows administrators to search for open recursive resolvers [2]. In addition, the Measurement Factory offers a free 
tool to test a single DNS resolver to determine if it allows open recursion. This will allow an administrator to 
determine if configuration changes are required and verify that configuration changes have been successful [3]. 
Finally, the site offers statistics showing the number of public resolvers detected on the different Autonomous System 
(AS) networks, sorted by the highest number found [4].

"DNSInspect"
http://www.dnsinspect.com
Another freely available, web-based tool for testing DNS resolvers is DNSInspect. This site is similar to The 
Measurement Factory’s ability to assess an individual resolver for vulnerability, but offers the ability to test an 
entire DNS Zone for several other possible configuration and security issues [5].

Indicators

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 [6, page 21]. The specification does not allow 
for unsolicited responses. In a DNS amplification attack, the main indicator is a query response without a matching 
request.  

MITIGATION

Unfortunately, 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. However, 
it is possible to reduce the number of servers that can be used by attackers to generate the traffic volumes.

While the only effective means of eliminating the use of recursive resolvers in this type of attack is to eliminate 
unsecured recursive resolvers, this requires an extensive effort by various parties. According to the Open DNS Resolver 
Project, of the 27 million known DNS resolvers on the Internet, approximately “25 million pose a significant threat” of 
being used in an attack [1]. However, several possible techniques are available to reduce the overall effectiveness of 
such attacks to the Internet community as a whole. Where possible, configuration links have been provided to assist 
administrators with making the recommended changes. The configuration information has been limited to BIND9 and 
Microsoft’s DNS Server, which are two widely deployed DNS servers on federal networks. If you are running a different 
DNS server, please consult your vendor’s documentation for configuration details.

Source IP Verification

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 [7]. 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.

Disabling Recursion on Authoritative Name Servers

Many of the DNS servers currently deployed on the Internet are exclusively intended to provide name resolution for a 
single domain. In these systems, DNS resolution for private client systems may be provided by a separate server and the 
authoritative server acts only as a DNS source of zone information to external clients. These systems do not need to 
support recursive resolution of other domains on behalf of a client, and should be configured with recursion disabled.

Bind9

Add the following to the global options [8]:
options {
     allow-query-cache { none; };
     recursion no;
};

Microsoft DNS Server

In the Microsoft DNS console tool [9]:


  * Right-click the DNS server and click Properties. 
  * Click the Advanced tab. 
  * In Server options, select the “Disable recursion” check box, and then click OK. 

Limiting Recursion to Authorized Clients

For DNS servers that are deployed within an organization or Internet Service Provider, the resolver should be 
configured to perform recursive queries on behalf of authorized clients only. These requests typically should only come 
from clients within the organization’s network address range. We highly recommend that all server administrators 
restrict recursion to only clients on the organization’s network.

BIND9

In the global options, include the following [10]:
acl corpnets { 192.168.1.0/24; 192.168.2.0/24; };
options {
  allow-query { any; };
  allow-recursion { corpnets; };
};

Microsoft DNS Server

It is not currently possible to restrict recursive DNS requests to a particular client address range in Microsoft DNS 
Server. To approximate the functionality of the BIND access control lists in Microsoft’s DNS Server, a different 
caching-only name server should be set up internally to provide recursive resolution. A firewall rule should be created 
to block incoming access to the caching-only server from outside the organization’s network. The authoritative name 
server functionality would then need to be hosted on a separate server, but configured to disable recursion as 
previously described.

Response Rate Limiting (RRL)

There is currently an experimental feature available as a set of patches for BIND9 that allows an administrator to 
limit the maximum number of responses per second being sent to one client from the name server [11]. This functionality 
is intended to be used on authoritative domain name servers only as it will affect performance on recursive resolvers. 
To provide the most effective protection, we recommend that authoritative and recursive name servers run on different 
systems, with RRL implemented on the authoritative server and access control lists implemented on the recursive server. 
This will reduce the effectiveness of DNS amplification attacks by reducing the amount of traffic coming from any 
single authoritative server while not affecting the performance of the internal recursive resolvers.

BIND9

There are currently patches available for 9.8.latest and 9.9.latest to support RRL on UNIX systems. Red Hat has made 
updated packages available for Red Hat Enterprise Linux 6 to provide the necessary changes in advisory 
RHSA-2013:0550-1. On BIND9 implementation running the RRL patches, include the following lines to the options block of 
the authoritative views [12]:
rate-limit {
    responses-per-second 5;
    window 5;
};

Microsoft DNS Server

This option is currently not available for Microsoft DNS Server.

"*Disclaimer:*"  Rate limiting DNS responses may prevent legitimate hosts from receiving answers. Such hosts may be at 
increased risk for successful DNS cache poisoning attacks.

RRL of DNS responses may prevent legitimate hosts from receiving answers. Such hosts may be at increased risk for 
successful DNS cache poisoning attacks.

References

  * [1] Open DNS Resolver Project [ http://openresolverproject.org ] 
  * [2] The Measurement Factory, "List Open Resolvers on Your Network" [ 
http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl ] 
  * [3] The Measurement Factory, "Open Resolver Test" [ http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl 
] 
  * [4] The Measurement Factory, "Open Resolvers for Each Autonomous System" [ 
http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html ] 
  * [5] "DNSInspect," DNSInspect.com [ http://www.dnsinspect.com ] 
  * [6] RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES [ http://tools.ietf.org/html/rfc1034 ] 
  * [7] BCP 38: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing 
[ http://tools.ietf.org/html/bcp38 ] 
  * [8] Chapter 3. Name Server Configuration [ http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch03.html#id2567992 
] 
  * [9] Disable recursion on the DNS server [ http://technet.microsoft.com/en-us/library/cc787602.aspx ] 
  * [10] Chapter 7. BIND 9 Security Considerations [ 
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch07.html#Access_Control_Lists ] 
  * [11] DNS Response Rate Limiting (DNS RRL) [ http://ss.vix.su/~vixie/isc-tn-2012-1.txt ] 
  * [12] Response Rate Limiting in the Domain Name System (DNS RRL) [ http://www.redbarn.org/dns/ratelimits ] 
  * [13] The Measurement Factory, "Open Resolvers for Each Autonomous System" [ 
http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html ] 
  * [14] Configure a DNS Server to Use Forwarders [ http://technet.microsoft.com/en-us/library/cc754941.aspx ] 

Revision History

  * March 29, 2013: Initial release 
  * April 18, 2013: Minor updates to Description and Solution sections(Source IP Verification and BIND9) 
  * July 5, 2013: Added disclaimer for DNS request rate limiting 
  * July 8, 2013: Updates to Description, Detection, and Mitigation sections 
  * July 22, 2013: Minor updates to recursion and RRL advice 
________________________________________________________________________

This product is provided subject to this Notification [ http://www.us-cert.gov/privacy/notification ] and this Privacy 
& Use [ http://www.us-cert.gov/privacy/ ] policy.

________________________________________________________________________

OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ 
http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ 
http://www.us-cert.gov/related-resources ] 

STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ]