Matthijs Mekking <[email protected]> wrote: > > 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.
I think BIND will do that, but I'm less sure about Unbound and Vantio - see for instance a recent discussion on the dns-operations list: https://lists.dns-oarc.net/pipermail/dns-operations/2012-September/008725.html Duane Wessels's stunt authoritative nameservers are intended to detect validating resolvers. It alternately serves signed and unsigned versions of a zone and notices when the resolvers retry after a validation failure. In practice not all resolvers are persistent enough. > 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. Yes, the way to fix it is not to change the child NS RRset at the old provider A until redelegation time, which is when you are sure resolvers no longer have the old chain of trust cached and are able to validate the zone at the new provider B. There are a couple of ways to deal with sticky resolvers: (1) Change the NS RRset at A to NS_B after redelegation. (2) Reconfigure the zone at A to slave from B. There is a second bug in the draft which leads to lameness rather than validation failures. After redelegation, the draft says provider A should serve both NS_A and NS_B, so a sticky resolver will continue to send queries to A after the zone is deconfigured there in the post-migration phase. > 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. That's probably the right direction. However, I just looked at appendix D properly. It has errors too :-( Section 4.3.5.1 says: The requirement to exchange signatures has a couple of drawbacks. It requires more operational overhead, because not only the operators have to exchange public keys, they also have to exchange the signatures of the new DNSKEY RRset. This drawback does not exist if the Double Signature KSK rollover is replaced with a Double-DS KSK rollover. See Figure 15 in Appendix D for the diagram. But the figure in Appendix D shows that signatures HAVE been exchanged, so it doesn't have the simplification implied by this text. Figure 15 also changes the NS RRset at A too soon, so it doesn't fix the bug I found on Friday. A minor niggle: It has a "new DS" phase rather than an initial phase, which is not necessary: you can publish the new DS at the same time as the new DNSKEY RRs. That is, you can do the "new DS" phase of the double-DS KSK rollover at the same time as the "pre-publish" phase of the ZSK rollover. After all that here is what I think are the minimal changes necessary: To correct figure 10: Remove NS_B from the "Child at A" column in the pre-publish phase. Remove NS_A from the "Child at A" column in the redelegation phase. The second paragraph of the explanatory text should read: > The zone is initially delegated from the parent to the name servers of > operator A. Operator A uses his own ZSK and KSK to sign the zone. The > cooperating operator A will pre-publish the ZSK and KSK of operator B, > including the RRSIG over the DNSKEY RRset generated by the KSK of B. > Operator B needs to publish the same DNSKEY RRset. When the old DNSKEY > RRset has expired from the caches, the re-delegation can be made, which > involves adjusting the NS and DS records in the parent zone to point to > operator B. To ensure resolvers switch from A to B, operator A should > also change its NS records to point to operator B. And after all RRSIG > records related to A have expired from the caches (apart from the DNSKEY > RRSIG), operator B can stop publishing the keys and signatures belonging > to operator A. To correct figure 15: Change the first column from "new DS" to "initial" and remove DS_B. In the "Child at A" column of the pre-publish phase, remove NS_B and RRSIG_K_B(DNSKEY). In the "Child at B" column of the pre-publish phase, remove RRSIG_K_A(DNSKEY). Change the name of the pre-publish phase to "new DS and pre-publish". In the "Child at A" column of the redelegation phase, remove NS_A. Tony. -- f.anthony.n.finch <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
