In message <1278014471.22848.6352.ca...@shane-asus-laptop>, Shane Kerr writes:
> 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 ch
> ild zone.
> > > It's very simple for signing software (including off-line signers) to gen
> erate the "CDS" RRset.
> > > Since there are many more child zones than parent zones, this seems signi
> ficant.
> > 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 examp
> le).
> > I don't think it's more or less complex than including a record inside of t
> he
> > zone. This however is a decision we as those who are writing the drafts sho
> uld
> > 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.
So what's so hard about:
nsupdate
key isc.org <secret>
update delete isc.org DS
update add isc.org 86400 DS ...
update add isc.org 86400 DS ...
send
to update the DS's?
nsupdate
key isc.org <secret>
zone org
update delete isc.org NS
update add isc.org 86400 NS ...
update add isc.org 86400 NS ...
send
to update the NS's?
It scales. It is secure. It works with any type. It does not
depend apon DNSSEC so it works for everyone now.
If one wants to send updates to a seperate server one can and that
can feed into the EPP system so one doesn't have to change the
existing nameservers configurations. Sending to other servers can
be formalised by using SRV so it can be auto discovered. The update
server would have access to the EPP database for TSIGs.
nsupdate
server <updateserver> [<port>]
key isc.org <secret>
zone org
update delete isc.org NS
update add isc.org 86400 NS ...
update add isc.org 86400 NS ...
send
Mark
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
