Hello David,
the risk of changing the policy only consist by the consequence that the
zone's NSEC3s are exchanged all at once, which my cause minor hiccups
only for very large zones. For tiny ones this is negligible. Anyway, if
you use default settings, your salt is exchanged every month already
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#nsec3-salt-lifetime
(which would eventually stop when the salt is zero, because there will
be nothing more to change)
Unlike DNSSEC key roll-overs, changing salt does (or should) not involve
any consideration regarding caching resolvers.
In fact, you have third possibility:
3) do nothing and let the salt length have changed by upgrading Knot version
To elaborate the two options you mentioned:
1) add explicit salt length 8, live with that and consider changing to 0
manually later on
2) add explicit salt length 0, migrate immediately, and later on when
Knot changes the default you might want to remove the option from your
conf again
My favourite is 2).
Hope I helped!
Libor
PS: I like your train photos
On 10. 12. 24 8:47, Erwan David wrote:
Hello,
My knot 3.4.3 gives me following notice :
notice: config, policy 'rail_policy' depends on default nsec3-salt-length=8,
since version 3.5 the default becomes 0
In order to avoid problems when .5 will arrive, I see 2 possibilities:
* add an explicit nsec3-salt-length=8 to my policy
* add an explicit nsec3-salt-length=0 to my policy and resign the
zone.
From
https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec3-guidance-10.html#nam…
I understand that 0 should be the new configuration, but what are the
risks (considering eg. DNS caches) if I change the policy of the zone?
I only have small zones, with very few dynamic changes, which I can
delay for the time of the TTL if needed.