Hi Goerge, What I like about your approach is the fact that is takes advantage of DNSSEC. My opinion is that if DNSSEC is so great it would be cool if we can define an update mechanism that utilizes it. This could be the first real world application for DNSSEC.
I would encourage some type of notification mechanism so that the parent doesn't have to poll blindly. Also, why not use a DNSKEY with another flag to announce the availability of a new key instead of a new RR? Similar to what RFC5011 is doing for a revoked key. Thanks, S ---------------------------------------------------------------------- Stephan Lagerholm Senior DNS Architect, M.Sc. ,CISSP Secure64 Software Corporation, www.secure64.com Cell: 469-834-3940 > -----Original Message----- > From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of > George Barwood > Sent: Wednesday, June 30, 2010 5:37 AM > To: Matthijs Mekking; dnsop@ietf.org > Subject: Re: [DNSOP] Fwd: New Version Notificationfordraft-mekking-dnsop- > auto-cpsync-00 > > I'd like to encourage some discussion of the relative merits of the UPDATE > approach > > http://www.ietf.org/id/draft-mekking-dnsop-auto-cpsync-00.txt > > compared to the publication approach outlined in the recent draft at > > http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt > > I haven't yet done a well-considered analysis, and maybe this would be > better > undertaken by others, but here are some of my immediate thoughts: > > 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. > > The publication approach leverages the in-built redundancy of DNS slave > servers > for transmitting information, and seems closer to the normal DNS method of > operation. > > I also like the ability to simply check whether the parent and child DS > RRset > are properly synchronised. > > I'm a bit doubtful about the complications of setting up additional secret > keys for UPDATE. > > Regards, > George > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
