Subject: Re: [DNSOP] Error in rfc4641bis - change of operator

From: Matthijs Mekking <[email-masked]>
Date: Tue, 16 Oct 2012 15:38:18 +0200

Hi,

On 09/17/2012 12:42 PM, Tony Finch wrote:
> Matthijs Mekking <[email-masked]> 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.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 16 Oct 2012 15:38:30 +0200

Correct, applied your corrected text to the work in progress document.

Best regards,
  Matthijs

On 09/18/2012 01:55 PM, Tony Finch wrote:
> Section 4.1.3. This description of a variant rollover is dangerous: the
> new key must sign the DNSKEY RRset before the DS change, even if signing
> the rest of the zone is delayed.
> 
>    This rollover has the drawback that it introduces double signatures
>    over all data of the zone.  Taking these zone size considerations
>    into account, it is possible to not introduce the signatures made
>    with DNSKEY_S_2 at the "new DNSKEY" step.  Instead, signatures of
>    DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an
>    additional stage between the "DS change" and "DNSKEY removal" step:
>    After the DS RRset containing DS_S_1 has expired from distant caches,
>    the signatures can be swapped.  Only after the new signatures made
>    with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1
>    can be removed from the DNSKEY RRset.
> 
> Corrected text:
> 
>    This rollover has the drawback that it introduces double signatures
>    over all data of the zone.  Taking these zone size considerations
>    into account, it is possible to not introduce the signatures made
>    with DNSKEY_S_2 at the "new DNSKEY" step, except for the signature
>    over the DNSKEY RRset.  Instead, signatures of DNSKEY_S_1 in the rest
>    of the zone are replaced with signatures of DNSKEY_S_2 in an
>    additional stage between the "DS change" and "DNSKEY removal" step:
>    After the DS RRset containing DS_S_1 has expired from distant caches,
>    the signatures can be swapped.  Only after the new signatures made
>    with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1
>    can be removed from the DNSKEY RRset.
> 
> Tony.
>

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 16 Oct 2012 15:38:34 +0200

Correct, applied your fixed text to the work in progress document.

Best regards,
  Matthijs

On 09/18/2012 01:25 PM, Tony Finch wrote:
> Section 4.1.2, explanatory text:
> 
>    initial:  Initial version of the zone.  The parental DS points to
>       DNSKEY_K_1.  Before the rollover starts, the child will have to
>       verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
>       it is needed during the rollover and we refer to the value as
>       TTL_DS.
> 
>    new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
>       generates a second KSK, DNSKEY_K_2.  The key is provided to the
>       parent, and the child will have to wait until a new DS RR has been
>       generated that points to DNSKEY_K_2.  After that DS RR has been
>       published on all servers authoritative for the parent's zone, the
>       zone administrator has to wait at least TTL_DS to make sure that
>       the old DS RR has expired from caches.
> 
>    DS change:  The parent replaces DS_K_1 with DS_K_2.
> 
> This is missing a necessary wait: the old DNSKEY RRset must expire from
> caches before the parent to replaces the DS RR.
> 
> Fixed text:
> 
>    new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
>       generates a second KSK, DNSKEY_K_2, introduces it into the key
>       set, and signs the new key set with both the old and new KSKs.
>       The minimum duration of this phase is the time it takes for
>       the data to propagate to the authoritative servers, plus TTL value
>       of the key set.
> 
>    DS change: The new key is provided to the parent. The child will
>       have to wait until the parent replaces DS_K_1 with DS_K_2.  After
>       the new DS RR has been published on all servers authoritative for
>       the parent's zone, the zone administrator has to wait at least
>       TTL_DS to make sure that the old DS RR has expired from caches.
> 
> Tony.
>