Interesting new dns failures

Tue May 22 20:42:45 UTC 2007

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