[Opendnssec-develop] Deactivating old KSK

[Stephen.Morris at nominet.org.uk]

Jakob Schlyter <jakob at kirei.se> wrote on 02/11/2009 12:10:51:

> On 2 nov 2009, at 13.03, Sion.Lloyd at nominet.org.uk wrote:
> 
> > There are 3 strategies for ksk rollover described in
> > draft-morris-dnsop-dnssec-key-timing-01 (
> > 
http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01#section-4.3 

> > )
> 
> if we do anything semi-automatic, it should be double KSK - i.e. when 
> the new KSK is published, we have to wait for the operator to ack 
> before removing the old KSK. double DS requires the operator to upload 
> the DS of a not yet publish KSK to the parent, which might be a bit 
> difficult for most operators to understand.
> 
> so, I hope we do double KSK with manual confirm before removing the 
> old KSK.
> 
>    jakob

The draft actually suggests the "double RRset", which minimises the key 
rollover time. In this method the new KSK is added to the zone and the 
associated DS record submitted to the parent.  After a suitable interval, 
the old DS record and KSK can be removed. However, that does separate the 
addition of the new DS record to the parent and the removal of the old 
one.  The double KSK, although taking longer, requires only one 
communication with the parent when changing the DS record.  What do people 
think - do the advantages of a single change to the parent zone outweigh 
the disadvantages of a longer rollover?

I agree about the manual confirm bit.  The earlier -00 version of the 
draft included an algorithm for doing a KSK rollover. (It was removed from 
the -01 version because it made the document too long and took the focus 
away from the timing issues).  This algorithm noted that you can't assume 
that the DS record will appear in the parent, a check needs to be made for 
it.

It does strike me that we need to get this sorted out fast though (i.e. 
before 1.0).  In particular, the documentation should describe the steps 
involved in doing a KSK rollover.


Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20091103/c47a2bc1/attachment.htm>