[dns-operations] summary of recent vulnerabilities in DNS security.
vjs at rhyolite.com
Tue Oct 22 15:09:33 UTC 2013
> From: Daniel Kalchev <daniel at digsys.bg>
> >> Have you turned on DNSSEC where you can? If not, why not?
> When one claims "DNSSEC is difficult", while other claim it is not, then
> something is wrong. Answering questions like there might help find out
> where the wrong comes from and eventually fix it.
I think the claim was more "dangerous" than "difficult":
} It's a complicated story to tell and it doesn't make for clear
} straightforward advice; for the forseeable future deploying DNSSEC on
} the auth side makes you more vulnerable, as there are still more ...
> See, I can answer such questions. Why can't others?
The signing half of the answer is often public with `dig +dnssec`.
The verifying half is hard to see, but almost or soon guessable as
"yes" thanks to big resolvers and default-on verifying in software
> As for port randomization, etc -- these things will obviously happen.
> But the number of people that need to get involved is very small. These
> people know already what to do and will do it. On the other hand, the
> number of people needed to get involved with proper DNSSEC
> implementation is pretty large -- and this is where we should put our
I hope that a big reason DNSSEC signing is rare
is obstruction by registrars. That might change next year.
My main complaint about the port randomization talk and its refusal
to address the DNSSEC relative priority issue is that it gives those
who should DNSSEC sign an excuse to say
DNSSEC is difficult, dangerous, and unneeded. Port randomization
solves the DNS security problem and I needn't do anything but
wait for new software in a few years.
Vernon Schryver vjs at rhyolite.com
P.S. Checking SMTP headers for STARTTLS often illuminates even
better than `dig +dnssec`. I'm amused by authoritative sounding
security talk that lacks the minimal, easy protection of STARTTLS.
More information about the dns-operations