On 1/21/2015 3:43 AM, Carsten Strotmann wrote:
Hello John,



Example:

the initial key generation:

# dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -P +1d -A +4d example.com

publication: now + 1 day
activation: now + 4 days
retirement: unset
deletion: unset

# 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

# dnssec-settime -p all
Kexample.com.+008+40260 Created: Wed Jan 21 09:38:04 2015
Publish: Fri Feb 20 09:37:28 2015
Activate: Sun Feb 22 09:37:28 2015
Revoke: UNSET
Inactive: UNSET
Delete: UNSET

By setting the inactivation time not at the creation of the key, but
when the rollover starts, the process is more robust against failures
of the script/process and the rollover can be postponed if needed (by
disabling the script).

But please send a feature request to the BIND 9 people (email
<bind9-bugs@isc.org>) if you feel relative dates for a successor key
would be useful.

Best regards

Carsten
Our processes are very similar . The initial key was generated in much the same way as yours. Except I did not set any dates and so the very first key as created with Create, Publication and Active all set to NOW automagically.

dnssec-keygen  -a RSASHA256 -b 2048 -3 klam.ca.,  I then did a settime with -I+60d -D+90d. The usual house-keeping was performed adding the NSEC3 chain etc.
which gave me:

root@bilbo:/etc/bind/keys# dnssec-settime -p all Kklam.ca.+008+00849.
Created: Fri Jan 16 20:22:55 2015
Publish: Fri Jan 16 20:22:55 2015
Activate: Fri Jan 16 20:22:55 2015
Revoke: UNSET
Inactive: Sun Feb 15 21:12:51 2015
Delete: Mon Mar  2 21:12:51 2015

I then created a second key using my proposed rollover procedure, which goes something like this:

1 ) manually extracted the key activation date and use it as a base for running keygen., which in this case Feb 15, 2015 (20150215). In the example below I am using a 30 day active-life and 15 day retirement, in practice I would probably use 90 and 120.

2) dnssec-keygen -i7d -S Kklam.ca.+008+00849 -I 20150215+30d -D 20150215+45d klam.ca. followed by the usual house keeping.
-S param takes care of getting the right date for publishing and activation..

I did a ran a test of the above which gives me:

root@bilbo:/etc/bind/keys# dnssec-settime -p all Kklam.ca.+008+26709.
Created: Fri Jan 16 21:15:23 2015
Publish: Sun Feb  8 21:12:51 2015
Activate: Sun Feb 15 21:12:51 2015
Revoke: UNSET
Inactive: Tue Mar 17 22:15:23 2015
Delete: Wed Apr  1 22:15:23 2015

Currently to keep rollovers up to date I have to manually intervene perform steps 1 & 2 each time. I am trying to work out how to find the current valid ZSK and extract the various, dates from it in order to automate this process. The attached script is an early attempt of mine at automating this process, but I am not happy with it, as it using the key files and I am not sure this is the best approach or if I should be getting the info directly from Bind.

my second biggest problem is that its 10 years plus since I wrote any code so more than half the time is spent reading the bloody book!!!

My 2 cents worth.

--
John Allen
KLaM
------------------------------------------
How do you tell when you're out of invisible ink?