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