I wrote myself a small bash script to handle ZSK rollover, it might handle KSK but I have tried it. All it does is to setup for a DNSSEC-keygen. My idea is to automatically pick a ZSK and use it as the base for the next key set, as per the -S param in DNSSEC-keygen. The only real additions are the calculation of an Inactivation and a Deletion date based upon the new keys Activation date retrieved from the base key. I use a param which I call the "active life" (Active - Inactive) and a second param called "retirement" (Inactive - deletion).
A couple of questions: Does anybody know if key rolling is going to be part of Bind (as part of maintain/inline) maybe? Has the been any discussion on basing the +/-nn part of the date/time params, not on today, but on one of the existing params when the -S option is used?
On 20.01.2015, at 04:47, John john@klam.ca wrote:
I wrote myself a small bash script to handle ZSK rollover, it might handle KSK but I have tried it. All it does is to setup for a DNSSEC-keygen. My idea is to automatically pick a ZSK and use it as the base for the next key set, as per the -S param in DNSSEC-keygen. The only real additions are the calculation of an Inactivation and a Deletion date based upon the new keys Activation date retrieved from the base key. I use a param which I call the "active life" (Active - Inactive) and a second param called "retirement" (Inactive - deletion).
Just in case that you don't know this already: DNSSEC Zone Key Tool (http://www.zonekeytool.de) is a combination of scripts to handle key rollover with BIND.
Regards, Jan
On 1/20/2015 6:27 AM, Jan Münnich wrote
Just in case that you don't know this already: DNSSEC Zone Key Tool (http://www.zonekeytool.de) is a combination of scripts to handle key rollover with BIND.
Regards, Jan
I saw it, unfortunately it does not work with my setup.
Hello John,
On Mon, 19 Jan 2015 22:47:59 -0500 John john@klam.ca wrote:
A couple of questions: Does anybody know if key rolling is going to be part of Bind (as part of maintain/inline) maybe?
Not that I'm aware of. Would probably be a major addition, as BIND 9 would need to keep state across restarts.
Has the been any discussion on basing the +/-nn part of the date/time params, not on today, but on one of the existing params when the -S option is used?
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
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
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, ...).
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 wrote:
For this exercise all time is measured in days
|<--------------------------- Key Life ------------------------------>| | | |<- Lead Time ->|<--------- Active Life --------->|<- Retirement ->| | | | | |____ __________|__________________________________|__________________| | | | | | | _P_ublish | | | | | | | |<- Create |<- _A_ctive _I_nactive ->| _D_elete->|
Problem:
- what is the easiest/best way of retrieving information on the current ZSK.
I use a symbolic link that I resolve using "readlink":
% ln -s Kexample.com.+008+25464.key Kexample.com.active.zsk % readlink Kexample.com.active.zsk Kexample.com.+008+25464.key
It would also be possible to retrieve a RRSIG from the active zonefile (or from an authoritative DNS server) and get the ZSK keytag number (field 6 of the RRSIG data) from there:
# dig soa sys4.de +dnssec ;; ANSWER SECTION: sys4.de. 3600 IN SOA ns.sys4.de. hostmaster.sys4.de. 2015012206 3600 3600 604800 3600 sys4.de. 3600 IN RRSIG SOA 8 2 3600 20150129030130 20150122135311 14544 sys4.de. xg6+KXifZyQj3URwaY6XaTsLcQn7g31DiVv+Q3u2IHBQzZZjAvkTm35W qjWDSsaD31jeNgQVCqvROHs9jmXM+LbSBqfxxLcdR9HFrhuTSZl03S4+ 9KIuAbfej7Fr/jguadPPel7ZfdKHf43QvUpb5iy3kxfGh9uzqAvad0BH h+E=
The current ZSK for sys4.de has the keytag 14544 and algorithm 8, so the name of the key-file on disk is "Ksys4.de.+008+14544.key" (true only for BIND 9 DNSSEC tools).
- Could any of the interval use TTLs if so which ones.
not TTLs alone, as the propagation time (master -> slaves) needs to be taken into account. If you have faith that propagation will happen in your SOA-refresh time:
* Time between "publish" and "active" is SOA-Refresh + TTL of the DNSKEY Record Set * Time between "inactive" and "deletion" is SOA-Refresh + largest TTL in the Zone
Because of the 2nd, it is recommended to not use excessive TTL times in DNS records in signed zones (I would recommend max 24 H = 86400 sec)
- Should the he interval in this setup be checked against TTLs.
Sorry, I'm not seeing what the "he" interval is. Can you explain?
Carsten
On 1/22/2015 10:08 AM, Carsten Strotmann (sys4) wrote:
- Should the he interval in this setup be checked against TTLs.
Sorry, I'm not seeing what the "he" interval is. Can you explain?
*/the he -> the/*, I think I typed the twice and only partially removed the second one. It should read "Should the intervals in this setup be checked against TTLs."
However, looking back at it I am not sure what I would be checking them for.
|<--------------------------- Key Life ------------------------------>| | | |<- Lead Time ->|<--------- Active Life --------->|<- Retirement ->| | | | | |____ __________|__________________________________|__________________| | | | | | | |<-Publish | | | | | | | |<- Create |<- Active Inactive ->| Delete->|
I am think of changing the above. Either replace "lead time" with "latency" and use lead time to describe the period between creation and publication, or vice versa.
Hi,
the blog post by JP Mens "RFC 5011 with OpenDNSSEC, BIND, and Unbound" might be of interest for those following this discussion: http://jpmens.net/2015/01/21/opendnssec-rfc-5011-bind-and-unbound/
Best regards
Carsten
participants (6)
-
Carsten Strotmann -
Carsten Strotmann (sys4)
-
Jan Münnich -
John -
John Allen
-
Viktor Dukhovni