Interesting new dns failures

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
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

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? :slight_smile:

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? :slight_smile:

-David

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? :slight_smile:

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