[Dnssec-deployment] synthesizing DS from DNSKEY in the parent

[Paul Vixie]

> Date: Wed, 4 May 2011 10:51:49 -0400
> From: Edward Lewis <Ed.Lewis at neustar.biz>
> 
> About 5 or so years into this Olafur proposed the DS record.  The
> advantages of it were that it was uniquely from the parent, not at
> both parent/child, and the parent could control the security
> delegation.  The NS set delegates the existence of names to other
> servers, the DS delegates the security parameters to the child's
> settings.

noting in passing, other parts of the dns protocol (UPDATE) already have
to know how to find a zone cut but the implications of this were not
felt in the NS/DS design or else we would have put the DS at a different
node (so, VIX._DNSSEC.COM DS rather than what is today VIX.COM DS) so
that there would be no rule changes about "NS and other data" at the
delegation point.

> Note that the NS parent set does not have to be the same as the NS
> child set.  They should be, but at least in transition, they will
> differ.  DNS, to accomplish its goals, has to accept that this
> situation happens.

i think "should" is too strong here, there's no identity requirement, no
bad thing happens if identity between the sets never occurs.  intersect on
the other hand is a "must" for DS/DNSKEY, and while it's possible to live
without it for NS/NS it's a diagnostic hell when it happens.

> As a zone operator, I wouldn't want any automatic linking of my zone
> to the parent.  And in the vice versa, it wouldn't scale.  This
> auto-linking works against the independence of the DNS and creates a
> bottleneck in the DNS.  Both of these work against scaling.

while we may disagree on this i do not think this is the time to hash out
our reasons for disagreement and i think we agree that assuming a future
where such trust anchor management never happens would be bad design.