[dns-operations] summary of recent vulnerabilities in DNS security.
daniel at digsys.bg
Mon Oct 21 08:13:50 UTC 2013
On 21.10.13 02:52, David Conrad wrote:
> On Oct 20, 2013, at 2:16 PM, Vernon Schryver <vjs at rhyolite.com> wrote:
>> Should the people working on DNS implementations prioritize making
>> their DNSSEC code more robust and easier to use above or below
>> addressing your issues?
> I'd say "below".
> Resolver operators (hopefully) want to protect their caches. DNSSEC will do that, but only if people are signing their zones. There are lots of external parties (e.g., registries, registrars, software developers, resolver operators, etc) to get DNSSEC deployed and there remains very little incentive for anyone to sign their zones, regardless of how robust and easy it might be made.
There is only one thing, that can influence wider deployment of
something on Internet and this is the shame, combined with envy. Making
browsers claim loud and clear "this site is not protected by DNSSEC, you
may be viewing something else, beware!", similar to what (some) browsers
do for SSL certificates can help big time. It also more or less will
drive the validation-closer-to-the-app setups.
Surely, this will "wreak havoc", in having all those parties in the
business hurry to implement DNSSEC or answer uneasy customer questions.
Considering how trivial this feature is to implement, one has to wonder
why it has not happened until now? Perhaps stepping on someone's toes?
By the way, I agree with both you and Vernon, that such research should
prominently state, that the ultimate solution of this kind of bugs is
deploying DNSSEC --- and that it should also mention that deploying
DNSSEC yourself will not automatically cure all known diseases, so you
should put pressure on your peers to do so as well. Setups that clearly
create more vulnerabilities should be exposed as well, including bad
vendor practices and documentation.
More information about the dns-operations