[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver
Mark_Andrews at isc.org
Tue May 27 23:03:53 UTC 2008
> * 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
"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.
> dns-operations mailing list
> dns-operations at lists.oarci.net
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the dns-operations