Re: Detailed implementation question

[Olafur Gudmundsson <ogud@ogud.com>]

On Wed, 10 Apr 2002, Olaf M. Kolkman wrote:

>
> We are trying to spec a resolver that can do verification.
> The assumption is that the resolver speaks to a DNSSEC aware cache.
>
> The resolver will ask the cache all it's questions with the CD on. And we
> rely on the cache not having expired or bad data in it's cache.

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 ?

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

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.
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).

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.


>
> --Olaf and Miek trying to do a resolver in perl.
>

Olafur (answering e-mail instead of writing code)