[knot-dns-users] Re: policy.rrsig-refresh in Knot 3.2.0

Hi André, thanks much for your concern in operational aspects of Knot DNS. The point of recent change in rrsig-refresh default is to actually align it with other closely related options, to make it suitable in wider range of configurations. It's obvious that 7d may be often too high or too low. What rrsig-refresh actually serves for, is to refresh RRSIGs soon enough, so they they don't expire due to delays in: 1) propagation among authoritative servers, that means synchronization of secondaries with primaries, including e.g. the lengthy process of signing itself (in case of huge zone) 2) propagation to resolvers' caches When I thought about this, I actually saw that (1) is exactly propagation-delay and (2) is exactly the RRSIG's TTL. Setting rrsig-refresh default to the sum of both values was a logical conclusion. I'd say that the setting of propagation-delay is still in your hands, as well as setting non-default rrsig-refresh. The only disadvantage of too high rrsig-refresh is that zone signing takes place more often and creates larger change-sets to be propagated to secondaries. In other words, utilizing more of all resources (CPU, memory, disk, network). Anyway, we already received concerns about this change. Another argument was that in their case, the rrsig-refresh ought to also cover possible outages of otherwise regular signing process (signer server down). It is a philosophical question if propagation-delay should cover those as well. This all makes me think if the one-hour default of propagation-delay is maybe not optimal...? Please let me know your ideas/opinions in more detail. Any real operational experience is very very valuable for us! Thank you, Libor Dne 31. 08. 22 v 10:47 André Keller napsal(a):