[Opendnssec-user] KSK rollover logic?

[Johan Ihrén]

Hi,

I'm playing with KSK rollovers and smashed my head on what appears to be a combination of 

1. Parent (not running OpenDNSSEC) assuming Double-Signature (i.e. "add new KSK to child; wait; flip the DS; wait; retire old KSK"). 

2. Child (running OpenDNSSEC 1.2.0) assuming Double-DS (i.e. "add new DS to parent; wait; flip KSK; wait; retire old DS").

What happened was that the child got stuck in "dssub" and refused to publish the new DNSKEY for which the DS had been requested. The parent in its turn refused to add a DS for a DNSKEY that was not visible in DNS. Both parties were stubborn ;-)

Am I missing something obvious here or is Double-DS really the intended default KSK rollover logic? I remember that during the OpenDNSSEC training course that I attended in December there was a bit of confusion about exactly what logic ODS currently implements (I think Rickard said "Double-DS", but I am not entirely sure). Googling a bit seems to imply that ODS should do "Double-Signature" KSK rollovers, so I suspect that this is me failing to find the knob.

Now, while there are certain advantages to each method (and also to the third alternative, Double-RRset) it clearly causes problems when child and parent have different expectations for the rollover method to use. If that happens there must be a way to align the logic.

My view is that the parent gets to decide the rules and the child has to adopt to that. The alternative of having the child decide simply doesn't work, as the parent would then end up having to treat different children in different ways. I.e. ODS must be able to adopt to the parent requirements. Furthermore, "Double-Signature", being the "first" KSK rollover method we identified, does have a bit of legacy status that would seem to make it reasonable to expect Double-Signature to be supported. 

Is there some knob somewhere that I'm missing that allows me to kick ODS into behaving according to Double-Signature KSK rollover logic (quite possible)? Otherwise I would argue that this really ought to be considered ASAP.

Regards,

Johan