[Dnssec-deployment] synthesizing DS from DNSKEY in the parent
vixie at isc.org
Wed May 4 13:18:27 EDT 2011
> 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
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
> 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.
More information about the Dnssec-deployment