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.