Re: Interesting new dns failures
But very few people (okay, not nobody) are saying, "Hey, why should I allow that compromised windows box that has never sent me an MX request before all of the sudden be able to request 10,000 MX records across my resolvers?" "Why am I resolving a domain name that was just added into
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- David Ulevitch <davidu@everydns.net> wrote: the DNS an hour ago but has already changed NS servers 50 times?"
These questions, and more (but I'm biased to DNS), can be solved at the
edge for those who want them. It's decentralized there. It's done the right way there. It's also doable in a safe and fail-open kind of way.
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. And actually, in the case you mentioned above -- to identify this exact specific behavior. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) wj8DBQFGU2NQq1pz9mNUZTMRAn5EAKCxlJ6uAkM+GMK15oCezkBVXHcBpgCeLuzK Sn4ppcRBy8Nbc5MJU+zYiSE= =+JDX -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
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.
Was that the real reason? Here's a crazy question... Did it by chance cost money? :-) I'm not saying it should have been free just that the hesitation to roll it out *might* have been for factors besides the fact that it mitigated DNS based botnets. How do operators decide the expense is worth it to mitigate spew coming out of their network? When their outbound DoS traffic exceeds their inbound transit ratios? :-) -David
And actually, in the case you mentioned above -- to identify this exact specific behavior.
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
participants (3)
-
Chris L. Morrow -
David Ulevitch -
Fergie