[dns-operations] question for DNS being attacked

[Paul Vixie]

On 6/28/2012 7:50 PM, Michael Graff wrote:
>>> "BCP 38"  Enough said.
>> what does that mean?
> It means that time and time again, either sufficient mass must implement a feature like this, or it is effectively pointless.  It also means that the pain of installing such a security feature is on the side that does not feel the pain.

none of that is true.

first, because every server who refuses to participate reduces the
attack surface. we do not argue that "i should not bother to deploy BCP
38 here because until everyone does it, there is no point." nor do we
are thusly about open SMTP relays, or carbon emission limits, voting in
political elections, or pollution. every little bit DOES help. each of
us should do what little we can do.

second, because reflective amplifiers feel considerable pain. the 20X+
larger responses cost money to transmit, and use link and path headroom.
the phone also rings when victims call in to say "please stop answering
queries i am not sending you." so while i agree with you that BCP 38's
incentives are misaligned, that is demonstrably not the case in DNS RRL.

> But, unlike BCP38 which would make a difference if enough ISPs implemented it, this is another form of an arms race against a well armed opponent.

sometimes the best you can do is require your opponent to become better
armed, and continue the game to the next round. consider four approaches
to this problem:

1. implement per-source-ip rate limits (like f-root and many other
authority servers do.)
2. implement per-pattern filters (like EDNS bufsize==9000 filters as
some are doing now.)
3. implement DNS RRL, which rate limits based on source-ip *and*
prospective response.
4. do nothing for now until a better idea comes to us.

i believe that #3 is the right next step, since the ease of bypass for
#1 and #2 is too trivial, and since #4 is inevitable anyway.

do you have an argument to make in favour of #4?

> That said, the "slip" factor is clever, but I still worry about translating what would be a UDP timeout into a TCP query in addition to a filter that takes only 5 sequential packets to activate.

i'm a tcp/53 hater of some long standing. i resisted TC=1 for this until
nothing else proved out. at this point i'm thinking that if the repeated
queries are somehow coming from a real resolver, that TC=1 no more than
every other request should get them an answer that they can cache which
would then shut them up. and if the repeated queries are coming from a
spoofer, then these will at least be small (non-amplifying) and
infrequent (not sent in response to every request) packet-bombs. and if
there's a mix of both real and spoofed traffic, then the fact that real
resolvers both retry and cache, means that SLIP reduces the attack
surface. (here i'm thinking of kaminsky attacks.)

i apologize to anyone here who believes that there is a silver bullet to
be had. DNS RRL is a tradeoff, useful for risk management. if your risk
of processing and transmitting large flows toward victims who are not
sending you packets, is greater than your risk of dropping responses
toward legitimate resolvers during times they are being attacked, then
you should probably sign your zones with DNSSEC and restart your thought
process. but in any case DNS RRL is not a silver bullet. there is no
silver bullet.

paul