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.
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
