> 1) The attacks use spoofed source addresses. This ain't something
> that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged.


the real problem..

> 2) The attacks make use of servers that will answer to arbitrarily
> sourced packets with lots of data. Currently only recursive servers
> can really to this, sooner or later any DNSSEC zone server will
> qualify for this duty.


other applications do this too.

> 3) The attacks make use of something called amplification,
> specifically the ability to send a little message in and get a lot of
> message out.


kind of like http, eh?

> Item 3 is something that can be dealt with within the protocol. And
> this is what my goofy idea addresses.
>
> Potential Solution:
>
> The crux of the goofy idea is that the only way to prevent DNS from
> being an agent of amplification is to make the queries (almost) as
> big as or bigger than the responses. Via padding, of course.


so, we give the bad boys an -EXTRA- communications channel
as an effective deterent?
what could you do with those extra padding bits?

--bill

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: