lib/dnssec/nsec3.h | 7 2 + 5 - 0 !
1 file changed, 2 insertions(+), 5 deletions(-)

 validator: lower the nsec3 iteration limit (150 -> 50)

Also done by BIND9 >= 9.19.19:
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8515

The latest real-life measurements show that values above 50 are rare:
https://chat.dns-oarc.net/community/pl/aadp9wwrp7g7ux1b8chbzebmze

lib/cache/api.c | 2 1 + 1 - 0 !
lib/cache/nsec3.c | 2 1 + 1 - 0 !
lib/dnssec/nsec3.c | 4 2 + 2 - 0 !
lib/dnssec/nsec3.h | 32 28 + 4 - 0 !
lib/layer/validate.c | 7 4 + 3 - 0 !
5 files changed, 36 insertions(+), 11 deletions(-)

 validator: similarly also limit excessive nsec3 salt length

Limit combination of iterations and salt length, based on estimated

lib/cache/nsec3.c | 14 14 + 0 - 0 !
lib/dnssec/nsec3.h | 12 12 + 0 - 0 !
2 files changed, 26 insertions(+)

 lib/cache: limit the amount of work on sha1

That's when searching NSEC3 aggressive cache.

lib/dnssec/nsec3.c | 12 12 + 0 - 0 !
1 file changed, 12 insertions(+)

 validator: limit the amount of work on sha1 in nsec3 proofs

lib/layer/validate.c | 18 18 + 0 - 0 !
1 file changed, 18 insertions(+)

 validator: refuse to validate answers with more than 8 nsec3 records

lib/layer/validate.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 validator: compatibility with older libknot versions

The value is in IANA registry, so it's very constant anyway.

lib/cache/api.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 lib/cache: bump cache_version

Ideally we would've done that at once with increasing NSEC3 strictness,
i.e. in 5.7.1 + 6.0.6, as otherwise we could run into some recoverable
assertions until the records got removed or expired.
We at least do the bump now.

lib/dnssec.c | 11 5 + 6 - 0 !
1 file changed, 5 insertions(+), 6 deletions(-)

 lib/dnssec kr_rrset_validate_with_key(): deduplicate cleanup

lib/resolve.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 lib/resolve kr_request_set_extended_error(): tweak priorities

Keep the first error in case priorities are equal.

At least with the current KeyTrap topic that should work better,
but blaming a single error is alchemy anyway, at least in some cases.

daemon/engine.c | 1 1 + 0 - 0 !
daemon/lua/kres-gen-30.lua | 3 3 + 0 - 0 !
daemon/lua/kres-gen-31.lua | 3 3 + 0 - 0 !
daemon/lua/kres-gen-32.lua | 3 3 + 0 - 0 !
lib/defines.h | 2 2 + 0 - 0 !
lib/dnssec.c | 28 28 + 0 - 0 !
lib/dnssec.h | 1 1 + 0 - 0 !
lib/layer/validate.c | 7 7 + 0 - 0 !
lib/resolve.h | 3 3 + 0 - 0 !
lib/rplan.h | 6 6 + 0 - 0 !
10 files changed, 57 insertions(+)

 mitigate keytrap dos = cve-2023-50387

lib/dnssec.c | 7 4 + 3 - 0 !
lib/layer/validate.c | 4 4 + 0 - 0 !
lib/resolve.c | 4 3 + 1 - 0 !
3 files changed, 11 insertions(+), 4 deletions(-)

 mitigate keytrap dos = cve-2023-50387

Improve: don't retry in this case.

lib/dnssec.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 lib/dnssec: fix imprecise assertion

It was no longer correct after commit cc5051b444130 (KeyTrap).

daemon/io.c | 38 10 + 28 - 0 !
daemon/session.c | 26 21 + 5 - 0 !
daemon/session.h | 5 3 + 2 - 0 !
3 files changed, 34 insertions(+), 35 deletions(-)

 daemon: more avoidance of excessive tcp reconnections

Previously this penalization was only triggered if the remote server
closed TCP.  Now it's extended to us closing it when the server
(only) sends back some nonsense.  At least for the cases which I could
see immediately.

That's just three trivial one-line additions; the rest is refactoring.