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

[Florian Weimer]

* 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.