Another "what if scenario" for bypassing the EPP keyrelay with automation, what if there was a CKEYRELAY record pointing to the gaining DNS operator name servers, where the parent zone operator can grab the new DS record to be pre-published prior DNS operator transfer?
Potentially, parent zone can manage add/delete/transfers automatically, except for the initial DNSSEC setup which needs to be authenticated. Jack > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Paul Hoffman > Sent: February-19-13 11:37 AM > To: [email protected] WG > Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud- > dnsop-cds-00.txt > > On Feb 19, 2013, at 8:07 AM, Paul Wouters <[email protected]> wrote: > > > What is missing in this draft doing the same for other parent-child > > data, such as NS and glue records. Since we have an authenticated > > parent-child relationship now, why not extend this draft to include > > CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here, > > because the mechanism will be basically identical, although perhaps > > some more prevention for shooting one's foot might be required. > > +1. The operational implications of NS record changes are the same as for DS, > even though the DNS protocol ramifications are different. > > And, before someone suggests it, I am *not* in favor of a kitchen-sink > approach that defines some record of a random type as being for the parent. > It is fine for us to specify as many of these records now that we know about > (DS and NS and glue being mentioned so far), and if someone comes up with > one later, they can update the RFC with a new type for the new record. > > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
