On Tue, Jun 30, 2009 at 08:36:47AM +0200, Patrik Fältström wrote: > [On request from Olaf, also dnsop is included:ed]
<hat "dnsop co-chair"> The discussion and input is very wolcome in DNSOP. For reasons related to "Note Well" <http://www.ietf.org/maillist.html> we'll not be able to routinely approve cross postings. That said, I'd humbly suggest we move followups that help framing document updates to dnsop only. </hat> > changed as it should. We all agree that could lead to a blackout, but > in many cases the blackout is not more serious than a normal blackout > when NS is changed. ack > 1. We have three different kinds of changes that can happen: > > 1.1. Change of Registrar > 1.2. Change of Registrant > 1.3. Change of Domain Manager (DNS Hosting Provider) Terminology is crucial here and domain manager as well as domain operator are ambiguous. The entity changed under 1.3 is probably the one that has the "hands" on the zone content and essentially holds the key(s). The former is often called the "zone maintainer". Of course there are popular scenarios more complicated than that, for example where a customer can maintain - to a certain extent - the content of their zone through some web or database interface that will then feed the primary master. I'd assume that DNSSEC will be transparently added by the service provider here and it's arguable who best fits the "zone maintainer" role. > 2. We have when using epp some limited number of commands available > > 2.1. Transfer (change of registrar) > 2.2. Update of holder in the domain object (change of Registrant) > 2.3. Update of host in the domain object (change of nameservers) > 2.4. Update of IP address in host object (change of IP address of > nameservers) Just as a side note, this is another place where the R-R-R model breaks, because the most authoritative party, the operator of said nameserver is not - per se - involved in this scenario. We've discussed that to - almost - death for root zone delegation changes. > 2.5. Update of techc in the domain object (change of Techc) [rarely > used even in thick registry situations] For DE, there exist both "tech-c" and "zone-c" where the latter is supposed to be the "zone maintainer". > I only see three possible solutions: > > A.1 Have as a new requirement on accredited registrars that they MUST > be able to handle DNSSEC operations with epp. In .SE we had as a > requirement that they MUST be able to remove DS (but not add), but I > claim that is not enough. Well, this is a registry policy issue and hence not necessarily workable in all environments. But it may be an option. > A.3. Have the registry remove DS implicitly if domain is transferred > to registrar that does NOT handle DNSSEC. > > My suggestion is that we look carefully on option A.3. This does not > imply any changes to any pieces of the protocol, deployed operation or I'd support that suggestion. > scares me a bit. I do think we MUST reach some conclusions here. In Well, conclusions maybe, but probably not a consensus. This situation (name server change to servers that don't or don't all support DNSSEC) is similar to changing the delegation into a lame delegation. If I understand your scenario B correctly, sensible pre delegation checks can avoid damage here. > registry is going through all DS in the zone, and detect what DS are > bad, what are "category B" and then notify the domain holder and > registrar. We'll see on the details, but "handle just like lame > delegations" is probably the best option. OK, it helps to read to the end ;-) > Is this summary at least partially correct? It may be more than a summary, but I believe it raised all issues. -Peter _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
