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.
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. 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. 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.
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
