Yes. There is an attack based on DNS queries with forged source
addresses.

The idea is based on the existence of large botnets. The largest known
on this side of the Internet was about 2.5 or more million hosts (I
forget the actual number, might have been higher), but it self-
destructed (or anyway fell apart) not long ago. But there are still a
few botnets around with membership ranging in the 1/2 million range.

Now remember that most ISP's do not block forged source addresses. (If
they did, the recent cache poisoning announcements would be much less
dreadful.) And if a server gets a query for a large RRSet, it may very
well return a large RRSet to the apparent (and possibly forged) source
address of the query.

Now put it all together: A small botnet botnet (5 thousand members),
or a small portion of a larger botnet, starts targeting a large number
of open DNS resolvers (100 each) around the world, all using the same
forged source address and the same query. Suppose the query packet is
40 bytes, but the response is 500. Now suppose the queries are sent
once per second.

The members of the botnet generate 4000 bytes per second of outbound
traffic. Not much. It might be noticeable on a modem connection, but
the network will still work. (Modem connections could be special-cased
to send fewer packets, but let's ignore that for the moment.) The open
DNS servers each see a small number of identical queries per second,
all coming from the same host. Odd, but not likely to be noticed. The
real target, whose address was used as the forged source address, sees
5 thousand bots x 500 bytes x 100 open resolvers per bot per second =
250 million bytes per second = 2 Gb/s.

Real attacks in the wild have been clocked at 2-4 Gb/s, sustained for
quite a long time. This is a basic DDOS attack, using DNS as an
amplifier.

Chris Buxton
Professional Services
Men & Mice

On Jul 25, 2008, at 10:59 PM, Skeeve Stevens wrote:

> Thanks for that, and my problem is now solved - I found the example @
> http://support.menandmice.com/jforum/posts/list/25.page
>
> I understand what the issue was now and yes, I was relying on the old
> default.
>
> Thing is, while I understand that running an open query DNS server
> is not an
> ideal situation, I am not sure (assuming you are prepared to deal
> with the
> bandwidth) what the actual problem is.
>
> I understand the issue of the current security breach and the
> poisoning
> attack against certain implementations of the DNS daemon, but
> assuming you
> are running the latest safest version, is there anything actually
> wrong with
> running an open DNS server?
>
> ...Skeeve
>
>
>
> -----Original Message-----
> From: Chris Buxton [mailto:cbuxton@menandmice.com]
> Sent: Saturday, 26 July 2008 3:37 PM
> To: skeeve@skeeve.org
> Cc: comp-protocols-dns-bind@isc.org
> Subject: Re: Basic Question re Security issue
>
> What version of BIND did you upgrade from? If it was BIND 9.3.x or
> earlier, then I think you have not created an allow-recursion
> statement - you've been relying on the default of:
>
> options {
> allow-recursion { any; };
> };
>
> The new default is:
>
> options {
> allow-recursion { localhost; localnets; };
> };
>
> You probably just need to open that back up somewhat. Please do not
> return your config to using an allow-recursion ACL of { any; }. Keep
> it as limited as you can while allowing those you must allow.
>
> Chris Buxton
> Professional Services
> Men & Mice
>
> On Jul 25, 2008, at 7:27 PM, Skeeve Stevens wrote:
>
>> OK, I upgraded to the latest binds (tried latest 9.4 and 9.5) and the
>> compatibility with my current 9.4 config file seemed fine, except
>> recursion
>> broke.
>>
>> So.. for a quick explanation here.
>>
>> After we have the latest safe code, what config changes should we be
>> making
>> for everything to be ok?
>>
>> .Skeeve
>>
>> --
>> Skeeve Stevens, RHCE
>> skeeve@skeeve.org / www.skeeve.org
>> Cell +61 (0)414 753 383 / skype://skeeve
>>
>> eintellego - skeeve@eintellego.net - www.eintellego.net
>> --
>> I'm a groove licked love child king of the verse
>> Si vis pacem, para bellum
>>
>>
>>
>>
>>

>
>