Jake Zack
2017-08-16 20:43:31 UTC
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.
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.