[On request from Olaf, also dnsop is included:ed]
I think this discussion have derailed a bit, while on the other hand
explained somewhat to me what things are really creating problems.
We have a problem when "a domain changes hands" and the private DS key
in some way is changed, should be changed, and sometimes is not
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.
First a description on the issues:
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)
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)
2.5. Update of techc in the domain object (change of Techc) [rarely
used even in thick registry situations]
First conclusion is that we see that the operations under (1) does not
match operations under (2), and specifically, there is in (2) not
anything that maps clearly with (1.3) which might be the key operation
when we know the DS for the zone should change.
I started the discussion because I have seen problems in .SE in these
two cases:
A. The domain is transferred (1.1) to a registrar that does NOT handle
DNSSEC
B. The domain is transferred (1.3) to a Domain Manager that does NOT
Handle DNSSEC
I also pointed out I have (just like Patrik Wallström) seen cases where:
C. The Registrar and Domain Operator are different entities, and
although the registrar do handle DNSSEC operations, the Domain
Operator is not using it.
Conclusion of the main portion of the discussion I thinks about the
simple cases:
A change like any of the above that implies change of DS is for the
parties that know what they are doing, "just like" any key rollover.
Further, the key rollover can, just like change of NS, happen
regardless of what kind of change we deal with (1.1, 1.2, 1.3) with a
minimum involvement of the donating registrar and Domain Manager:
1 New Nameservers are set up
2 Old zone is served on new nameservers
3 Old zone is signed on new nameservers
4 Domain is transferred to new registrar
5 New Domain Operator is adding new DS to the old DS set
6 New Domain Operator is adding new NS
7 New Domain Operator is removing old NS
8 New Domain Operator is removing old DS
Or similar. The only problem I might see is that in step 2, the old
zone must be available for the new domain operator (nothing new, this
has always been a problem). In step 4, a notification is sent to old
registrar, and if the old registrar is also the old domain manager,
the zone is often ripped from the old nameservers (without any delay),
and a blackout is happening.
This is old news for many parties, and only the DS is adding some
complexity to this, and of course finding that there are some errors
is a new thing if there is such blackout (but I can tell you you learn
fast ;-) ). This scenario is also independent of whether the gaining
Domain Operator is the same or different organisation as the gaining
Registrar.
The problems I started the discussion with still exists though. And my
suggestions for fixes I think are still on the table. I have still not
contacted Patrik Wallström to see how bad the situation is in .SE, but
we will do that as soon as we can.
To fix A, which I think is serious, because DS operations can _NOT_ be
made with the registry if the registrar is not handling DNSSEC
operations with DNSSEC.
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.
A.2. Transfer the domain (again) during the blackout to a new
registrar that do handle DNSSEC (hopefully at least one exists...see
the RSTEP review of .ORG request on using DNSSEC.
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
such. And A.2 is still possible to fix the problem if the registrant
want DNSSEC on their domain.
To fix B, we have a larger problem from a registry/registrar
perspective, because it is impossible in epp to know when the domain
operator is changed. There are some experimentation in some TLDs on
defining Domain Operator as a special role/contact, but epp already
today have problems with incompatibe handling of contacts so that
scares me a bit. I do think we MUST reach some conclusions here. In
the discussions on the list, people unfortunately (I think) talked too
much about the special case when one of the Domain Operators
(specifically the gaining one) is a registrar, but if so, we have a
"case A". And for me that is not so interesting (it is a different
problem).
The good thing with case B is that it is still possible for the
registrant to remove the DS, if not the domain is moved again to some
Domain Operator that can handle DNSSEC.
My suggestion for fixing B is that (we will test this in .SE) the
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.
To fix C, we need a protocol so that registrars can give a better
interface than "point and click" for update of the DS. Some registrars
in Sweden (at least two) are working on ideas on such protocols. Still
too early for IETF work on this. Until this is fixed, each Domain
Operator will most certainly either be the same organisation as
registrars, or be friend with one registrar that have a special API
that they use.
Is this summary at least partially correct?
Patrik
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
