[dns-operations] security-aware stub resolver

[Joe Abley]

We're switching gears from my original question to a different one,  
which is OK because I'm interested in the answer.

On 22 May 2008, at 13:57, Paul Vixie wrote:

> a "security-aware stub resolver" would be a "cacheless validator"  
> and i'm
> sure i wouldn't like its network behaviour.  validation requires  
> access to
> all signatures and keys between an rrset under test and a trust  
> anchor, and
> thus benefits tremendously from a local cache.  adding a local cache  
> to a
> stub resolver that is not otherwise going to traverse zone cuts and  
> will
> therefore not be receiving DS RRsets as a side effect, means a lot  
> ofdelay in
> every validation, and a lot of extra traffic.  the model therefore  
> calls for
> a stub to use TSIG to reach a normal caching validator.  this is  
> what routers
> and browsers should be doing when they need secure DNS.

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 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?


Joe