Wolfgang,
On Thu, 2010-07-01 at 20:43 +0200, Wolfgang Nagele wrote:
>
> > I think the publication approach is somewhat simpler, at least for the
> > child zone.
> > It's very simple for signing software (including off-line signers) to
> > generate the "CDS" RRset.
> > Since there are many more child zones than parent zones, this seems
> > significant.
> Not sure i can agree with that. The UPDATE the child has to send can be
> performed completely with existing tools ('nsupdate' from BIND as one
> example).
> I don't think it's more or less complex than including a record inside of the
> zone. This however is a decision we as those who are writing the drafts should
> not decide but leave it up to the end-user.
I do think that publishing some new RR in a zone is simpler. In fact, as
a child zone maintainer, I can do it today without any changes to
existing software. So, I like the simplicity of George's draft.
I also like that George's draft only concerns itself with DS data, and
that the child doesn't have to know anything about its parent.
I do think that George's approach only makes sense if some more work is
done fleshing out the actual algorithm the parent uses. For example,
what happens when some of the child name servers disagree? The algorithm
need not be too complex, but the devil is in the details.
And ultimately I do think some sort of NOTIFY-like mechanism would be
cool with George's approach, although clearly not necessary. Key rolling
is less time sensitive than updating an NS RRSET, unless you need an
emergency roll, in which case it's time to contact the administrator of
your parent zone!
--
Shane
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop