Re: dnssec: resolver - application communication

[David Blacka <davidb@verisignlabs.com>]

On Monday 10 May 2004 3:05 pm, Miek Gieben wrote:

> I fully agree with what you say here, but right now such a cache does
> not exist, hence a application needs to bypass the current available
> cache and it goes out on the Net to talk to the authoritative servers.

I still don't get this.  It seems to me that "such a cache" *does* exist.  Why 
does the app need to bypass the cache?

> (it is possible to _use_ a cache and try to built the chain of trust
> yourself, but this is really an exercise in "programming around the
> cache", and getting the cache to do the right thing)

I think that there is some confusion as to how, exactly, a SASR works.

It is true that a SASR cannot get away with the brain-dead simple mode of 
operation that a non-SASR can.  Instead of one-call->one-query->one-response, 
the SASR must follow the original response with queries for the other data 
that it needs to do the validation (that is, the chain-of-trust information).  
This isn't so bad, because 99 times out of 100, this information will be 
coming from the full resolver's cache, as the full resolver probably just 
cached it.  If the SASR wants to cache the chain of trust itself, more power 
to it.

But the SASR shouldn't even know *how* to bypass the cache.

AFAIK, the way to get the cache to "do the right thing" is CD=1.

> But reading the rest of the thread, and trying to respond here, it
> seems that:
> o SERVFAIL is too overloaded,

Yes.

> o We need something like the CD-bit, that will return an entire chain
>   of trust, which consists of the RR's you specified above: ALL keys,
>   ALL DSs, ALL RRSIGs, and the RRset,

Why?

> o A library/daemon that can handle this,
> o Standarization of the errors in DNSSEC.
> o ....
>

-- 
David Blacka    <davidb@verisignlabs.com> 
Sr. Engineer    VeriSign Applied Research