On Wed, Jan 21, 2015 at 09:43:18AM +0100, Carsten Strotmann wrote:
The way I use the key dates is to specify the "retirement" and "deletion" only before the new key is generated, e.g. when the rollover starts. That way, the rollover can be postponed in time when needed
[...]
# dnssec-settime -p all Kexample.com.+008+50340 Created: Wed Jan 21 09:32:35 2015 Publish: Thu Jan 22 09:32:35 2015 Activate: Sun Jan 25 09:32:35 2015 Revoke: UNSET Inactive: UNSET Delete: UNSET
[...]
28 days after activation, the rollover process starts by setting the inactivation time and creating the successor key:
# dnssec-settime -I +2d -D +8d Kexample.com.+008+50340 ./Kexample.com.+008+50340.key ./Kexample.com.+008+50340.private # dnssec-settime -p all Kexample.com.+008+50340 Created: Wed Jan 21 09:32:35 2015 Publish: Thu Jan 22 09:32:35 2015 Activate: Sun Jan 25 09:32:35 2015 Revoke: UNSET Inactive: Sun Feb 22 09:37:28 2015 Delete: Sat Feb 28 09:37:28 2015
# dnssec-keygen -i 2d -S Kexample.com.+008+50340.key example.com
Thanks for posting this, very useful!
This looks like a robust and complete process for ZSKs, could you take a few minutes to describe any additional or different steps for SEP keys (KSKs)? (Especially in relation to DS RR updates, ...).