Re: Detailed implementation question

[Ólafur Guðmundsson <ogud@ogud.com>]

At 04:30 AM 4/11/2002, Olaf M. Kolkman wrote:
>On Wed, 10 Apr 2002 11:52:25 -0400 (EDT)
>Olafur Gudmundsson <ogud@ogud.com> wrote:
>
>
> > 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.

I was not clear, and this is not a problem introduced by DS but by RFC3008
(signing authority)
bert.example is a signed zone
at
foo.bert.example are following records
         DS id=334 ....
         SIG DS  by bert.example.
         KEY id=334 ....
         KEY id=9999 .....
         SIG KEY by foo.bert.example id=334
         <other RR types but not SOA or NS)

Now the question is does a resolver trust that the authoritative server
does not put DS at non delegation points, or does it check?

A paranoid resolver would check but that increases the number of signatures by
at least one and may require extra round trip to authoritative server to
verify neither NS or SOA exists at this point ?

If the resolver trusts the DS blindly w/o checking then
foo.bert.example is now the signature authority the NXT for foo.bert.example
must be signed by it, and foo can sign any names below bert but there is not
a NXT chain it can maintain only a part of one.

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

yes.


         Olafur