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

Bill Owens owens at nysernet.org
Sat Jan 28 09:29:34 EST 2012


On Sat, Jan 28, 2012 at 01:15:28AM +0100, 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 think that Jason is looking for a facility to help inform end-users about the cause of the failure they're seeing, which is reasonable. On the other hand, proposing any form of circumvention seems extremely undesirable. 

For one example, imagine the addition of DANE to the mix. In the current world if I were to hijack DNS for a banking site, the user would see a certificate error. Hopefully they would be sufficiently well conditioned that they would not override that warning for their bank. In the DNSSEC+DANE world, with your additional mechanism, they'd first see a DNSSEC error, choose to bypass it because it's some sort of network problem, then see *no* certificate error, because they'd be getting the TLSA record from my hijacked site. I think they'd be much more likely to fall for that.

I also think it is possible to hope that this is a short-term problem, at least for some value of 'short' ;) Zone admins will have to get better at their signing and key rollover procedures, just as network admins have gotten better at their BGP administration (to borrow Patrik's analogy).

Bill.


More information about the Dnssec-deployment mailing list