DNS ANY Request Cannon - Need More Packets

Published: 2012-05-21
Last Updated: 2012-05-21 16:28:47 UTC
by Kevin Shortt (Version: 1)
7 comment(s)
We have a report from our reader Tuukka, who observed a flood of DNS ANY requests from likely spoofed IP addresses.  What we know so far is that it seems to be a DNS Reflective Amplification Attack.  These usually use generic recursive DNS queries trolling for poorly configured DNS services.  This event is different in that the reflection is more targeted.  DNS 'ANY' record queries are only sent for domains for which the server is authoritative for, which the server will of course reply to regardless of available recursion.  These events have been validated by a real time observation by one of our handlers. Here is what we know so far.
Hit List: 
  • Source IP is spoofed
  • Flood lasts up to 60 seconds with 500 queries (as witnessed, but likely could be more)
  • Flood comes from a designated IP and seem to target multiple domains on authoritative server
  • All observed requests are similar thus far
  • This appears to be similar to what others have seen [1]

Example DNS Log Entry:
  • x.x.x.x is the spoofed/target server
  • example.com/ is the "reflecting" DNS server
21-May-2012 13:21:41.757 queries: info: client x.x.x.x#20475: view external: query: example.com IN ANY + (
21-May-2012 13:21:41.897 queries: info: client x.x.x.x#59247: view external: query: example.com IN ANY + (
21-May-2012 13:21:42.054 queries: info: client x.x.x.x#18676: view external: query: example.com IN ANY + (
21-May-2012 13:21:42.059 queries: info: client x.x.x.x#28530: view external: query: example.com IN ANY + (
21-May-2012 13:21:42.193 queries: info: client x.x.x.x#6489: view external: query: example.com IN ANY + (
We are interested in knowing if you have seen this and what you have done to mitigate any ill effects of such events.  Please post a comment to let us know.
We also want your DNS logs and packet capture logs of the events described in this diary.  There is still plenty to learn about this behavior.
If you see outbound ANY query floods from your own network: Try to identify the source machine. It would be interesting to see what tool causes these queries.
ISC Handler on Duty
7 comment(s)


We've been noticing this for the past few weeks. Here's what we're doing against it on our firewalls:
2 IPTables rules on INPUT:

-p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|'
-m recent --set --name dnsanyquery

-p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|'
-m recent --name dnsanyquery --rcheck --seconds 60 --hitcount 5 -j DROP

The first rule looks on UDP 53 for DNS ANY queries (hex 0000FF0001 towards the end of the query) and sets a recent tag for that IP named dnsanyquery

The second rule looks to see if the first rule has been hit more than 4 times in the past minute by a particular IP. If so, drop the packet.

This way, valid ANY queries still work so long as they request fewer than 5 a minute, and the lockout does not affect other queries (A, NS, PTR, MX, etc) so standard traffic will not be affected. This also prevents an attacker from being able to stop others from getting to our nameservers because even if they lock out ANY queries for an IP address, all other normal queries always work fine. Very few things use ANY nowadays for normal lookups.

One interesting side effect of this is that the attacker uses more bandwidth to request the hits than we send back out, so by using us they are actually reducing their total DDoS bandwidth.
I've been seeing this quite a bit. Thanks to network mouse for the iptables recommendations. will give them a try.

Kevin, where do you want me to send a packet capture?

this topic comes up about every 6-8 weeks now... 'known issue', someone in China is upset at someone else in China, they send ~3k packets to your nameserver, for every domain you are authoritative for, you send back replies... go team.
We've been seeing such activity on our DNS servers since the end of March.
We can confirm that most of the targets (i.e. spoofed source addresses) are from the China but we've seen some US IP addresses either.
Also we've been working with Sourcefire on the ways to mitigate this attack. The result is the rule 21817 that is in official rule-base since the middle of April.
By default the rule is disabled, but anyone who runs authoritative DNS servers and uses Snort to protect their assets should consider turning that rule on.
@Network Mouse: thanks for sharing the iptables rule.

I had to tune the iptables rule because our nameserver is very busy. The 'recent' module tracks by default only 100 ip addresses (see man iptables -> recent). For a busy nameserver a time window of 60 seconds may omits some bad guys because the list is too small. So either load the 'recent' kernel module (xt_recent) with a higher default or lower the time window (--seconds). I currently use --seconds 10 --hitcount 5
I've been battling this problem since February on my authoritative name server, had large netblocks in China and some in other parts of the world blocked, eventually, but it was just a temporary solution.
What I've seen is bursts of these queries, about 8-10/second for a set number of time before dropping again, and growing in frequency and number. The IPs may be spoofed but what I noticed was that it's adaptive, it would swap IP very shortly after blocking one in my bogons list. So the query results are fed back into the abusing system. Apart from causing traffic spikes and unneeded traffic, I'm a little at a loss about what the real purpose is behind these attacks.
What I've found out is that as a precursor to floods, there tends to be a few probing requests to see if the name server responds, usually from a limited set of IPs belonging to t-ipnet.de -- I gather this is done through proxies to mask the real source.

What I've done myself is write a reverse DNS proxy in python using dnslib that drops all Qtype=ANY requests coming in from the outside and forwards other query types to the DNS server. Considering there is no reason for any client on the outside to request these records from the server (it's atypical traffic for normal DNS resolution), this should be fine to do. It has slowed the abuse after a few days, and I gather the botnets will eventually realize that their attacks aren't working through the server anymore and whittle down.
We Got these: 11./24.2016 11/18/2016

Diary Archives