Hi, On 09/17/2012 12:42 PM, Tony Finch wrote: > 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
I am not sure what is going on exactly there, but when responses come
back with unsigned NSEC, it seems to me that Unbound is correctly
returning a SERVFAIL.
>
> 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 :-(
Yes, I mentioned that in the previous mail:
... (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).
>
> 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.
As I mentioned...
>
> 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.
Ok, adjusted the figure.
> 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.
I think we should remove this overly complex rollover with too many
drawbacks.
> 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.
Well, that is just the paragraph as it is now right? So it seems that
text should be adjusted. But if we are going to remove this rollover,
this text will be removed too. Here is the suggested text for the
explanatory text that goes with the other approach:
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.
In the second stage, 'new DS and pre-publish', the cooperating
operator A will pre-publish the ZSK of operator B, while the new
operator B publishes the ZSK of operator A. Both operators sign their
zone with their own ZSKs and KSKs. At the same time, operator B can
pre-publish the new DS record, DS_B, that delegates to the KSK of
operator B.
When the old DNSKEY and DS RRsets have expired from the caches, i.e.
all the resolvers are still using the delegation of the old operator
but are prepared to trust the delegation to the new operator, the
re-delegation can be made. This involves adjusting the NS RRset 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. In the post migration stage, when all RRSIG records
related to A have expired from the caches, operator B can stop
publishing the keys belonging to operator A and the DS record
belonging to operator A, DS_A, can be removed from the parent zone.
>
>
> To correct figure 15:
>
> Change the first column from "new DS" to "initial" and remove DS_B.
Sure.
>
> In the "Child at A" column of the pre-publish phase, remove NS_B and
> RRSIG_K_B(DNSKEY).
Yes.
>
> In the "Child at B" column of the pre-publish phase, remove
> RRSIG_K_A(DNSKEY).
Yes.
>
> Change the name of the pre-publish phase to "new DS and pre-publish".
Sure.
>
> In the "Child at A" column of the redelegation phase, remove NS_A.
Yes.
All done in the work in progress document.
Best regards,
Matthijs
>
>
> Tony.
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
