Thanks Olaf! Patrik
On 8 jul 2010, at 15.04, Olaf Kolkman wrote: > > On Mar 24, 2010, at 11:19 PM, Patrik Fältström wrote: > >> General comment: >> >> The document is not clear enough regarding the roles of the registrant, dns >> operator, registrar and registry -- where the dns operator is in the >> document implied to be the one that hold the private keys. Further, the same >> organsiation might have one or more of these roles. > > > > ACK. > > >> >> 4.4.1. >> >> OLD: >> >> The initial key exchange is always subject to the policies set by the >> parent. >> >> NEW: >> >> The initial key exchange is always subject to the policies set by the >> parent. This is specifically important in a registry-registrar model where >> the key material is to be passed from the DNS operator, via a registrar to >> the (parent) registry, where both DNS operator and registrar is selected by >> the registrant and they might be different organisations. >> > > ACK. > > >> 4.4.2. >> >> OLD: >> >> In the registry-registrar model, one can use the >> DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [14], >> which allows transfer of DS RRs and optionally DNSKEY RRs. >> >> NEW: >> >> In the registry-registrar model, one can between registry and registrar use >> the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [14], >> which allows transfer of DS RRs and optionally DNSKEY RRs. There is no >> standardized way for moving the data between DNS operator and registrar >> although the DNSSEC extensions to epp can be used there as well. Different >> registrars have different mechanisms, where a simple web interface is what >> is used in most cases, and various APIs are used in other cases. >> > > This didn't quite parse > > I've rewritten: > <t> > The storage considerations also relate to the design of > the customer interface and the method by which data is > transferred between registrant and registry; Will the > child zone administrator be able to upload DS RRs with > unknown hash algorithms or does the interface only allow > DNSKEYs? When Registries support the Extensible > Provisioning Protocol (EPP) <xref target="RFC4310"/> then > that can be used for registrar-registry interactions since > that protocol allows the transfer of DS and optionally > DNSKEY RRs. For moving data between DNS operator and > registrar there is no standardized way for moving the > data. Different registrars have different mechanisms, > ranging from simple web interfaces to various APIs. In > some cases the use of the DNSSEC extentions to EPP may be > aplicable to. > </t> > > > > >> 4.4.5.2. >> >> OLD: >> >> However, there is no operational methodology to work around this >> business issue and proper contractual relations ships between >> registrants and their registrars seem to be the only solution to cope >> with these problems. >> >> NEW: >> >> However, there is no operational methodology to work around this business >> issue, and proper contractual relationships between all involved parties >> seems to be the only solution to cope with these problems. It should though >> be noted that the problem with temporary broken delegations in many cases >> already exists when DNS operator is changed for a zone, as that often >> implies also move of services that the DNS reference. So if not DNS is >> "down" for a while does in reality not have so much impact as services >> referenced by the DNS also will be down in the same service window. To >> minimise such problems, the only recommendation is to have relative short >> TTL on all involved resource records, and that will solve many of the >> problems regarding changes to a zone. Not only the time when DNS operator is >> changed and DNSSEC is in use. >> > > > I agree with the changes (specifically the change of contracts between > registrants and registrars to 'all parties') although I've rewritten the > paragraphs a bit for clarity (I hope): > > > <t> > However, there is no operational methodology to work > around this business issue, and proper contractual > relationships between all involved parties seems to be > the only solution to cope with these problems. It should > be noted that in many cases, the problem with temporary > broken delegations already exists when a zone changes > from one DNS operator to another. Besides, it is often > the case that when the DNS moves from one operator to > another the services that that zone references also > change operator, possibly involving some downtime. > </t> > <t> > In any case. To minimise such problems, the classic > recommendation is to have relative short TTL on all > involved resource records. That will solve many of the > problems regarding changes to a zone regardless of > whether DNSSEC is used. > > </t> > > > > --Olaf > > > > > > >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ________________________________________________________ > > Olaf M. Kolkman NLnet Labs > Science Park 140, > http://www.nlnetlabs.nl/ 1098 XG Amsterdam > >
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
