[dns-operations] Another whitepaper on DDOS

[Daniel Kalchev]

Good example. I have argued for quite some time, that one of the DNSSEC primary benefits is to fight misconfigurations. With DNSSEC an misconfigured domain just "fails" instead of continuing to "work somehow".

There are lots of misconfigured domains on the Internet and plenty clueless DNS admins. Those are the primary resistance to widespread adoption of DNSSEC. Unfortunately, most management types who could enforce an DNSSEC-only policy don't know or just don't care. For most "does the web site open in a browser?" is good enough.

Daniel

Sent from my iPad

On 27.02.2013, at 09:08, Edward Lewis <ed.lewis at neustar.biz> wrote:

> 
> On Feb 22, 2013, at 23:18, David Conrad wrote:
>> 
>> Has there been any documented attack that would have been prevented by DNSSEC that one can point to?
> 
> 
> Well, prevented...no, nothing can ever "prevent" an attack.
> 
> But I realized yesterday I should answer yes to the question of whether DNSSEC would have stemmed a cache poisoning attack - with a public reference.  
> 
> http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-1/
> http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-2/
> 
> Here's the weird thing.  I wrote the above article.  I wasn't aware it was publicly visible until about a month ago.  I found it via a web search engine myself.
> 
> Second, the quick story behind this is that this indeed is a cache poisoning attack, but not as described by Dan Kaminsky.  That it was an attack nonetheless didn't occur to me until just this week.
> 
> Third - when I was presented with the problem and I learned a few crucial facts, the thought "gee, I wish there was DNSSEC here' did cross my mind.  Not that the validation was needed, but had the data been signed I would have known where it was coming from.  (You'd have to read the article to understand the context.)
> 
> So, yes, finally I can say I've seen a case that's publicly documented - up to the point of providing anonymity to the victims involved.  (I'm still waiting for the first full disclosure case, but this is what I can offer for now.)
> 
> PS - As many of you know, I do not adhere to "name and shame" policy and take strides to protect identities when I present any sort of case study.  So, the anonymity I hope to be supplying here (I think I've left no breadcrumbs) is not only because it involves a customer but the data being poisoned is not mine nor is the cache being poisoned mine.  I just happened to look into the problem and turned the results over to the others.  Because of this, I realize, it's not possible to "very my claims" and that's a regret I'll take.  So - take this as you will.  And finally - the event happened last summer and was ongoing when I wrote the blog entry in the fall.  I don't know if it is still ongoing, I don't expect to hear back from anyone nor is it really my business to know.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis             
> NeuStar                    You can leave a voice message at +1-571-434-5468
> 
> There are no answers - just tradeoffs, decisions, and responses.
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs