US-CERT Technical Cyber Security Alert - DNS Amplification Attacks (TA13-088A)
National Cyber Awareness System:

TA13-088A: DNS Amplification Attacks
03/29/2013 02:26 PM EDT

Original release date: March 29, 2013 | Last revised: July 05, 2013
Systems Affected

Domain Name System (DNS) servers

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
recursive DNS servers to overwhelm a victim system with DNS response traffic.


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
recursive DNS servers to overwhelm a victim system with DNS response traffic. The
basic attack technique consists of an attacker sending a DNS name lookup request to
an open recursive DNS server with the source address spoofed to be the victim’s
address. When the DNS server sends the DNS record response, it is sent instead to the
victim. Attackers will typically submit a request for as much zone information as
possible to maximize the amplification effect. Because the size of the response is
typically considerably larger than the request, the attacker is able to amplify the
volume of traffic directed at the victim. By leveraging a botnet to perform
additional spoofed DNS queries, an attacker can produce an overwhelming amount of
traffic with little effort. Additionally, because the responses are legitimate data
coming from valid servers, it is especially difficult to block these types of

While the attacks are difficult to prevent, network operators can implement several
possible mitigation strategies. The primary element in the attack that is the focus
of an effective long-term solution is the detection and elimination of open recursive
DNS resolvers. These systems are typically legitimate DNS servers that have been
improperly configured to respond to recursive queries on behalf of any system, rather
than restricting recursive responses only to requests from local or authorized
clients. By identifying these systems, an organization or network operator can reduce
the number of potential resources that the attacker can employ in an attack.


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



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
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
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
directly test an individual DNS resolver to determine if it allows open recursion. 
This will allow an administrator to determine if configuration changes are necessary
and verify that configuration changes have been effective [3].  Finally, the site
offers statistics showing the number of open resolvers detected on the various
Autonomous System (AS) networks, sorted by the highest number found [4].

Another freely available, web-based tool for testing DNS resolvers is DNSInspect. 
This tool is similar to The Measurement Factory in that it tests a specific resolver
for vulnerability, but it offers the ability to test an entire DNS Zone for several
other potential configuration and security issues [5].


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 key indicator is a query response without a matching request.  


Unfortunately, due to the overwhelming 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.  While the only
effective means of eliminating this type of attack is to eliminate open recursive
resolvers, this requires a large-scale effort by numerous 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.  If you are
running a different DNS server, please see 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 (ISPs) to
deny any DNS traffic with spoofed addresses.  The Network Working Group of the
Internet Engineering Task Force released a Best Current Practice document in May 2000
that describes how an Internet service provider can filter network traffic on its
network to drop 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
test whether it is possible to reach the source address of the packet via the
interface that transmitted the packet. If it is not possible, the packet obviously
has a spoofed source address. This configuration change would considerably reduce the
potential for most current types of DDoS attacks.

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.  These systems do not need to support
resolution of other domains on behalf of a client, and therefore should be configured
with recursion disabled.


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” checkbox, and then click OK.
Limiting Recursion to Authorized Clients

For DNS servers that are deployed within an organization or ISP to support name
queries on behalf of a client, the resolver should be configured to only allow
queries on behalf of authorized clients.  These requests should typically only come
from clients within the organization’s network address range.


In the global options, add the following [10]:
acl corpnets {;; };
options {
  allow-query { corpnets; };
  allow-recursion { corpnets; };

Microsoft DNS Server

It is not currently possible to restrict recursive DNS requests to a specific client
address range in Microsoft DNS Server.  The most effective means of approximating
this functionality is to configure the internal DNS server to forward queries to an
external DNS server and restrict DNS traffic in the firewall to restrict port 53 UDP
traffic to the internal server and the external forwarder [11].

Response Rate Limiting (RRL) of Recursive Name Servers

There is currently an experimental feature available as a set of patches for BIND9
that allows an administrator to restrict the number of responses per second being
sent from the name server [12].  This is intended to reduce the effectiveness of DNS
amplification attacks by reducing the volume of traffic coming from any single


Patches are currently 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, add the following lines to the options block
of the authoritative views [13]:
rate-limit {
    responses-per-second 5;
    window 5;

Microsoft DNS Server

This option is currently not available for Microsoft DNS Server.

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


[1] Open DNS Resolver Project
[2] The Measurement Factory, "List Open Resolvers on Your Network"
[3] The Measurement Factory, "Open Resolver Test"
[4] The Measurement Factory, "Open Resolvers for Each Autonomous System"
[5] "DNSInspect," DNSInspect.com
[7] BCP 38: Network Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing
[8] Chapter 3. Name Server Configuration
[9] Disable recursion on the DNS server
[10] Chapter 7. BIND 9 Security Considerations
[11] Configure a DNS Server to Use Forwarders
[12] DNS Response Rate Limiting (DNS RRL)
[13] Response Rate Limiting in the Domain Name System (DNS RRL)
Revision History

March 29, 2013: Initial release
April 18th, 2013: Minor updates to Description and Solution sections(Source IP
Verification and BIND9)
July 5th, 2013: Added disclaimer for DNS request rate limiting


What's the real cost of a security breach?

The majority of business decision makers admit that their organisation will suffer an information security breach and that the cost of recovery could start from around $1 million.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Thu, Feb 11th