[dns-operations] A Case Against DNSSEC (A Matasano Miniseries)

Rodney Joffe rjoffe at centergate.com
Wed Apr 4 16:21:34 UTC 2007

On Apr 4, 2007, at 9:04 AM, Edward Lewis wrote:

> At 10:45 -0400 4/4/07, Matt Larson wrote:
>> We can all imagine a
>> doomsday scenario that none of us can survive, but that doesn't  
>> excuse
>> a responsible provider from provisioning the hell out their
>> infrastructure to survive the survivable attacks.
> Not everyone can afford to over provision, regardless of how
> responsible they are.  There maybe limits to what's available to over
> provision with.  Sometimes you have to get crafty.
> What makes me say this is a presentation about complexity in protocol
> design in which the presenter summed up the benefits of simplicity by
> saying that "all you need is more bandwidth."  The presenter worked
> for an ISP (selling bandwidth).
> IP technologies work best when there is an abundance of bandwidth.
> But bandwidth requires installation of stuff (fiber, towers) and
> needs power for signal propagation and for server operation.  There's
> a need to be more efficient (work accomplished per unit of energy) as
> we near resource limits.

I'll say this again (and Matt, I am not arguing with you that the  
provisioning of lots of bandwidth and servers is a requirement as  
well), even if you were the gub'mint of the US of A, using the  
current public nature of nameserver architecture, you cannot  
provision sufficiently to withstand an intelligent DDoS. Period. You  
have to change the way you solve the problem. Over-provisioning is  
not the answer.

To put this another way, I can protect 75% of end users in the world  
for my 20 million domains with less than 100 mb of bandwidth and  
fewer than the equivalent of 30 servers. But it needs a philosophical  
change in attitude that the protectors of those users have to make.   
Unfortunately some of them are too arrogant or stupid to make the  
change. So "our" job remains hard.

I'm done with my soapbox, and am headed back into the mine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2425 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20070404/d558102c/attachment.bin>

More information about the dns-operations mailing list