Water Torture: A Slow Drip DNS DDoS Attack

A number of our service provider customers around the world are reporting that they see a new type of DNS DDoS attack that uses the DNS as the attack vector. The service providers themselves do not appear to be the target of this attack. Instead, the attack tries to overwhelm an outside victim’s authoritative DNS servers. Once the DNS server is taken down, the victim’s domains will appear to be inaccessible.

As a side effect, our service provider customers are seeing a spike in DNS traffic resulting in increased CPU and memory usage. This blogs gives some more details about the attack and suggests what you can do to mitigate the impact of it.

The Attack

It appears that a fairly large botnet is used to send queries for the victim’s domain. Queries are made-up, with random string with up to 16 letters prepended to the victim’s domain, like:


A query for this domain is then sent to the service providers DNS server. The DNS server attempts to contact the authoritative nameserver to find the answer. If the authoritative nameserver does not reply (because it is too busy responding to queries from DNS servers all over the world, or perhaps has crashed), the DNS server attempts to contact the next authoritative nameserver and so on. Modern DNS server will make multiple attempts to contact each authoritative nameserver before giving up and responding back to the client with a SERVFAIL response.
The infected client will then repeat the same pattern but this time with another random string prepended, for example:


Even though the DNS server was unable to get a response from any of the victimdomain.com authoritative nameservers during the previous query, most DNS servers will still attempt to contact them for this second query.
Now imagine that thousands of bots are sending a relatively small number of queries for such made-up subdomains. This will trigger a large increase in the number of DNS queries sent by the service provider’s DNS servers to the victim’s nameservers.

How to Detect the Attack

While this attack most likely is targeting the authoritative servers for victimdomain.com, it also puts an increased CPU load on the DNS server by forcing it to continually initiate recursive queries and also consumes large amounts of resolver memory resources. More importantly, if the internal resolver resources are fully consumed, the resolver may drop any inbound queries, including queries from legitimate clients.

If the DNS server’s behavior is being monitored, the symptoms of the attack will also show up as:

  • Increased CPU utilization
  • Increased number of SERVFAIL responses
  • Increased number of outbound queries and retransmissions
  • Increased query latency
  • Increased number of dropped client queries (if the resolver resources are fully consumed)

One thing all of the victim domains have in common is that they appear to be Chinese sites, perhaps gaming or gambling sites.

How to Block the Attack

Because the query rate from each client IP address is quite low and because there is no response amplification, it is difficult to determine simply from packet rates or bandwidth consumption which client IP-addresses are participating in the attack. And because the names change periodically, it can be time consuming to track and block queries to the domains being used in the attack.

However, here are some specific steps you can take to minimize the impact of the attack:

  • Check your timeout settings. Most resolvers allow you to specify the initial and subsequent timeout intervals. Make sure that these values are not too high (if they are, they will tie up resolver resources longer than necessary before a query fails).
  • Increase the number of outstanding recursive queries if you have sufficient RAM on your server. This will give the resolver more resources to work with.
  • Specify a non-zero TTL for the negative responses so that if a client requests the same non-responsive name more than once, the SERVFAIL answer is cached. By RFC, you should be able to specify up to a 5 minute TTL.

Secure64 Defenses

Secure64’s DNS Cache has built-in defenses against such an attack. Under attack conditions, the Secure64 resolver will not consume any CPU or memory resources attempting to reach nameservers that it already knows are non-responsive. This adaptive behavior allows the Secure64 resolver to remain 100% available to legitimate clients under such attack conditions.

Firezilla FTP

Recently, a fake version of the popular Filezilla File Transfer Protocol (FTP) client has been made available for download on some sites. This fake version of Filezilla looks and works as expected but it also harvests login credentials in the background. These credentials are secretly sent to a hacker owned site.  This is clearly a concern for any network and action must be taken to limit the damage. There are two things you should do:

1.       Block the stealing of credentials

The domain name that the hacker used to send credentials to is aliserv2013.ru. This domain name currently does not resolve, as the nameservers appear not to respond to DNS queries anymore (interestingly enough they still respond to ping). Additionally, the FTP server also appears to be down. So the worst crisis might be over. But to be safe you should blacklist aliserv2013.ru in your DNS server. If you are using Secure64 you need to add a line like the one below and reload your cache server:

local-zone: “aliserv2013.ru” refuse log

2.       Find and clean up your clients

If your DNS server is capable of logging blacklist hits, then now is the time to check your logs and see if any of your clients are using this fake Filezilla client.

By using the log option in the Secure64 example configuration above you can see which clients are trying to access the aliserv2013.ru site. You can then reach out to them and make sure they remove the faulty FTP client.

More info can be found here:


DNS prefetching in browsers

Some browsers such as Firefox implement various types of prefetching. The basic idea is that the browser will start to preload hyperlinked pages in the background to so that once a user clicks on a link the web page will already be ready to be displayed.

Speculative prefetching like this is obviously wasteful from a DNS and network bandwidth perspective because there will be plenty of links on a page that are prefetched but that the user will not click on. On the other hand, prefetching in the browser gives a better user experience with reduced wait time.

Unfortunately for an ISP, prefetching is outside of their control. Prefetching is something that is turned on and off at the browser level. A web site owner can potentially limit prefetching by analyze its HTML code and making sure that it doesn’t have too many links on its most popular pages and also by adding special tags to links that shouldn’t be prefetched.

This blog post provides additional details about prefetching and what impact it has on DNS. In Firefox, the settings for prefetching can be changed by typing about:config in the address bar and then scrolling down to the network.dns.disablePrefetch setting. This setting is disabled by default (note the double negative) meaning that DNS prefetching is turned on. Chrome and other browsers have similar settings.

I ran a small experiment just to see if there is a large difference between turning prefetching off or on. Below is a table showing the results of this experiment. As you can see, there is quite a substantial difference in the number of queries generated. www.wikipedia.org and www.ebay.com in particular seem to generate a lot of DNS queries with prefetching turned on. This is because these pages have links to hundreds of different sub sites pages in other languages such as de.wikipedia.org (Germany) sv.wikipedia.org (Sweden), etc.  The google.com page, on the other hand, does not generate any additional queries with prefetch turned on.

without prefetch with prefetch increase factor
www.wikipedia.org 3 155 51.7
www.yahoo.com 10 12 1.2
www.fox.com 45 64 1.4
www.cnn.com 11 66 6.0
www.youtube.com 12 14 1.2
www.msn.com 28 85 3.0
www.google.com 1 1 1.0
www.ebay.com 31 147 4.7
www.amazon.com 8 65 8.1
average 16.6 67.7 4.1

From this experiment using a short list of domains it is clear that browsers with DNS prefetch enabled generate a very substantial number of additional queries to the DNS system.

Due to the 3-tiered architecture of DNS, the increased load and additional cost for browser prefetching in is borne by the Service Provider. The web site owner and the end user do not incur any significant extra cost. Companies like Wikipedia and Ebay should really look into how they have their sites coded. From what I understand, there are simple HTML codes you can add to instruct the browser not to do prefetching. To give you an example: every browser with prefetching turned on in the world will prefetch the DNS record for the Icelandic (330,000 native speakers) version of the Wikipedia site. This seems wasteful to me as it adds unnecessary extra queries to DNS systems at service providers around the world.

Lies, damn lies and DNS performance statistics

To paraphrase Mark Twain (and Benjamin Disraeli if internet search results can be trusted), there are three kinds of DNS lies: lies, damn lies and DNS performance statistics.

Most networking professionals know to have a healthy skepticism about information put out by the marketing departments of networking vendors. And so they should. It is the job of every marketer to put their company and products in the best possible light, and sometimes this means they have to stretch the truth a bit.

Read more

FAQ for CVE-4854 – BIND Vulnerability

In order to help our customers with their DNS-related questions, we wrote this blog post regarding the recently announced BIND vulnerability, CVE-4854.

What happened?

ISC announced a critical vulnerability in the popular BIND DNS software. This might affect you.  BIND servers configured either as caching or authoritative are vulnerable. Read more

Developing a Framework to Improve Critical Infrastructure Cybersecurity

Here are thoughts from our CTO, Bill Worley PhD, on properly securing critical infrastructure in our highly connected world. They are particularly applicable with what we have seen in the last year with increased DDoS attacks focused on the DNS and compromised systems for the theft of intellectual property. Read more

DNSSEC Adoption is Slow for Government Agencies

Even though more than two years have passed since federal government agencies were required to support DNS Security Extensions (DNSSEC) on their web sites, only 57 percent of agencies have met these requirements. In other words, about 40 percent of federal agencies have not secured their domains to protect users from domain name hijacking and cache poisoning attacks.

As this Network World article explains, Read more

DNSSEC Deployment Lags

DNSSEC has been slow to be accepted by commercial sites, leading a lag in DNSSEC deployment, even though it is the best solution to prevent the exposure to site hijacking. This type of hijacking is possible because of a major flaw in DNS that makes it possible for hackers to launch cache poisoning, found by security researcher Dan Kaminsky 5 years ago. Read more

A New DNS Vulnerability

A new DNS vulnerability was found in BIND yesterday, CVE-2012-5688. It is listed as a critical vulnerability.

This adds to the list of major vulnerabilities discovered in BIND. Since February of 2011, a new high vulnerability has been found on average every 60 days. This is a worrisome trend for DNS administrators concerned with the increasing sophistication and level of attacks. None of these vulnerabilities have affected Secure64 DNS servers. Read more

Protecting Your DNS

There have been several recent Denial of Service attacks reported on banks, hosting providers and federal agencies around the world.  As always with these types of attacks, one of the victims is the DNS server. Attacking DNS is effective, once the DNS server is taken down by the hacker, customers can’t reach any of the victim’s servers including mail servers, web servers, etc.

Besides the effectiveness there are also other reasons why the DNS server is the bully victim of the Internet. One of the more technical reasons is that DNS service is UDP based and not TCP based like most other services. Many simple types of attacks can be performed towards UDP based system.  Additionally, UDP is also much easier to forge than TCP so the hacker does not have to reveal his IP-address in the attack. All of this makes the DNS a juicy target.

The traditional way of protecting DNS and other servers is via stateful firewalls. However, this protection mechanism does not work well for UDP based attacks. In fact, most firewalls actually contribute to the problem rather than helping since they are not designed to cope with large floods of small packets. You can verify that this is the case by reading the fine print in the specifications of your firewall. It is probably rated at an impressive number of gigabytes per second but if you look at the number of packets, it is not that high. And even if you have a firewall capable of millions of packets per second it will not do you much good as it is not doing much inspection of the DNS traffic. Traditional firewalls are not smart enough and do not look far enough into the packet to really be able to determine if the packet is legit or not.

What is really needed for adequate protection is a specialized DNS firewall that sits outside of the firewall. This device can either be configured with the DNS data so that it can respond directly or simply forward the scrubbed traffic to “softer” DNS servers behind it.

Secure64’s products can be used in such a setup. Our products defend against Denial of Service attacks and other types of attacks directed towards the DNS servers while we are still able to respond to legitimate traffic. For more information on our products please visit us at our web site.