Re: Detailed implementation question

["Olaf M. Kolkman" <olaf@ripe.net>]

On Wed, 10 Apr 2002 11:52:25 -0400 (EDT)
Olafur Gudmundsson <ogud@ogud.com> wrote:


> So you are writing full function resolver with it's own cache or
> just the ability to keep all RRsets needed for the current set
> of verifications ?

The latter. It tries to obtain all RRs that it needs from the cache.
Writing your own cache is a different ballpark.

> > What seems to be necesary, for proof of insecurity, is that the cache
> > has knowledge about returning the appropriate NXT record at zone
> > splits i.e. if the cache is explicitly asked for a DS record that does
> > not exist and it contains cached data from a zone with a locally
> > secured apex that it knows that it is supposed to return the parental
> > NXT.


> DS-07 requries that DS or parent NXT MUST be returned along with
> referral or a NS query. DS-06 required both DS and NXT but that was
> redundant, as DS proves there is a secure delegation, there is no
> need for checking the NXT record.

But a chache will not forward referrals to a resolver. The resolver
will, during negative validation, requests for a DS record from the
cache. We expect (hope) the cache to have the intelligence to return
the NXT record from the parent supplying proof the record is not
there.


> The corner case is there is a DS at NON delegation in an attempt to
> authorize a KEY record at the same name to sign data.
> To prevent this a paranoid resolver should check that either a SOA or
> a NS exists at the name, or look into the bitmap of a NXT record
> at the name.

I am not sure I understand this corner case. Could you give an example
of this situation.

> Do I need to issue clarification text for this in the DS draft?

> >
> > Either this is made explicit in the DS specs (maybe it is and I
> > overlooked it) or the resolver needs to have the intelligence to
> > surpass the cache and ask the parent's server immediatly.
> 
> Yes in many cases the secure resolver MUST ask the parent explicitly
> and not use the regular caching server. This is required when the
> cache does not support DNSSEC, does not know about DS processing,
> or has not done the verification.

Yes, that is what we found as well. I think one still wants to make as
much use of cached data as possible. Although we did not do thourough
research it seems that the case that you have to circumvent the caches
is for data at delegation points. That worries me since it is for
delegation data that caches are important (Who cares that the data for
'bert.secret-wg.org' is cached :-) ).


> If you send a query with AD and DO bits the DNSSEC enabled cache
> should collect all the records needed by the resolver (resulting in
> duplication of crypto work).

I do not see duplication of the crypto as a problem; The cache
verifies, based on it's own policies, what it wants to put in it's
cache. The end user might have a different policy. I think that the
resolver should send it's request with CD and DO so that all records
are forwarded blindly. i.e. either from the cache if they are there or
fetched from the auth. servers directly. 

The AD bit would be set if you want to rely on the Cache's policy.

(Am I making sense ?)

> The resolver may run into the problem that it CAN NOT reach the
> parent server directly, due to DNS query interception or blocking
> by a firewall in this case security proofs may fail due to network
> reasons rather than DNS reasons.


Had not yet thought of that :-(. 


--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi