[96718] in North American Network Operators' Group
Re: Interesting new dns failures
daemon@ATHENA.MIT.EDU (David Ulevitch)
Tue May 22 16:43:06 2007
Date: Tue, 22 May 2007 13:42:45 -0700
From: David Ulevitch <davidu@everydns.net>
To: Gadi Evron <ge@linuxbox.org>
Cc: "Chris L. Morrow" <christopher.morrow@verizonbusiness.com>,
nanog@merit.edu
In-Reply-To: <Pine.LNX.4.21.0705211549260.18599-100000@linuxbox.org>
Errors-To: owner-nanog@merit.edu
Gadi Evron wrote:
> On Mon, 21 May 2007, Chris L. Morrow wrote:
>> ok, so 'today' you can't think of a reason (nor can I really easily) but
>> it's not clear that this may remain the case tomorrow. It's possible that
>> as a way to 'better loadshare' traffic akamai (just to make an example)
>> could start doing this as well.
>>
>> So, I think that what we (security folks) want is probably not to
>> auto-squish domains in the TLD because of NS's moving about at some rate
>> other than 'normal' but to be able to ask for a quick takedown of said
>> domain, yes? I don't think we'll be able to reduce false positive rates
>> low enough to be acceptable with an 'auto-squish' method :(
>
> Auto-squish on a registrar level is actually starting to work, but there
> is a long way yet..
>
> As to NS fastflux, I think you are right. But it may also be an issue of
> policy. Is there a reason today to allow any domain to change NSs
> constantly?
Why are people trying to solve these problems in the core?
These issues need to and must be solved at the edge. In this case the
edge can be on customer networks, customer resolvers, or at the
registrar. It's dangerous to fix problems at the core where visibility
is limited and data is moving quickly.
These issues should not be "solved" by the registry operators or root
server operators, that's very dangerous.
There are, of course, exceptions where it's helpful when a registry
operator steps in to help mitigate a serious Internet disturbance, but
that's the exception and should not be the rule.
People are suggesting it become the rule because nobody is trying
anything else.
-David Ulevitch
