In message <d16b14cccc004d64a6236906c9be9...@local>, "George Barwood" writes: > ----- Original Message ----- > From: "Mark Andrews" <[email protected]> > To: "Shane Kerr" <[email protected]> > Cc: "Wolfgang Nagele" <[email protected]>; <[email protected]> > Sent: Friday, July 02, 2010 4:42 AM > Subject: Re: [DNSOP] Fwd: New Version > Notificationfordraft-mekking-dnsop-auto-cpsync-00 > > [snip] > > >> 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? > > This implies extra infrastructure to generate and securely transmit <secret> > between > the parent and child, and administrative activity to set this up somehow.
I regularly use TSIG today between my master server and the slave servers for my zones operated by other parties. TSIG really isn't a hard thing to setup or use. In many cases it's no harder than clicking on a button that generates a TSIG key that can be cut-and-pasted into the nameservers configuration on a https protected page. This is what I would expect would happen with TLD's via the registrars. In other cases I've generated the key and sent it to the slave. > The publication method does not imply any administrative action other than > updating > the DNS software and activating the DNSSEC feature. Publication also requires a secure exchange of crypto material. Mark > - George -- 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
