On 2021-04-30 18:14, Havard Eidnes wrote:
Relevant commands:
vi kasp.xml
ods-enforcer policy import
ods-enforcer zone set-policy -z example.com -p newpolicy
ods-enforcer enforce -z example.com
One caveat to think of, I probably wouldn't use this on
combined signing keys (CSKs).
If possible test this first, we've used set-policy but not for
this specific case AFAIK.
Hmm, this probably means that the wiki page at
https://wiki.opendnssec.org/display/DOCS/kasp.xml
with the notice
Once a zone is signed, changes to the algorithm require a
rollover which is not currently handled by OpenDNSSEC. Attempts
to change the algorithm on a policy will result in a warning
message and a request for confirmation.
needs an update? In particular it would seem that "is not
currently handled by OpenDNSSEC" is no longer true?
Yes, that needs updting, I think elsewhere it is explicitly states
to be supported. I think the entire wiki is to be revamped.
I realize this is a wiki, and as far as I recall I do have
editing privileges, so I can do the actual editing, but I'm
hesitating to do that without getting any feedback first.
So ... I tried specifying algorithm 14 (ECDSA P-384) for KSK with
a 1 year rotation, and algorithm 13 (ECDSA P-256) for ZSK with a
1 month rotation. Isn't that supposed to be supported? Or is
there something in the protocol specification which says that you
must have the same algorithm for KSK and ZSK? (I didn't think so.)
Also, no comment on this?
Need to test, this situation. I know some people have transfered to
ECDSA, but haven't been in this process. There is no direct relation
between key algorithms here.
I caved in, and specified algorithm 13 (ECDSA P-256) for both KSK
and ZSK on my test system, and did as specified above: created an
"ecdsa" policy specifying algorithm 13 and then:
ods-enforcer zone set-policy -z urc.uninett.no -p ecdsa
ods-enforcer enforce -z urc.uninett.no
I'm now one week later looking at the state of the keys with
ods-enforcer, and while the new KSK is generated and sits in the
zone, it doesn't look like OpenDNSSEC is doing a KSK roll-over to
complete the algorithm roll-over. Is it waiting for the normal
roll-over time to come for the zone, and *then* doing the KSK
roll-over? That seems counter-intuitive; I would have expected
that when I did "set-policy" and "enforce", it would realize that
I did indeed ask for a KSK with a new algorithm, and that an
automatic roll-over should be initiated immediately instead of
waiting for the normal rotation time previously specified (which
in my case is 1 year). State of the keys for the zone now look
like this:
Yes it is still waiting for a normal rollover period. Could be
a number of parameters in the kasp, such as long SOA or DNSKEY
TTL, publish safety. I'm working on a better insight for the
date of next transition to show why and when a transition for
which key is done. But turned out to be more work.
ods @ test-signer: {16} ods-enforcer key list -z urc.uninett.no -v
Keys:
Zone: Keytype: State: Date of next
transition: Size: Algorithm: CKA_ID:
Repository: KeyTag:
urc.uninett.no KSK active 2021-04-30 17:57:54
2048 8 60c393e7b35db5a0e9cf4a841693858f SoftHSM
46540
urc.uninett.no ZSK retire 2021-04-30 17:57:54
1280 8 1a81c8138fc886c7c84e8ebcd49a386a SoftHSM
9730
urc.uninett.no ZSK ready 2021-04-30 17:57:54
1280 8 4bbb93962f7bce0138c890889bff48b9 SoftHSM
42331
urc.uninett.no KSK publish 2021-04-30 17:57:54
2048 13 1605e5edf3e2c9b022010386419f624a SoftHSM
42582
urc.uninett.no ZSK ready 2021-04-30 17:57:54
1536 13 efd1db8fac425422cc8b5b8ad6837d2b SoftHSM
42185
ods @ test-signer: {17} ods-enforcer key list -z urc.uninett.no -d
Keys:
Zone: Key role: DS: DNSKEY:
RRSIGDNSKEY: RRSIG: Pub: Act: Id:
urc.uninett.no KSK omnipresent omnipresent
omnipresent NA 1 1 60c393e7b35db5a0e9cf4a841693858f
urc.uninett.no ZSK NA omnipresent
NA unretentive 1 0 1a81c8138fc886c7c84e8ebcd49a386a
urc.uninett.no ZSK NA omnipresent
NA rumoured 1 1 4bbb93962f7bce0138c890889bff48b9
urc.uninett.no KSK hidden rumoured
rumoured NA 1 1 1605e5edf3e2c9b022010386419f624a
urc.uninett.no ZSK NA rumoured
NA rumoured 1 1 efd1db8fac425422cc8b5b8ad6837d2b
ods @ test-signer: {18} ods-enforcer key list -z urc.uninett.no
Keys:
Zone: Keytype: State: Date of next
transition:
urc.uninett.no KSK active 2021-04-30 17:58:55
urc.uninett.no ZSK retire 2021-04-30 17:58:55
urc.uninett.no ZSK ready 2021-04-30 17:58:55
urc.uninett.no KSK publish 2021-04-30 17:58:55
urc.uninett.no ZSK ready 2021-04-30 17:58:55
ods @ test-signer: {19}
And, as per usual for OpenDNSSEC2 the "Date of next transition"
no longer means that, apparently.
I'm initially waiting for a "waiting for ds-seen" state here for
the new KSK, and it's not showing up.
Do I have to manually initiate a KSK roll-over with
ods-enforcer key rollover --zone urc.uninett.no --keytype KSK
to get things moving along?
Best regards,
- Håvard
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
