exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Technical Cyber Security Alert 2013-088A

Technical Cyber Security Alert 2013-088A
Posted Mar 30, 2013
Authored by US-CERT | Site us-cert.gov

Technical Cyber Security Alert 2013-088A - A misconfigured Domain Name System (DNS) server can be exploited to participate in a Distributed Denial of Service (DDoS) attack.

tags | advisory, denial of service
SHA-256 | 267de1873a51753001d948053d442596ac0e2e46a65b9c2f4f3f241dd131f274

Technical Cyber Security Alert 2013-088A

Change Mirror Download

Hash: SHA1

National Cyber Awareness System
TA13-088A: DNS Amplification Attacks

Original release date: March 29, 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 victims address. When
the DNS server sends the DNS record response, it is sent instead to the
victim. 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 attacks.

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

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 site is similar to The Measurement Factorys ability to
test a specific resolver for vulnerability, but 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
Microsofts DNS Server, which are two widely deployed DNS servers. If you
are running a different DNS server, please see your vendors
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 victims system, the
first step to reducing the effectiveness of DNS amplification is for
Internet Service Providers 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
their network to drop packets with source addresses not reachable via
the actual packets path [7]. This configuration change would
considerably reduce the potential for most current types of DDoS

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


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

Rate Limiting Response 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 resolver.


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.


* [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
* [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

Relevant URL(s):














Produced by US-CERT, a government organization.

This product is provided subject to this Notification:

Privacy & Use policy:

This document can also be found at

For instructions on subscribing to or unsubscribing from this
mailing list, visit http://www.us-cert.gov/mailing-lists-and-feeds/

Version: GnuPG v1.4.5 (GNU/Linux)

Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    28 Files
  • 9
    Jul 9th
    44 Files
  • 10
    Jul 10th
    24 Files
  • 11
    Jul 11th
    25 Files
  • 12
    Jul 12th
    11 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    0 Files
  • 16
    Jul 16th
    0 Files
  • 17
    Jul 17th
    0 Files
  • 18
    Jul 18th
    0 Files
  • 19
    Jul 19th
    0 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By