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

[Jake Zack]

Tested with OpenDNSSEC versions 1.4.8.2, 1.4.14-0.

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

Tested with sqlite3 and mysql.



Steps:



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>