Hi Tony, [CC'ed the AD, as this may lead to a non-negligible change]
I think you are right, this situation can happen in the drawn scenario. However, I guess a sane validator would try the other name server (NS_A) if it would receive a validation failure from NS_B. Would this be fixed by just removing the pre-published NS_B from the losing operator version of the zone? Probably, except for sticky resolvers. Nevertheless, if that would fix it or not, we should update the scenario, or perhaps remove it as Miek suggested. If we look at the history of the document, the scenario has been mentioned first in version -01 and the corresponding figure saw the light in version -02. The working group had detected that this is a complex operation and that there is a simpler way to handle a change between DNS operators. This is what you describe in your e-mail as well and is first mentioned in the document in version -06. A figure for this scenario was provided in version -09 (although until now it includes unnecessary signatures over the DNSKEY RRsets and still has the faulty pre-publication of NS_B in the losing operator version of the zone). Since I sense that there is a general consensus that using a Double-DS method is a simpler way to handle a change between DNS operators in comparison with the Pre-Publication method, I would like to propose the following: - Remove the text on the Pre-publication style of changing DNS operators. - Move the figure from Appendix D to the section of changing DNS operators. Best regards, Matthijs On 09/14/2012 12:00 PM, Tony Finch wrote: > 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. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
