Re: Fwd: I-D ACTION:draft-ietf-dnsext-delegation-signer-00.txt

[Olafur Gudmundsson <ogud@ogud.com>]

At 01:42 PM 5/31/2001, Havard Eidnes wrote:
> > Just in case anyone did not see this one, here are my .02 SKR
> > solution to the problem of keysets at apex.  Please read and
> > comment as I would like do figure out real soon if this is
> > better or worse than Sigs at parent.  If there is no consensus
> > on either this or Sigs at parent then sigs at child wins.
>
>Hm, what I dislike about this (if I have understood it correctly,
>that is) is that it is one more proposal which goes against the
>current lookup mechanism in relation to delegation points.

You can also put it as "one more proposal trying to overcome a
design flaw in RF103[45]"



>My understanding of the current (non-DNSSEC-perturbed) rules is that
>data at a zone cut stored by and provided by the parent is non-
>authoritative glue, and that ideally the glue data should be
>identically (meaning "name, class, type and data", not necessarily
>TTL) replicated in (and consistent with) the child zone.

This is the flaw in DNS design that makes DNSSEC real hard.


>As you observe, there is currently a large number of delegation
>points where this consistency rule is not adhered to.  The actual
>current operational minimal requirement is that there must be an
>overlap of at least one operational name server from the parent NS
>set and the child NS set for a tree traversal and name lookup to
>work, so the actual consistency demand is fairly lax (no, I would not
>recommend such a setup to anyone).  Furthermore, the current rules
>say that the authoritative data (from the child) overrides any glue
>provided by the parent.


For that reason I say DK can ONLY appear in parent, no confusion.



>Thus, creating a model where you store authoritative data only in
>the parent *at the zone cut label* creates a special lookup rule
>which says "if you want to look up the DK record, you need to visit
>the parent name server", while for all the other record types you
>need to visit one of the child name servers (the pre-DNSSEC
>"authoritative" name servers).

yes it does but DNSSEC resolvers have to do this already for NULL Keys
and NXT records.



>You say that a caching name server doesn't care whether the record
>comes from the parent or the child.  That is most probably in-
>accurate, as the caching name server needs to know where to look it
>up.  The DK record may be provided by the parent (in the additional
>section?) on the first traversal of the tree, but differing TTLs for
>DK and NS record sets (possibly by mixing in the NS record set from
>the child) may cause the DK record set to time out before the NS
>record set, so on a later attempt at using the DK rrset, the caching
>name server needs to know who it should ask.

You are correct.


>Not only is the introduction of such an in-orthogonality cause
>additional complexity for the implementors, I think that the major
>objection is the sort of confusion this is going to create among
>users of the DNS.


I personally think this is simpler than what we have currently or I would
not have written this draft. If you work through what secure resolver needs
to do to make sure it has the correct answer in all cases this is not
more complex.
Also if we take "Sig in Parent" to its logical conclusion then it is
possible to argue that KEY should ONLY reside in the parent.

         Olafur
PS: this discussion should really be taking place on namedroppers.