[dnssec-deployment] Problems with DS change in registry/registrar environment
pk at DENIC.DE
Tue Jun 30 07:31:28 EDT 2009
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.
> 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.
> 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
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.
More information about the Dnssec-deployment