Thwarting the isc.org DNS DDoS

Yesterday I posted an article regarding the importance of ACLs in BIND because a client's DNS server was under extreme load and, at the time, I believed it was because a network of web form spammers was outsourcing their lookups to the target. Upon further investigation it turned out that this was not the case - the hosts were indeed a part of some sort of spamming ring/botnet but they were actually performing endless repeated ANY lookups on isc.org - the producers of BIND, among other things.

The whole attack doesn't make any sense; if they wanted to involve this server in the attack against isc they would be wasting reams of bandwidth that could otherwise have been applied directly, unless they knew both recursive lookups were allowed and caching was disabled. Even with no recursive ACL at the time the only server suffering was my client's thanks to caching and there is no conceivable reason, in my mind, that a spam network would be targeting this specific dns server among many in its address space - from one source address at a time. Fortunately adding a recursive ACL reduced the bandwidth impact but it did not stop the scans, and bandwidth is a pricey commodity after all.

I whipped out wireshark and took a sample capture, these are the contents of a typical request packet:

0000  00 16 3e bb 00 02 00 16  3e cc 00 02 08 00 45 00   ..>..... >.....E.
0010  00 40 8b 0d 00 00 e9 11  d7 93 d1 0b f2 7b 00 00   [email protected] .....{..
0020  00 00 63 01 00 35 00 2c  00 00 2a 39 01 00 00 01   ..c..5., ..*9....
0030  00 00 00 00 00 01 03 69  73 63 03 6f 72 67 00 00   .......i sc.org..
0040  ff 00 01 00 00 29 10 00  00 00 80 00 00 00         .....).. ......

Next it was just a matter of crafting a suitable snort rule for the upstream gateway:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS isc.org DDoS"; content:"|03 69 73 63 03 6f 72 67 00|"; reference:foxpa.ws,369; classtype:attempted-dos; sid:4000002; rev:1; fwsam: src, 1 day;)

Now I'm kicking back, watching the spammer network expose itself as its constituent hosts smack against the firewall like bugs against a windshield.

If only I had some beer.

See how this story progressed:


• moosie

I'm seeing the same activity on my host. I agree it's DNS amplification, with spoofed source ips as the actual targets. I shut it down with the following iptables rule:

#$IPT -A MY_INPUT -p udp --dport 53 -m string --algo bm --hex-string "isc|03|org" -j LOG --log-prefix 'ATTACK '

$IPT -A MY_INPUT -p udp --dport 53 -m string --algo bm --hex-string "isc|03|org" -j DROP

The result is, I am no longer part of the problem, sending even "REFUSED" responses back to the spoofed source. (I've always had recursion turned off, so I was never returning the large isc.org response).

Obviously this relies on the attacker using isc.org for the payload. They do seem to be consistent with this aspect of the attack. Large response, full of DNSKEYs and RRSIGs. Also, perhaps admins will be less likely to blacklist isc.org? And I wonder if there's just a little intentional irony, using the security features (large keys) of isc.org's own response to deliver an attack.

If the attack were to morph to various payload generators, not just isc.org, I might look at using iptables 'recent' module, as described here:


I have the same situation on my server. Does anybody knows how can I limit the number of DNS requests per second in BIND?


It's not taking part, it's being targetted.

The sending address is spoofed. This is an ARP amplification attack using your server as the amplifier. You are not the actual victim, you're collateral damage.


Can any body explain why i have a Googlebot IP taking part, see below :

client query (cache) 'isc.org/ANY/IN' denied: 3 Time(s)
client query (cache) 'isc.org/ANY/IN' denied: 1 Time(s)
client query (cache) 'isc.org/ANY/IN' denied: 1 Time(s)
client query (cache) 'isc.org/ANY/IN' denied: 1 Time(s) <------- Google IP
client query (cache) 'isc.org/ANY/IN' denied: 1 Time(s)
client query (cache) 'isc.org/ANY/IN' denied: 3 Time(s)
client query (cache) 'isc.org/ANY/IN' denied: 7 Time(s)
client query (cache) 'isc.org/ANY/IN' denied: 2 Time(s

• Chris

Note that this attack is not 'new' (in any sense of that word) the particulars of dns-reflective attacks have been well documented and the actual attacks have been seen in the wild since before 2000.

The particular set of folks using ISC.org ANY (and icann.org and a few others) though is about a year on now.


Please see foxpa.ws/2011/01/03/isc-org-drdos-update-2-problems-with-nl-netherlands-tld/

By modifying the netfilter rule I reference in the first line to use the source port of the attacks you can efficiently block these packets without dropping .nl DNS responses.


You are correct, I have been in touch with ISC recently and it seems they are taking advantage of isc.org's long response in particular because it is DNSSEC signed and this apparently adds some beef to the payload.

• Alex

I can tell you what this is, IT is a DNS amplified attack, they are not attacking isc.org, but sending requests that have the source address in the IP headers spoofed to that of their victim, in turn this generates hugely amplified DDoS attacks to the target! this needs to be stopped!

• rntk

Hi there,

I'm being hit by this same problem and googled and found your post here.

I believe they're not trying to DDoS isc.org - I'm thinking everytime an IP makes a request to your DNS server, it's expecting an answer. Maybe the IP that's requesting the isc.org in question was spoofed and that is the target of the attack?

I think that version would make more sense, however I am not any expert in networking and thus do not know if the amount of response (let's say) 60000 DNS servers sending back to one host about "request isc.org denied" in a short time window would constitute as DDoS or not (and I don't even know if that would be the case)

Would love to know your PoV on this. It's driving me mad as well (thanks for the snort rule)


Whether it is an attempted DoS against isc.org or not I really can't tell, but I can tell that the traffic they are generating was denying service to my client's name server. You're quite right in that the queries could have been spoofed, being UDP, and this would mean that the attackers were trying to use my clients' servers for a bulk-traffic Distributed Redirected Denial of Service. What leads me to believe otherwise is the footprint of the source IPs, that is to say the open ports and network stacks, changed yet at the same time most of them were somehow implemented in spamming activities. Either this is a strange statistical coincidence of randomly drawn spoof IPs or we could be looking at a war between spammers.