31 Srp
2022
31 Srp
'22
15:52
Hi,
let me elaborate more on propagation-delay, as it seems that almost
nobody fully understands it, including possibly me :)
This option has been invented with first (ZSK) key roll-overs, and it
roughly means "anything that can happen between a change in key set, and
the resulting publication of newly signed zone in all public-facing
secondaries".
I oppose to the idea that this is limited to normal, fully operational
state of all the involved services.
Imagine a case when a server breaks down just after new key had been
generated, preventing any further propagation. You need to take some
action, repair your services and just after that, it takes the normal
amount of minutes to propagate the zone to public secondaries. The
signer proceeds with next key roll-over step in (propagation-delay +
DNSKEY TTL) after the key generation. If all the previous is not covered
by propagation-delay, it might happen (not probably, but possibly) that
the public secondaries receive the two updates (new key published, and
new key activated+old retired) in too close succession, leading to
possible temporary bogus at some validating resolvers.
Do you understand this scenario and agree with my thoughts?
This all suggest that we shall focus more on propagation-delay setting,
and even its default. However, if my thoughts are correct, proper
setting of propagation-delay implies that the calculated rrsig-refresh
is automatically correct. A question might follow, why rrsig-refresh
option even exists? One explanation might be, that it has been invented
first. Automatic key roll-overs are way younger than automatic RRSIG
refresh. While it's possible to calculate rrsig-refresh from
propagation-delay, it's not possible the other way.
Let me know what you think.
Libor
Dne 31. 08. 22 v 14:30 André Keller napsal(a):
Hi Daniel,
On 31.08.22 14:15, Daniel Salzman wrote:
I understand your concerns but still you can
explicitly set
rrsig-refresh.
Absolutely, as I said I'm happy to adjust the configuration to fit our
specific deployment. I'm just unsure if rrsig-refresh or
propagation-delay is the correct option to tune. Seems I'm
interpreting the options differently than Libor does.
Based on our experience DNS deployments are very
diverse. So what is
the right default value?
I do not think that the new default value is necessarily bad, it is
just that it was a significant change that we did not recognize as
such. For our specific use case, the old default fit perfectly, but
I'm definitely aware that this might not be the case for everyone and
I do not propose to go back to the old default.
Maybe would make sense to include some considerations for this value
in the docs to give people a bit more guidance for tuning this aspect
of the DNSSEC policy.
Regards
André
--