The recent DDoS circus against Spamhaus and then CloudFlare was mostly executed by using open recursive DNS servers as traffic amplifiers. The Open Resolver Project has a list of IPv4 addresses they believe can be abused in that way to name and shame the offenders.

It appears that several are on Linode's network (e.g.). Have you thought about hunting down the offenders and... educating them about

allow-recursion { localhost; };

in BIND?

_________________
Lucas Bergman
Google Talk/Mail: lucas@bergmans.us

This is abuse@linode.com material - I'll forward it along to them.

Thanks,
-Chris

I'll bet there are people who in all innocence don't know that their DNS servers should not offer recursive resolution to the world. Using recursive DNS servers to amplify DDOS attacks isn't something that a lot of DNS server admins would know about or expect.


Linode - How about scanning your netblocks for recursive DNS servers?

It's not just recursive. The 'ANY' request can also generate much bigger response than request. Granted, probably not two orders of magnitude greater like the recursive one, but still. Esp. if the requested domain has lots of subdomains, DKIM, ...

Unlike recursive, which is just a matter of a simple config entry, AFAIK blocking ANY requests in Bind can only be done at the firewall level, so it's not something a simple perusal of the config file and docs would mention.

First shutdown the recursive servers that offer service to the whole Internet, then worry about ANY queries.

It should be easy enough to hack bind so it just drops these queries. What's the legitimate use of ANY queries anyway?

I see some clients that do ANY queries for my nameservers' hostnames to save themselves the trouble of doing separate AAAA and A queries. I don't know what the result of dropping those queries would be, but it might not be good.

Edit: By the way, I looked up two of the Linode /24s I'm on in the Open Recursive Project. One didn't have any results, the other had 9. Of them, 3-4 were real open resolvers; the others were apparently authoritative servers that unhelpfully returned . NS in response to strange queries.

Edit: Also by the way, SoftLayer/The Planet, where Linode colos in Dallas, is one of the top ASNs for open resolvers. Linode is a -- presumably small -- part of that.

_________________
Matt Nordhoff (aka Peng on IRC)

That in itself seems like a potentially flawed solution. One fundamental problem with that is that if you send an ANY query to a caching server it can just answer with whatever it has in its cache for the requested name (eg just AAAA even though there is an A record in the actual zone, just not in the cache).
With that in mind I really don't see ANY as particularly useful in reality.

I was referring to my authoritative servers. People who misuse recursive servers as authoritative deserve what they get.


We live in reality, and it's being used. Edit: Whether or not these clients are being smart is not the point. Whether or not it's worth risking breaking them is.

_________________
Matt Nordhoff (aka Peng on IRC)

I've been running a couple of authoritative nameservers for months and the only requests for ANY came from what appeared to be DNS amplification attacks against some chinese IPs. I've been filtering them at the firewall level for months and never saw any service impaired or a client complaining.

Then again perhaps the right thing to do is to ratelimit, so you allow ANY but not in a way that could be used as an attack.

I've been running authoritative DNS servers for ages, first with djbdns and now with BIND 9, and I haven't seen much recent traffic for ANY queries other than something that looked like a brain-damaged penetration brute-force.

Still, I'd feel better if I were rate limiting. Is the state of the art for that still "download some stale patch file and build BIND from source?"

_________________
Lucas Bergman
Google Talk/Mail: lucas@bergmans.us

I've seen some ANY request madness but no serious amounts of traffic.

You can rate limit with iptables, there is no need to hack bind for that. It looks easy enough to use the hashlimit module to block access to a /24 for a short time if it sends you too many queries in a short time. This will have costs in kernel memory and will possibly block misbehaving but still valid queries. I've never had to do it.