[dns-operations] security-aware stub resolver
paul at vix.com
Thu May 22 19:31:38 UTC 2008
> 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 .
More information about the dns-operations