[Dnssec-deployment] Analysis of NASA.GOV DNSSEC Issue 18-Jan-2012

[Patrik Fältström]

On 28 jan 2012, at 01:15, Andre Grueneberg wrote:

> Livingood, Jason wrote:
>> This is where validation implementers like me need to do some creative
>> thinking (with help from folks here of course). It'll probably take a lot
>> of experimentation to figure out the right way(s) to do so, but this is
>> where the work is I think. And getting it right will prevent a lot of
>> customer calls and upset.
> 
> How about some browser facility to initiate an additional query with CD
> flag set. If this yields a different result: inidicate DNSSEC issue. A
> bit like Certificate validation failures.
> 
> Okay, this opens potential for people to ignore the hard failure in
> recursor validation. [I know, people are used to ignore warnings]
> 
> Anyway, we'd have default: hard failure, optional: more information and
> temporary circumvention if application supports it.

I want to first of all say I am impressed and appreciate all work done by Jason and friends at Comcast.

I am though a bit nervous over the direction this discussion is taking. And the reason is that we know already from the SSL/TLS world that _if_ the user can bypass the warnings and errors presented to them in the case of errors in validation, they will.

I.e. one of the strengths so far has been that the end user can not bypass "by clicking 'yes, continue anyway'".

What I feel you have done at Comcast is to implement a mechanism to be able for skilled parties to evaluate the situation and override the error message. But the end user is not involved. Which I think is a good thing!


Or let me push this a bit further: if people mess up their bgp routing so that the packets can not flow correctly, can the end user click "yes, continue anyway"?

Of course not, so why should they be able to do so when DNS is broken?


Conclusion: I think the ability to "override" errors and problems in DNSSEC is something that should stay "in the network". And never be presented to the end user.


Now, given the PR nightmare and reactions that happened because of the nasa.gov errors, there is of course many lessons to learn for all parties regarding information sharing on what the problems actually where, and that in this case Comcast was not the party to blame. But I see that the same kind of information as if nasa.gov messed up their bgp feed or had problems with their physical infrastructure. Also things Comcast can not do anything about.

   Patrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120128/0294cc2e/attachment.bin