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

[Havard Eidnes <he@runit.no>]

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

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.

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.

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

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.

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.

Regards,

- Håvard