Edit: Here is an update on this issue.
This is annoying me:
Jan 19 10:05:26 mars named[7683]: client 76.9.16.171#16831: query (cache) './NS/IN' denied
Jan 19 10:05:26 mars named[7683]: client 76.9.16.171#37015: query (cache) './NS/IN' denied
Jan 19 10:05:28 mars named[7683]: client 76.9.16.171#6305: query (cache) './NS/IN' denied
Jan 19 10:05:30 mars named[7683]: client 76.9.16.171#59885: query (cache) './NS/IN' denied
Jan 19 10:05:32 mars named[7683]: client 76.9.16.171#38058: query (cache) './NS/IN' denied
Jan 19 10:05:34 mars named[7683]: client 76.9.16.171#39938: query (cache) './NS/IN' denied
Jan 19 10:05:34 mars named[7683]: client 76.9.16.171#35368: query (cache) './NS/IN' denied
Jan 19 10:05:35 mars named[7683]: client 69.50.142.110#10926: query (cache) './NS/IN' denied
Jan 19 10:05:36 mars named[7683]: client 76.9.16.171#55447: query (cache) './NS/IN' denied
Jan 19 10:05:38 mars named[7683]: client 76.9.16.171#36178: query (cache) './NS/IN' denied
Jan 19 10:05:40 mars named[7683]: client 76.9.16.171#32167: query (cache) './NS/IN' denied
Jan 19 10:05:42 mars named[7683]: client 76.9.16.171#11388: query (cache) './NS/IN' denied
Jan 19 10:05:43 mars named[7683]: client 76.9.16.171#8499: query (cache) './NS/IN' denied
Jan 19 10:05:44 mars named[7683]: client 69.50.142.110#21075: query (cache) './NS/IN' denied
Jan 19 10:05:44 mars named[7683]: client 76.9.16.171#45496: query (cache) './NS/IN' denied
Jan 19 10:05:46 mars named[7683]: client 76.9.16.171#42345: query (cache) './NS/IN' denied
Jan 19 10:05:48 mars named[7683]: client 76.9.16.171#59733: query (cache) './NS/IN' denied
Jan 19 10:05:50 mars named[7683]: client 76.9.16.171#22861: query (cache) './NS/IN' denied
Jan 19 10:05:52 mars named[7683]: client 76.9.16.171#37870: query (cache) './NS/IN' denied
Jan 19 10:05:52 mars named[7683]: client 76.9.16.171#53284: query (cache) './NS/IN' denied
Jan 19 10:05:26 mars named[7683]: client 76.9.16.171#37015: query (cache) './NS/IN' denied
Jan 19 10:05:28 mars named[7683]: client 76.9.16.171#6305: query (cache) './NS/IN' denied
Jan 19 10:05:30 mars named[7683]: client 76.9.16.171#59885: query (cache) './NS/IN' denied
Jan 19 10:05:32 mars named[7683]: client 76.9.16.171#38058: query (cache) './NS/IN' denied
Jan 19 10:05:34 mars named[7683]: client 76.9.16.171#39938: query (cache) './NS/IN' denied
Jan 19 10:05:34 mars named[7683]: client 76.9.16.171#35368: query (cache) './NS/IN' denied
Jan 19 10:05:35 mars named[7683]: client 69.50.142.110#10926: query (cache) './NS/IN' denied
Jan 19 10:05:36 mars named[7683]: client 76.9.16.171#55447: query (cache) './NS/IN' denied
Jan 19 10:05:38 mars named[7683]: client 76.9.16.171#36178: query (cache) './NS/IN' denied
Jan 19 10:05:40 mars named[7683]: client 76.9.16.171#32167: query (cache) './NS/IN' denied
Jan 19 10:05:42 mars named[7683]: client 76.9.16.171#11388: query (cache) './NS/IN' denied
Jan 19 10:05:43 mars named[7683]: client 76.9.16.171#8499: query (cache) './NS/IN' denied
Jan 19 10:05:44 mars named[7683]: client 69.50.142.110#21075: query (cache) './NS/IN' denied
Jan 19 10:05:44 mars named[7683]: client 76.9.16.171#45496: query (cache) './NS/IN' denied
Jan 19 10:05:46 mars named[7683]: client 76.9.16.171#42345: query (cache) './NS/IN' denied
Jan 19 10:05:48 mars named[7683]: client 76.9.16.171#59733: query (cache) './NS/IN' denied
Jan 19 10:05:50 mars named[7683]: client 76.9.16.171#22861: query (cache) './NS/IN' denied
Jan 19 10:05:52 mars named[7683]: client 76.9.16.171#37870: query (cache) './NS/IN' denied
Jan 19 10:05:52 mars named[7683]: client 76.9.16.171#53284: query (cache) './NS/IN' denied
The problem is, these are generating DNS query refused packets back, helping DDoS some poor bastard.
I need an iptables rule to drop recursive DNS queries. Doesn’t look like iptables does it out of the box, the u32 module might do the trick however.
iptables -A INPUT -p udp --dport 53 -m u32 --u32 "0>>22&0x3C@8>>15&0x01=1" -j DROP
Only problem is I don’t think the u32 module exists by default on lenny. I’ll have to go find it. Though, running that iptables rule doesn’t elicit an error.
Update: Patrik Rak posted a solution that works well.
I’m getting the exact same thing claiming to be from the same IP address on all 4 of my DNS servers. I found your blog by googling for the 76.9.16.171 ip address. These three DNS servers of mine exist on 3 entirely different networks – and all are getting hit with these recursive DNS queries at the same time. I’ve added rules in all three network to drop incoming DNS queries of any kind on UDP port 53 from 76.9.0.0/19 so that my BIND boxes don’t keep clobbering this victim with query refused packets. I doubt this network would have any reason to lookup anything legit from my network – and I’ll drop these rules in a few days of this crap stops! Sure would be nice to know who the luser is sending out these spoofed queries!
Bruce.
I came accross the same two IP ranges while re-installing Bind. At first I through it was me making a configuration error somewhere since they came so frequently.
I now added them to the firewall drop list.
I wonder if there is a way to configure bind to null a refusal reply? Added a rule a little while ago. 76.9.16.171 has been going at it since about 6am pst on my servers. Was curious at exactly what was going on, so I ran tcpdump for a few minutes grep’ing the ip. Glad my acl is working accordingly, but annoyed at the 2 queries per second, as well as the reply.
Cheers,
Vishnu
I’ve wondered the same thing – some way to get BIND to STOP replying to these queries and just drop them. I’m sure doing some would break some part of some RFC. But all of these attacks I’ve been seeing so far, are querying for the root zone “.” – which is not something that normal DNS servers answer to. Most normal clients ask complete host questions, and allow the resolver to do the recursive queries and return with just an answer. So I doubt hacking the source to NOT reply to any off-network, root zone NS queries would not break anything in real life. Anyone know different?
Bruce
You folks might want to think about updating bind, here are some articles to get you going. Seems theres a fair share of it going around.
http://www.uno-code.com/?q=node/160
and Dsheild is tracking it to:
http://www.dshield.org/diary.html?storyid=5713
New versions of BIND don’t fix this problem.
There is no way to disable “recursion denied” responses in bind, currently.
Maybe someone could write some script that tracks a syslog file for these kinds of queries, and drops them using iptables after.. say.. 5 failed attempts?
Give this a try.
Though if you don’t have the particular netfilter module, a script like that would work.
Hi,
why dont you think about fail2ban to do this job for you?
http://www.fail2ban.org/
Cheers.