This is horrifically late, I'm afraid - dunno if it's too late to fix it before publication...
There is a problem in the procedure described in section 4.3.5.1. In the pre-publication phase the following things happen: The new operator sets up a copy of the zone signed with new keys, with an NS RRset pointing at the new servers, and a DNSKEY RRset containing both old and new public keys, signed with both old and new KSKs. The old operator adds the new public keys to the DNSKEY RRset and the new KSK signature, and updates the NS RRset to include the new servers as well as the old ones. This change of name servers is wrong! It can lead to validation failures as follows: A client has a cached copy of the old DNSKEY RRset. They do a lookup at an old server (say, www.example AAAA) which validates fine since it is signed with the old key. As a side-effect it gives them an updated NS RRset which includes the new servers. They do a second lookup at a new server (say, www.example A) which is signed which the new key - but the client cannot validate it because it doesn't have the new DNSKEY RRs. There is a simpler procedure for change of operator, which only requires operators to be able to import extra DNSKEY RRs - the same for both the old and the new operator. It does not require cross-signing as described in rfc4641bis, and it does not require either operator to host NS records pointing at a competitor. (1) The new operator sets up a copy of the zone signed with new keys, with an NS RRset pointing at the new servers, and a DNSKEY RRset containing the new public keys and signed with the new KSK. (2) The old operator imports the new DNSKEY RRs. The new operator imports the old DNSKEY RRs. Each operator has a DNSKEY RRset containing both sets of public keys, signed with their own KSK - a different signature at each operator. (3) The DS is updated to include the new KSK digest as well as the old one. (4) Wait for a TTL. Now all the clients are still using the old operator, but they are prepared to trust the new one. (5) Change the delegation NS RRset to point to the new operator. (4) Wait for a TTL. Now all the clients are using the new operator, and the old signatures have expired from their caches. (5) Clean up by deleting the old DS and DNSKEY RRs, and remove the zone from the old operator. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
