How can you defend your assets against distributed reflective attacks via DNS?

DNS servers are necessary for finding resources on the internet. They are also a source of vulnerabilities, and are often poorly defended. The DNS protocol listens on port 53, and this port is therefore open in most firewalls. This combination of an open listening service and little security focus makes the protocol interesting to hackers; especially if they want to perform denial-of-service attacks, because they can use some of the features of DNS to amplify their attack vectors.

How DNS works

DNS servers are used on the internet to translate between human friendly domain names and IP addresses. DNS stands for Domain Name System, and is a database of IP addresses. For an overview of how DNS works, see this Microsoft Technet article:

DNS usually receive a recursive name query from a web browser. One specific DNS server can only hold a limited amount of information. When a query is recursive it will query other DNS servers on the internet for the correct address lookup before returning the IP address to the client. The way this works is that when the web browser queries the DNS and the DNS doesn’t have the right information it gives a referral back as the result; the address of a DNS server further down the namespace tree.

Illustration of a recursive DNS lookup. The resolver queries the DNS server with a request.The DNS server cannot find the infromation requested in its cache or zone, and queries the root server. It is then referred to the domain DNS server, which again points to the Example domain DNS server.

Attacking through Recursive Open DNS

Using recursive DNS servers to flood a target with traffic is effective for attackers because the request package sent to the DNS server is very small compared with the response (hence the term “amplified” attack). All the attacker has to do, is to spoof the sender address of the DNS request package, and submit the spoofed package to open recursive DNS servers from a large number of machines under his or her control, and voila – a DoS condition occurs for the target because the DNS server will direct all those responses to the spoofed IP. So what you need to perform this attack is:

  • A list of open recursive DNS servers
  • A spoofed UDP request package to the DNS server
  • A botnet under your control

The first point of the list is easy enough – go to and search for ‘public dns’ and it will give you a list as an instant answer.

Spoofing the IP can be done using any library that can write IP headers (or you can craft the header manually…). Here’s an example using scapy, a Python module for low level network operations:

from scapy.all import *

spoofed_packet = IP(src='spoofed_ip', dst='the dns you are trying to reach') \
	/ TCP(sport=sourceport, dport=53) / payload

So, then you only need a botnet. You can go ahead and create one by spreading malware to thousands of victims, or you can hire a botnet on the dark web – both are equally illegal and immoral, but the bad guys do this.

Defending against this mess

Using an old-fashioned IP tables firewall won’t do the job because you cannot drop traffic on port 53 (this is your DNS traffic). The DNS server can be configured to mitigate some of these attacks – but the open public ones are outside of your control. Some of them have rate control, limiting the frequency with which they can be queried for the same target, as well as per source IP.

So what can you do locally to protect against this type of attacks?

  1. Ensure you have sufficient capacity to take peak traffic loads. It is probably infeasible to build capacity for very large DDoS attacks (~ 300 Gbps) but many attacks are much smaller than this and can be absorbed by high bandwidth capacity
  2. Filter your traffic – especially unexpected traffic types. Filter out all DNS traffic for all equipment not dependent on sending DNS requests. Filter out IP’s from identified botnets and use a robust threat intelligence solution to obtain information on botnets.
  3. Use anomaly detection and use dynamic throttling of traffic from name servers. If there are sudden spikes in traffic from unusual resolvers, it may be a sign of a reflective amplification attack.
  4. For key resources, build in redundancy to redirect traffic when necessary and allowing the service to remain operational. Potentially contract with a very-high-bandwidth provider to act as a buffer to large DDoS floods.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s