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

[Daniel Kalchev]

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.

Daniel