On 12/06/2011 20:50, George Barwood wrote: > I have updated the draft > > http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt > > I have added an appendix with an exampler KSK rollover, and made > various generally minor changes. > > IANA have now assigned type code 59 for the CDS RRtype. > > I'd like to request that the WG adopt this document.
Before calling for adoption of this draft or any other similar proposal, I think we should step back a minute and take a look at the context. There was quite a discussion on the subject of "automatic update of DS records" in this mailing list during February and March last year (the thread started by Tony Finch at at http://www.ietf.org/mail-archive/web/dnsop/current/msg08079.html). Early on in the discussion, Ed Lewis said: "My concern - if the IETF produces a solution for transferring DS records in-band to the DNS protocol we will repeat a mistake made in pushing EPP to Full Standard. Pushing EPP to Full Standard is in itself a true accomplishment and there is no controversy, the process was followed faithfully. The problem is, once it was Full Standard it was found to not be applicable to the general population that it was designed to serve. The protocol works and is interoperable; the requirements didn't grow as the use cases grew." I agree with Ed and think that we before adopting a solution, we should step back and ask some basic questions such as: 1. Is there a problem? 2. If so, do we agree on the nature of the problem? 3. If we agree, is the IETF (and in particular, DNSOP) the place to develop a solution? Last year's discussion thread covered a number of issues: at the risk of missing ones and losing some of the nuances of the discussion, the ones that stood out when I reviewed it were: * Do we need to automatically update DS records? Current manual procedures were cited as being error-prone (i.e. people are less likely to notice a mistake in cutting and pasting a DS record into a web form than doing the same with an NS record), and there was the suggestion that DS records are likely to need more frequent updating than NS records. * Who is the target audience? Should the operator/registrant-registrar-registry ecosystem be the primary or only target audience or should this approach focus on other parent/child relationships? * How should we update DS records? There was some discussion as to whether the update channel should be from child zone to parent zone, or whether the update should go through the registrant->registrar->registry path (or variation thereof). With the latter, EPP was suggested. * If we automatically update DS records, why not NS records? Delegations are frequently broken - if we have a mechanism for automatically updating DS records, can we use the same mechanism to update NS records as well? * What sort of security issues will arise? If you use an in-band (i.e. DNS) solution to transfer information from the child to the parent, how does it cope if the child zone has been compromised? * What sort of out-of-band communication should exist between parent and child zones? It was felt that some form of non-DNS communication needs to exist between the operators of the parent and child zones to handle initial zone configuration and to resolve emergencies and the like. * Does this raise any issues with regards to transferring secure domains between registrars? The problems associated with these types of transfers have been discussed to great extent elsewhere, but they may have a bearing on the solution. So it seems to me that the first step would be to write a draft that defines the problem and the requirements for a solution. (The requirements should include real-world requirements, e.g. how do we assess the potential bypassing of a registrar in changing registry data?) Solutions can then be measured against that. Does this sound a reasonable way for the WG to proceed? Stephen _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
