[Opendnssec-user] Changing policy for some domains

[Berry van Halderen]

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