[dns-operations] summary of recent vulnerabilities in DNS security.

[Colm MacCárthaigh]

On Mon, Oct 21, 2013 at 11:32 AM, Vernon Schryver <vjs at rhyolite.com> wrote:
>> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm at stdlib.net>
>> Economics also include costs. The operational cost of deploying DNSSEC
>> validation on resolvers remains high - there are still frequent key
>> rotation and signing errors that cause various DNS subtrees to be
>> unresolvable.
>
> On what do you base your claims about the fatal costs of DNSSEC
> validation?

I wrote that the costs are high, not fatal. http://dns.comcast.net/
serves as a reasonable, though not complete, public example list of
issues. http://dns.comcast.net/ serves as a reasonable, though not
complete, example list of real issues.

>> If an attacker can cause the domain to be unresolvable, that seems
>> like a weakness.
>
> True, but the right question is not "Does DNSSEC add vulnerabilities?"
> but "Overall, is DNS more or less secure with DNSSEC?" or "Among all
> of the things I can do, what will improve the security of my users and
> the Internet in general?"

This thread concerns the vulnerabilities uncovered in the fragment
attacks. One of those vulnerabilities is that domains can be rendered
unresolvable; even when DNSSEC is enabled. That seems like something
to take seriously.

>> Kaminsky wasn't the discoverer of the "Kaminsky's bug" either, it was
>> long known, yet here you credit him. Not that I mean to deny credit to
>> Kaminsky, he did a good job of publicising the vulnerability. Just as
>> Haya has done here.
>
> I suspect Kaminsky got the credit because he had been contributing to
> the field for years.  But who cares who got there first?

Evidently Paul Vixie does. That's what I was responding to.

> Let's agree that ports ought to be as random as TCP ISNs, improve port
> randomness where each of us can, and stop implying that anyone thinks
> or says otherwise.

O.k., but what about fragmentation point randomisation, or randomized
DNS payload padding?

-- 
Colm