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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
