[dns-operations] security-aware stub resolver

[Paul Vixie]

> We're switching gears from my original question to a different one, which is
> OK because I'm interested in the answer.
> ...
> For an application to be able to give warnings similar to the current "SSL
> certificate is bad, or something" messages that pop up when using HTTPS,
> though, surely some amount of security awareness in the stub is necessary.
> 
> Or is it the consensus that such messages (and other implied security-
> related APIs) are unnecessary for applications?

i think it's important that applications be dnssec aware.  i don't know the
exact signalling used to tell an app that an answer was validated,

> I had assumed that the "DNSSEC deployed" world would involve stub resolvers
> setting RD=1 and DO=1, and validators setting DO=1, and authority-only
> servers serving up security information. You seem to be saying that the
> final utopia in your mind looks different.
> 
> Or do I just need more coffee?

i was only trying to say that stubs should not plan to make enough queries
of their RDNS to validate a signature all the way back to a trust anchor,
nor should stubs have to be configured with trust anchors.  this either
means applications will need caching validators in their own address space,
or that they'll need a TSIG-covered path by which they can request security
from their RDNS and also know, in a response from their RDNS, whether or not
they got security.  details deeper than this belong on namedroppers at .