[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver

[Mark Andrews]

> * David Conrad:
> 
> >> 	You do not get answers that failed to validate.
> >
> > This is, I believe, the problem.  Instead of getting an indication  
> > that validation failed, you get the same response you'd get if someone  
> > unplugged your router.  This will result in support calls which will  
> > result in caching server operators turning off DNSSEC.
> 
> Okay, this makes at least some sense.  However, if there's some standard
> interface to get detailed information about a verification failure, it's
> rather natural for applications to abuse it to implement functionality.
> Which is wrong--it's hard to envision more reasonable semantics for
> validation failures than "drop it" (or "break it"), and to my knowledge,
> this is what has been implemented in all cases where integrity was a
> major design goal (TCP MD5 extension, TLS, SSH).
> 
> I could imagine that for failed validation, the validator sends some
> token to the client, identifying that validation failure.  An
> out-of-band protocol would then allow to retrieve details, using that
> token (possibly in an HTML document served over HTTP).  This has little
> risk of misuse, but could be a useful debugging tool.  On the other
> hand, we've got similar lack of failure transparency in SMTP, even
> within the same administrative domain, and I haven't seen anyone
> implementing something similar (and the same thing could be said about
> legacy DNS).  Maybe there isn't a clear need, after all.  But all
> complexity is a bit scary if there are few debugging tools, I agree.

	So far I've been able to pin point 100% of DNSSEC operational
	failures with "DiG" and "date".  With these two tools you
	can solve most of the potential problems or identify the
	broken component.  I've yet to have to check a individual
	signature.

	"dig +multi-line" gives you the DNSKEY's id, which is visible
	in both the DS and RRSIG records.  The RRSIG records also
	display the time stamps clearly.

	"date -u" provides you with the local machine's concept of
	time that is consistant with the timestamps in the RRSIGs.

	The checks you make a pretty straight forward.  

	Is the local time between the time stamps?
	Is there a key that matches the key id in the RRSIG RRset.
	Is there a key that matches the key id in the DS RRset.
	Is there a key that matches the trust anchor.

	Mark

> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org