[Opendnssec-user] How to have multiple ODS signers using the same keys in the same order

Jake Zack jake.zack at cira.ca
Wed Aug 16 20:43:31 UTC 2017

Tested with OpenDNSSEC versions, 1.4.14-0.

Tested with SofthSM-1, AEP Keyper Enterprise, Gemalto Safenet Luna.

Tested with sqlite3 and mysql.


On Server 1:  Run 'ods-ksmutil setup' to ensure that the kasp.db and/or the mysql database is zeroized.

On server 1:  Generate keys (ods-ksmutil key generate ...)

                -> This populates the kasp.db and/or the mysql table 'keypairs' with a numerically ordered list of all keys.

                -> This 'keypairs' list is what dictates the order with which all keys will be used in the future and their order.  (mysql> use opendnssec; select * from keypairs;)

                -> Each key is added (key 'id') in the order in which they were created.

On Server 1:  Start the 'ods-enforcerd' process

                -> This marks keys and timings in the kasp.db and/or populated the mysql table 'dnsseckeys'

                -> You can see these keys and timings with 'ods-ksmutil key list -verbose'

On Server 1:  Stop the 'ods-enforcerd' process

On Server 1:  Stop the 'mysqld' process (if applicable)

On Server 1:  Tarball the mysql data directory and copy it over to server 2. -OR- copy over the kasp.db file. (and/or the softhsm directory if applicable)

On Server 1:  Restart the 'ods-enforcerd process'

On Server 1:  Restart the 'mysqld' process (if applicable)

On Server 2:  Untarball the mysql data directory created in the previous step. -OR- place the copied kasp.db file into it's proper location (and/or the softhsm directory if applicable)

On Server 2:  Start the 'mysqld' process (if applicable)

On Server 2: Run 'ods-ksmutil key list --verbose' to verify that it now has the same keys selected

On Each Server:  Run a key rollover and notice that both servers select the same next key (id) from the table 'keypairs' and add said key to the table 'dnsseckeys'.

Success!  (See some notes below)


In a previous post about my sudden inability to do this when I was able to a few years ago, I was wrong.  The behaviour didn't change.

My bad assumption #1:

                I believed the initial run of 'ods-enforcerd' was what decided which key(s) would be picked first.

My lesson learned:

                'ods-enforcerd' does not decide which key will be picked first/next - only the 'keypairs'(id) decides that (where appropriate - if KSK is 2048 and ZSK is 1024, it will pick the next available 2048).

My bad assumption #2:

                Because of assumption #1, I believed that I could run 'ods-enforcerd' on the second box and have it make the same decisions

My lesson learned:

                'ods-enforcerd' doesn't check the HSM for available unused keys...it checks the 'keypairs' database.

My wish:

                I wish ods-enforcerd, on initial run, would first check the HSM for available keys instead of checking 'keypairs', finding it empty, and then generating a new key.

è This behaviour would be especially bad in situations where someone is using multiple AEP Keypers in remote locations, as it would take a trip and smart cards to get the newly generated key on to the secondary HSM.             (Unless using AEP load balancer, I guess)

Key considerations:

Over time, if you have OpenDNSSEC managing your roll-overs, you will see a slow amount of drift between key rollover timings.  If Server1 takes 2 seconds longer than Server2 to roll a key, the timings will now be 2 seconds off.

You can periodically resynch this, but generally it's not a problem so long as one server (production) is the source of truth, and the other server acts as a backup/failover.

Even if both are in production, so long as the DS record at the parent matches the KSK you're signing your ZSK(s) with, you're more than likely okay in a vast majority of situations.

If you're not using OpenDNSSEC to do roll-overs, but are instead set to <ManualRollover/>, you need not worry about this drift of timings.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20170816/c2633f93/attachment.htm>

More information about the Opendnssec-user mailing list