[Opendnssec-user] Changing policy for some domains

[Havard Eidnes]

>> 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?

No comment on that?

Admittedly, the above recipe doesn't change the algorithm in an
existing policy, but suggests creating a new policy for the new
algorithm and then setting zones to use the new policy instead of
the old one, so technically it's not *exactly* doing what the
notice warns about as "unhandled", but ... the comment also isn't
helpful in suggesting how one might go about doing an algorithm
roll-over which usually is what's asked about in this context.

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?

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:

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