Interesting new dns failures

Wed May 23 03:53:27 UTC 2007

On Tue, 22 May 2007, David Ulevitch wrote:

>
> Fergie wrote:
>
> > David,
> >
> > As you (and some others) may be aware, that's an approach that we
> > (Trend Micro) took a while back, but we got a lot (that's an
> > understatement) of push-back from service providers, specifically,
> > because they're not very inclined to change out their infrastructure
> > (in this case, their recursive DNS) for something that could identify
> > these types of behaviors.

also sometimes assumptions were made about userbase/usages/deployments...
but the larger issue I think is below.

>
> Was that the real reason?
>
> Here's a crazy question... Did it by chance cost money? :-)

I think the reason I gave was that at certain places in the recursive dns
world this sort of thing is 'hard' mostly because you can't easily scope
the userbase and their requirements.

To use an example: 198.6.1.1 is in all manner of documentation (from
vendors, wee!) and other places (Rodney says the same happend with 4.2.2.1
& 4.2.2.2). All manner of oddball people (and customers. wee!) use this
'service'. Their intents and usages are mostly unknown (aside from 'where
is www.google.com today?').

On the other hand, look at the recursive resolver that lives inside YOUR
enterprise network (or your managed customer's network, perhaps managed by
you). This has a closed community with clear policy and procedures, and
clear reporting chain for figuring out 'problems'.

In the first cast applying some magical DNS solution is bound to cause
many and varied problems with out any real hope of finding a fix (aside
from, hey go use rodney's 4.2.2.1 box). In the second set of cases if your
mail-admins have problems they can be told: 'like it or lump it, policy
says "blah"' or 'hey, maybe you should use your own recursive resolvers?'

Fixing this problem (is it a problem? that's still tbd...) at the 'core'
is much more difficult than at the enterprise/edge. Services may/will
arise that offer 'edge' folks a way to implement 'security policy' ('no
one can view gadi.com or *.cn or whatever your policy is) in a sane and
reliable fashion not just in 'firewall' or 'access-list' places. Offering
more than one option for security policy enforcement (layered options)
seems like a very reasonable thing, to me atleast.

>
> How do operators decide the expense is worth it to mitigate spew coming
> out of their network?

there are a myriad of reasons, some related to how much sleep people want
to lose, some related to 'who pays', some related to 'would my management
yell at me about this?' I think in the case being discussed there's a
right place and a wrong place to do the function, some of the tools for
implementing this at the 'right' place don't quite exist in a digestable
fashion. (yet)

-Chris