> -----Original Message----- > From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of > Subject: [DNSOP] Problems with DS change in registry/registrar environment > > > Is this summary at least partially correct?
Partially, yes. I agree with you that there is no match between DNS operations and the definitions of registry transactions like you describe in 1 and 2. That's not the problem however, or at least is solvable at a local registry level by defining correct procedures. So let's not discuss the mixing up of roles like registrar, registrants, dns-operators, etc. The only reason they matter is because in practice: -95% of registrar changes INVOLVE a change of DNS operator -95% of registrant changes INVOLVE a change of DNS operator -10% of nameserver changes at a registry INVOLVE a change of DNS operator, in 90% of the cases they don't. The problem is in any transaction that involves a dns-operator change for the zone. Since this is a DNS discussion, let's not discuss registrars, registrants, etc. I only want to know how to move a DNSSEC zone from one DNS operator to another one, without outage. I don’t agree with you here: > 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. In normal non-DNSSEC DNS, when an NS set changes, both versions of the truth are still accepted by DNS resolvers. As long as you make sure the same data is in the old and new zone (except for the NS set), the general public doesn't notice anyting. In the period between the delegation change at the parent and the expire time of the old NS set, any answer in a resolver works. There is no blackout DNS-wise if you handle it right. With DNSSEC, it doesn't. Only one version of the truth works (only one validates), leading to a partial blackout for those resolvers/validators that still have the old DNSKEY in their cache. > 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 With whose key ? DNS-operator A or DNS-operator B ? > 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 Don't get you here. Where does he do this ? > 7 New Domain Operator is removing old NS > 8 New Domain Operator is removing old DS I think this procedure does not work. When you remove the old DS, the DNSKEY of the old zone is still in caches. That's the real issue. I think the best way to get this working is if we can make sure that a validator will go back to the parent to verify if NS and DS records have changed once validation fails. Search for a changed chain of trust. If we cannot mandate that to resolvers/validators, then the procedures for changing DNS-operator (and thus registrar, registrant, etc) will become very complex, and can only be done with the cooperation of the losing DNS-operator if you don't want outage. The loosing DNS operator then needs to sign the DNSKEY records from the gaining DNS operator with his private key, and publish those RRsigs. I would like best not to have complex procedures. So can we mandate resolver/validation behavior ? Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl http://www.sidn.nl/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
