[Opendnssec-user] Apply key inception time and state to all zones of a shared policy on key import

Guillaume-Jean Herbiet gjherbiet at restena.lu
Thu Jan 27 09:58:00 UTC 2022


I would like to import keys for a shared policy, including the inception date, so the state on the test system is the same as on the production system.

For this I issue, e.g. for the shared KSK:

ods-enforcer key import \
	--repository <myrepo> --cka_id <locator> \
	--keytype KSK --keystate active \
	--inception_time 2020-08-26-15:56:56 \
	--algorithm '8' --bits '2048' \
	--zone <zone1>

While this works fine, for all subsequent zones in the shared policy (e.g. `zone2` ... `zoneN`), I receive the following error:

Already used this key with this locator: <locator>

If I later request the key states for zones using this policy, I see that the first imported zone has the KSK is active, the other zones are in `ready/waiting for ds-seen` states:

# ods-enforcer key list --verbose | grep KSK | grep '^<zone>'
<zone1>  KSK  active  2022-08-24 15:59:15  2048  8  <locator>  <myrepo>  <keytag>
<zone2>  KSK  ready   waiting for ds-seen  2048  8  <locator>  <myrepo>  <keytag>
<zone3>  KSK  ready   waiting for ds-seen  2048  8  <locator>  <myrepo>  <keytag>

The fact that the inception time is only applied to the first imported zone is confirmed while looking at the `kasp.db` SQLite DB, especially the `keyData` and `keyState` tables:

# sqlite3 -header -csv kasp.db "SELECT p.name, z.name, d.*, s.* FROM keyData d LEFT JOIN keyState s ON s.keyDataId = d.id LEFT JOIN zone z ON z.id = d.zoneId LEFT JOIN policy p ON p.id = z.policyId WHERE d.role = 1 ORDER BY p.id, z.id, d.id, s.id ASC;"

Considering shared policies, it seems strange to me that `ods-enforcer key import` requires a `--zone` argument and not a `--policy` argument (as the one-to-one matching between the two is not relevant for shared policies), or that the command doesn't actually import the key (or at least apply the requested states and inception time) on subsequent zones of a shared policy.

To get around this, I could manually update the `kasp.db` (this is on a test system):
- set `keyData.inception = <inception_time>` and `dsAtParent = 3` for all KSKs of the subsequent zones
- set `keyState.state = 2` where `keyState.state = 1` for all KSKs of the subsequent zones
- set `keyState.lastChange = <inception_time>` where `keyState.state > 1` for all KSKs of the subsequent zones

This is based on the the differences between first and other zones observed in my request.
Can you confirm this is relevant (at least when no key roll-over is in progress)?

Note: prior to this, I would copy the full `kasp.db` to test systems, but this time I only wanted to focus on a specific policy, hence the idea of importing keys using `ods-enforcer` command.

Thanks in advance for your replies,

Guillaume-Jean Herbiet, PhD
DNS-LU Technical Manager/Team Leader

Fondation Restena
2, avenue de l'Université
L-4365 Esch-sur-Alzette

T +352 42 44 09 1
F +352 42 24 73

restena.lu | dns.lu | my.lu

PGP 0x3A4C47C7

This email may contain information for limited distribution only, please treat accordingly.
*** I am out-of-office on Wednesdays ***

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20220127/bf211ebb/attachment.bin>

More information about the Opendnssec-user mailing list