Subject: Re: [DNSOP] Late comments on rfc4641bis

From: Olaf Kolkman <[email-masked]>
Date: Thu, 8 Jul 2010 15:04:36 +0200

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 9 Jul 2010 07:32:37 +0200

Thanks Olaf!

   Patrik