TTL tweaks

I've been reluctant to do (some of) these changes in a patch-version update, so this has been hibernating, but let me open a MR already.

Fixes #127 (closed); fixes #736 (closed). (and other TTL-related changes)

The earlier choice was applying TTL bounds only when caching. That makes some sense from implementation point of view, but I can't see any motivation to behave that way and treat the first answer differently.

So now, when I set e.g. config.min_ttl(1000), TTL stays on 1000 on repeated queries as well. Is that the behaviour we want?

I personally expected this to fix the queries that caused new records to be inserted into cache, so that even that first answer has TTL modified by min_ttl and max_ttl (instead of it being the upstream value), but subsequent queries would still count down, as it was before. Now, we're delaying updates of downstream resolvers, so that even when kresd only has a few seconds remaining on a cached record, the downstream resolver will still potentially cache it for min_ttl amount of time. The way I see it that might or might not be the desired behaviour depending on what the user wants to achieve.

marked this merge request as draft

added 1 commit

• 882e0587 - fixup! TTL bounds: improve the logic

Compare with previous version

resolved all threads

approved this merge request

There are still some issues in behavior, which is why I left it marked as draft.

unapproved this merge request

added 88 commits

• 882e0587...48451459 - 84 commits from branch master
• adc65785 - lib/cache: tweak TTL computation for packets
• eae7c327 - cache.max_ttl(): lower the default from six days to one day
• ae1a64f1 - TTL bounds: improve the logic
• 8ce35c3f - NEWS + doc about TTL: apply changes from previous commits

Compare with previous version

added 4 commits

• 48ab4d36 - lib/cache: tweak TTL computation for packets
• bb6e2de2 - cache.max_ttl(): lower the default from six days to one day
• a4455c78 - TTL bounds: improve the logic
• bc0cf66b - NEWS + doc about TTL: apply changes from previous commits

Compare with previous version

resolved all threads

marked this merge request as ready

merged

mentioned in commit 7ad8b83b

Since months ago I just added the missing generated diff for libknot 3.2, and I slightly tweaked the NEWS and docs.

mentioned in merge request !1369 (merged)