Tweak and reword release notes

This commit is contained in:
Michal Nowak 2024-10-03 18:27:30 +02:00
parent f0590dbff7
commit eb14a3b976
No known key found for this signature in database

View file

@ -24,34 +24,21 @@ New Features
Feature Changes
~~~~~~~~~~~~~~~
- Allow IXFR-to-AXFR fallback on DNS_R_TOOMANYRECORDS.
- Allow IXFR-to-AXFR fallback on ``DNS_R_TOOMANYRECORDS``.
This change allows fallback from an IXFR failure to AXFR when the
reason is `DNS_R_TOOMANYRECORDS`. This is because this error condition
could be temporary only in an intermediate version of IXFR
transactions and it's possible that the latest version of the zone
doesn't have that condition. In such a case, the secondary would never
be able to update the zone (even if it could) without this fallback.
This fallback behavior is particularly useful with the recently
introduced `max-records-per-type` and `max-types-per-name` options:
the primary may not have these limitations and may temporarily
introduce "too many" records, breaking IXFR. If the primary side
subsequently deletes these records, this fallback will help recover
the zone transfer failure automatically; without it, the secondary
side would first need to increase the limit, which requires more
operational overhead and has its own adverse effect. :gl:`#4928`
reason is ``DNS_R_TOOMANYRECORDS``. :gl:`#4928`
Bug Fixes
~~~~~~~~~
- Fix a statistics channel counter bug when 'forward only' zones are
- Fix a statistics channel counter bug when "forward only" zones are
used.
When resolving a zone with a 'forward only' policy, and finding out
that all the forwarders are marked as "bad", the 'ServerQuota' counter
of the statistics channel was incorrectly increased. This has been
fixed. :gl:`#1793`
When resolving a zone with a "forward only" policy, and finding out
that all the forwarders were marked as "bad", the "ServerQuota"
counter of the statistics channel was incorrectly increased. This has
been fixed. :gl:`#1793`
- Fix a bug in the static-stub implementation.
@ -61,29 +48,26 @@ Bug Fixes
addresses being used instead of the correct server addresses.
:gl:`#4850`
- Don't allow statistics-channel if libxml2 and libjson-c are
unsupported.
- Don't allow :any:`statistics-channels` if libxml2 and libjson-c are
not configured.
When the libxml2 and libjson-c libraries are not supported, the
statistics channel can't return anything useful, so it is now
disabled. Use of `statistics-channel` in `named.conf` is a fatal
error. :gl:`#4895`
When BIND 9 is not configured with the libxml2 and libjson-c
libraries, the use of the :any:`statistics-channels` option is a fatal
error. :gl:`#4895`
- Limit the outgoing UDP send queue size.
If the operating system UDP queue gets full and the outgoing UDP
sending starts to be delayed, BIND 9 could exhibit memory spikes as it
tries to enqueue all the outgoing UDP messages. Try a bit harder to
deliver the outgoing UDP messages synchronously and if that fails,
drop the outgoing DNS message that would get queued up and then
If the operating system UDP queue got full and the outgoing UDP
sending started to be delayed, BIND 9 could exhibit memory spikes as
it tried to enqueue all the outgoing UDP messages. It now tries to
deliver the outgoing UDP messages synchronously; if that fails, it
drops the outgoing DNS message that would get queued up and then
timeout on the client side. :gl:`#4930`
- Do not set SO_INCOMING_CPU.
- Do not set ``SO_INCOMING_CPU``.
We currently set SO_INCOMING_CPU incorrectly, and testing by Ondrej
shows that fixing the issue by setting affinities is worse than
letting the kernel schedule threads without constraints. So we should
not set SO_INCOMING_CPU anymore. :gl:`#4936`
Remove the ``SO_INCOMING_CPU`` setting as kernel scheduling performs
better without constraints. :gl:`#4936`
Known Issues