31 Srp
2022
31 Srp
'22
14:15
Hi André,
I understand your concerns but still you can explicitly set rrsig-refresh.
Based on our experience DNS deployments are very diverse. So what is the right default
value?
Regards,
Daniel
On 8/31/22 13:53, André Keller wrote:
Hi Libor,
On 31.08.22 13:14, libor.peltan wrote:
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 see, I guess from a knot standpoint this makes sense, but I feel this does not take
into account any potential delays that are caused by operational issues.
To paint a very simplified picture of our own architecture:
* We use Puppet Configuration management create/maintain the knot configuration on all
involved servers
* We have a hidden primary, that holds the zonedata and does the signing
* We have public secondaries that sync these zones via the normal TSIG/AXFR/IXFR
protocol
* Zonedata update on the hidden primary is done via a CI pipeline towards the hidden
primary
So for the actual "public" facing service, only the secondaries are relevant as
long as we do not need to change zonedata. That means the hidden primary also has no
redundancy built in. If it breaks,
we will simply redeploy it with puppet, rerun the pipeline and we are up and running
again. However this would take time depending on when the outage is. So having signatures
refresh early before they
expire give us some headroom there were the secondaries can serve the current zonedata
without being dependent on the primary.
Another issue I can think of, could be temporary network issues between the primary and
the secondaries.
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).
For our deployment this is not really a concern. We do not have huge zones, we just have
many of them. Also, they are mostly static. So signing performance was never an issue
until now.
I would probably prefer to set a higher rrsig-refresh as compared to increase
propagation-delay, it seems clearer to me what it does. Propagation delay for me is the
time it takes during normal
operations for all primaries and secondaries to be in sync, plus some margin for taking
into account caching on resolvers. On top of that I'd like to have some sort of safety
margin against
operational issues, so setting rrsig-refresh is probably the way we go about in the
future.
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!
As already said, at least to me propagation-delay is not what I would associate with
operational issues, I would expect all my primaries and secondary to be in sync during
normal operation well within
the default of one hour.
I guess choosing default values is always hard and I do not have an issue with making our
configuration more explicit to cover our specific use case. I just wish this, at least for
us, quite
significant change in behavior would have been made a bit more obvious in the changelog.
It caught us by suprise :)
Regards
André
--