Hi JP,
to answer the question from the subject: yes, changing the policy shall
always be a safe operation. Moreover, if you use automatic key
management, then sometimes a change in the policy may trigger some kind
of roll-over: changing algorithm kicks-off algorithm roll-over, changing
ksk-lifetime to lower value might cause immediate KSK roll-over and so
on. Knot simply starts following new rules.
You can also change the policy name, which has no meaning EXCEPT for
shared-ksk. Please don't change it if you use automatic key management
with shared KSK among zones.
You can also freely set/unset manual policy. Whenever the policy is
manual, no automatic key roll-overs take place, regardless if they are
one-time or regular. Currently running roll-over would be effectively
frozen.
I doubt anyone who can mistakenly write `knotc zone-key-rollover` can't
also mistakenly alter knot configuration :) Unfortunately, we have not
implemented any parental control yet. However, you can perhaps write
some wrapper on top of knotc to ensure limited set of knotc commands
available.
Libor
Dne 17. 07. 23 v 9:52 Jan-Piet Mens napsal(a):
I have a zone for which I'd like to ensure an admin cannot mistakenly
kick off
a KSK rollover, so I am considering setting configuring its
dnssec-policy to
one with `manual: on' which prevents even a `knotc zone-key-rollover'
on it. I
have experimented with switching `manual: on' to `manual: off', and
the idea
seems to work. I have also apparently successfully been able to alter
`ksk-lifetime', and have not noticed anything going wrong.
Based on this, I wish to know if it is considered safe to alter many
(all?) of
a policy's settings, as long as neither algorithm nor key sizes are
changed, and
whether it is safe to alter the policy itself (i.e. also change a policy
name for a zone).
ksk-lifetime, delays, rrsig-lifetimes, ksk-submission, etc.: can all
these be
changed without breaking signing of a zone?
Thank you & regards,
-JP
--
--
