-
Type:
Bug
-
Status: Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: OpenDNSSEC 2.0.0a3, OpenDNSSEC 2.0, OpenDNSSEC 2.1, 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.9, 2.1.8, 2.1.10
-
Fix Version/s: None
-
Component/s: Distribution
-
Labels:None
-
Environment:
MariaDB / MySQL backend, migating from 1.4 to 2.x
Hello,
during migration from 1.4 MySQL database to 2.1.x, a conversion script with associated SQL in /usr/share/opendnssec/migration/1.4-2.0_db_convert/mysql_convert.sql creates new db structure TABLE keyData.
The table has field 'inception', which in 1.4 parlance is 'generate', i.e. the time when the key was born into existence.
The migration script incorrectly uses 'dnsseckeys.publish' and not 'keypairs.generate' when populating TABLE keyData, so a time-wise logical impossibility ensues.
This is a problem (at least) when ZSKs autoroll. New key is taken from HSM and becomes 'ready' and old key becomes 'retire'. However, nothing happens after that and the zone ends up with both keys, and both keys are used for signing, i.e. double signature. DNS will not break, but it's an annoyance and I believe it doubles the reply size. The situation can be resolved doing manual 'sudo -u ods ods-enforcer key rollover -t ZSK -p ...' or similar, but it is annoying nonetheless.
The correct timestamp can be had using "UNIX_TIMESTAMP( (SELECT REMOTE.keypairs.generate WHERE REMOTE.keypairs.id=REMOTE.dnsseckeys.keypair_id) )", for which I attach a patch.
Best regards,
–
Mikko Rantanen