[dns-operations] DNS deluge for x.p.ctrc.cc

[Roland Dobbins]

They're both problems of scale; the main difference being there're  
some more 'centralized', if you will, ways of classifying and  
blocking the open recursers.

Whether or not this is iatrogenic in nature and produces the  
unintended consequences to which you allude, and the relative  
severity and tractability of same, are the questions which must be  
weighed.

The active scanning is being done (that's what Dan Kaminsky and Mike  
Schiffman have been doing), it's somewhat time-consuming (can be  
horizonatally scaled), but not rocket science.


On Feb 27, 2006, at 2:43 PM, Joe Greco wrote:

>> On Feb 27, 2006, at 2:15 PM, Joe Greco wrote:
>>> If shunning would be effective, wouldn't it make more sense to shun
>>> networks that don't implement BCP38?  We could fix a wide *range* of
>>> future attack vectors, rather than just this relatively small single
>>> vector that doesn't even address all of the ways to abuse DNS for  
>>> this
>>> sort of thing.
>>
>> i agree that "fixing" via filtering would solve many problems at
>> once, and would fix this particular issue with amplification but as
>> paul noted (and this has been my and many others' experience as well)
>> getting providers (or enterprise networks, in my own experience) to
>> *do* it is very, very hard.  they don't have financial incentive to
>> do so and sometimes negative financial incentive (no staff or
>> expertise to deal with it).
>>
>> as rodney/rob pointed out, working from the other end with the
>> providers that have open/recursive servers that are used in
>> amplification attacks (and therefore impacting them financially)
>> yields fairly good results.
>>
>> i don't disagree with much of what you've said, but aside from the
>> more difficult problem of getting bcp38 implemented, you're not
>> proposing a workable solution either.
>
> How do we know that one problem is "more difficult" than another?
>
> Why is shunning going to work to implement one solution but not  
> another?
>
> What happens if you start shunning networks who haven't implemented  
> BCP38?
>
> After all, if you're willing to take the collateral damage  
> associated with
> shunning open recursers, why not just go right for the jugular and  
> just
> start shunning anyone on a network without BCP38?
>
> Why bother trying to piddle around with one little problem that'll be
> replaced with another technique in *MINUTES*?  I came up with another
> one that was much more exciting in less than 30 seconds of thought,  
> some
> folks here will have seen the e-mail.
>
> Open recursers are a problem in an environment lacking BCP38.
>
> But many things are a problem in an environment lacking BCP38.
>
> Removing open recursers from a non-BCP38 environment fixes one attack
> vector, but also breaks useful things.
>
> Having a BCP38 environment fixes many attack vectors, and breaks  
> nothing.
>
> So.  Does it make more sense to fix the open recursers or fix the  
> BCP38
> situation?
>
> I am just amazed that any significant number of clueful people would
> think that it is easier to fix a ton of open recursers...  these  
> things
> are hiding all around the globe, unknown, unloved, in closets and  
> attics,
> big and little, Linux boxes deployed by that geek college student  
> we had
> one summer back in 2000.
>
> Let me make a prediction.  It's one that I hate to make.
>
> UltraDNS starts shunning open recursers.  Instantly, 100,000 recursers
> around the globe stop resolving 20% of the Internet.
>
> What happens next?
>
> It's not what you think.
>
> You have to remember that there's a ton of Internet stuff out there  
> that
> was set up and has been left to run.  The people who set it up have  
> long
> ago moved on, but stuff kept churning, and of course momentum being  
> what
> it is, it kept getting used.
>
> So one day, ABC Co. finds that they can't resolve 20% of the Internet.
> So they call up XYZ Internet, and say "what the futz."  XYZ does the
> normal and has them examine settings, and they see that the nameserver
> isn't the XYZ blessed nameserver.  So XYZ tech support has them change
> it to the XYZ blessed nameservers.  ABC Co. can now resolve the  
> Internet.
>
> But that old open recurser is still there.  Still recursing.
>
> Repeat 49,999 times.
>
> Don't bother trying to tell me it's unlikely.  I've seen too many such
> setups.
>
> So, let me be very clear:  this is a losing battle, unless you're  
> willing
> to get the cooperation of ISP's, probably do active scanning, or do  
> other
> really intrusive things, it's not very realistic to think that you can
> eliminate this problem.  If you can really get the cooperation of  
> ISP's,
> etc., then you're better off doing BCP38...
>
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http:// 
> www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance  
> [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e- 
> mail spam(CNN)
> With 24 million small businesses in the US alone, that's way too  
> many apples.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations

----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // 408.527.6376 voice

      Everything has been said.  But nobody listens.

                    -- Roger Shattuck