This sections describes common key management activities of OpenDNSSEC.
The details of the command utilities shown below can be found here.
OpenDNSSEC will generate keys on the fly as required to perform the key rollovers specified by the policy; the timings of this generation will not always be easy to predict. However there may be situations where users would prefer to pre-generate a pool of keys (for example, some high availability setups; or just to have a more deterministic system). This is possible with the following command:
The interval specifies how long the pool of created keys should last for. The interval should be given careful thought as depending on the policy it may result in the generation of a large number of keys (the command will report the number to be generated and then prompt for confirmation). It is advisable to backup the keys after generating keys in this way.
You can configure the system to only make keys active once they have been backed up. This is done by editing the conf.xml file. The user must do backups and then notify OpenDNSSEC about this, so that the key rollover process can continue. The keys must be backed up regulary, because OpenDNSSEC is generating new keys prior to a rollover.
First prepare the backup by telling the Enforcer that you want to do backup of the keys. This is so that keys generated after you have done your backup won't accidentally be marked as backed up.
For all of the repositories:
or a single repository:
Then you can safely do your backups. Please read the documentation of your HSM for instructions on how to do backups.
When you are done, then notify the Enforcer about this:
For all of the repositories:
or a single repository:
The command ods-ksmutil backup done will mark your keys as backed up in one step. This means that keys may have been generated between you doing the backup and giving the command. Thus accidentally marking them as backed up. This command is deprecated and should not be used, unless you make sure to stop the Enforcer when doing your backup.
Backups are specified by way of a repository option in conf.xml:
If you decide you want to change this facility, you should edit conf.xml accordingly, and run:
It will report something along the lines of:
You need to publish your key to the parent or to interested parties. If you are doing a key rollover, then only the ready KSK should be exported. The following command will extract the trust anchors:
What you get in return is the DNSKEY or DS in BIND-format.
This step is not needed for a scheduled rollover.
The rollovers are done automatically according to the policy of the zone. But a manual keyrollover may be desired in cases of emergency, such as having lost a private key.
A manual rollover can be done using the ods-ksmutil command like this:
This will roll the KSK key in a timely manner following the policy used for the zone example.com. If you want to roll the Zone Signing Key use --keytype ZSK instead.
You can also roll all the keys for zones which have a certain policy. This can be useful if you want to move all keys from one key store to another.
Unlike ZSKs, a KSK rollover requires a second step involving manual intervention. This intervention is a multi-stage process. First, the DNSKEY record for the new key is added to the zone. Then, after a suitable interval, the new DS record is submitted to the parent; at this point the old DS record can be removed from the parent.
The stages are:
Extract the DNSKEY record for the new key and publish it in the parent zone. (The new record replace any existing records for the zone being signed.) When it is time for this to happen a message with log-level "info" will be sent to syslog looking something like:
The DNSKEY or DS RR can also be retrieved by using the commands in the section Export the public keys.
This step can be automated or semi-automated by placing a command in the <DelegationSignerSubmitCommand> tag. This should point to a binary which will accept the required key(s) as DNSKEY RRs on STDIN.
When the records indicated have been seen in DNS then this can be communicated to OpenDNSSEC with the ds-seen command as indicated:
If the DS records were not swapped, i.e. the old DS was left in the parent when the new one was added, then the --no-retire flag can be added to the ds-seen command. Then, at some later time, the old key can be retired with the command:
The former command will retire the specific key (provided the key is active, and the action will not leave the zone without any active keys). The latter command will retire the oldest active key on the zone, again provided it will not leave the zone without any active keys.
If you wish to run like this and use the DelegationSignerSubmitCommand hook then you will need to add the current key back into the set yourself.
Some users want to have more control over their key rollovers and roll keys on exact dates, for example the first day of each month. To do this you need to specify that you want manual key rollovers in the kasp.xml configuration. Add the <ManualRollover/> tag to the type and key you want to roll manually.
When this is done you can add the rollover commands to a cron job, with a command like this: