Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SUPPORT-291: Wrong inception time in keyData after migration #851

Open
wants to merge 1 commit into
base: 2.1/develop
Choose a base branch
from

Conversation

dogo42
Copy link

@dogo42 dogo42 commented Dec 6, 2023

SUPPORT-291, https://issues.opendnssec.org/browse/SUPPORT-291

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 possibly be resolved doing manual 'sudo -u ods ods-enforcer key rollover -t ZSK -p ...' or similar, but it is annoying nonetheless.

This patch fixes the issue.

SUPPORT-291, https://issues.opendnssec.org/browse/SUPPORT-291

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.

This patch fixes the issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant