Tweak and reword release notes

diff --git a/doc/notes/notes-9.20.3.rst b/doc/notes/notes-9.20.3.rst
index c517e7e4ef9264713ed7d93017ae979fa7de87c0..639250794c73f54d15c55a2d2c9b3df90bb1fda9 100644 (file)
--- a/doc/notes/notes-9.20.3.rst
+++ b/doc/notes/notes-9.20.3.rst
@@ -17,9 +17,9 @@ New Features
 
 - Log query response status to the query log.
 
-  Log a query response summary using the new category `responses`.
-  Logging can be controlled by the option `responselog` and `rndc
-  responselog`. :gl:`#459`
+  Log a query response summary using the new ``responses`` category.
+  Logging can be controlled via the :any:`responselog` option and via
+  :option:`rndc responselog`. :gl:`#459`
 
 - Added WALLET type.
 
@@ -30,40 +30,27 @@ New Features
 Feature Changes
 ~~~~~~~~~~~~~~~
 
-- Set logging category for notify/xfer-in related messages.
+- Set logging category for ``notify``/``xfer-in``-related messages.
 
-  Some 'notify' and 'xfer-in' related log messages were logged at the
-  'general' category instead of their own category. This has been fixed.
-  :gl:`#2730`
+  Some ``notify`` and ``xfer-in``-related log messages were logged at
+  the "general" category level instead of their own category. This has
+  been fixed.  :gl:`#2730`
 
-- 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.
 
@@ -73,79 +60,66 @@ 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`
 
-- Separate DNSSEC validation from the long-running tasks.
+- Separate DNSSEC validation from long-running tasks.
 
-  As part of the KeyTrap \[CVE-2023-50387\] mitigation, the DNSSEC CPU-
-  intensive operations were offloaded to a separate threadpool that we
-  use to run other tasks that could affect the networking latency.
+  Split CPU-intensive and long-running tasks into separate threadpools
+  in a way that the long-running tasks - like RPZ, catalog zone
+  processing, or zone file operations - don't block CPU-intensive
+  operations like DNSSEC validations. :gl:`#4898`
 
-  If that threadpool is running some long-running tasks like RPZ,
-  catalog zone processing, or zone file operations, it would delay
-  DNSSEC validations to a point where the resolving signed DNS records
-  would fail.
+- Fix an assertion failure when processing access control lists.
 
-  Split the CPU-intensive and long-running tasks into separate
-  threadpools in a way that the long-running tasks don't block the CPU-
-  intensive operations. :gl:`#4898`
+  The :iscman:`named` process could terminate unexpectedly when
+  processing ACLs.  This has been fixed. :gl:`#4908`
 
-- Fix assertion failure when processing access control lists.
+- Fix a bug in Offline KSK using a ZSK with an unlimited lifetime.
 
-  The named process could terminate unexpectedly when processing access
-  control lists (ACLs). This has been fixed. :gl:`#4908`
-
-- Fix bug in Offline KSK that is using ZSK with unlimited lifetime.
-
-  If the ZSK has unlimited lifetime, the timing metadata "Inactive" and
-  "Delete" cannot be found and is treated as an error, preventing the
-  zone to be signed. This has been fixed. :gl:`#4914`
+  If the ZSK had an unlimited lifetime, the timing metadata ``Inactive``
+  and ``Delete`` could not be found and were treated as an error,
+  preventing the zone from being signed. This has been fixed.
+  :gl:`#4914`
 
 - 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`
 
-- Fix the 'rndc dumpdb' command's error reporting.
+- Fix the :option:`rndc dumpdb` command's error reporting.
 
-  The 'rndc dumpdb' command wasn't reporting errors which occurred when
-  starting up the database dump process by named, like, for example, a
-  permission denied error for the 'dump-file' file. This has been fixed.
-  Note, however, that 'rndc dumpdb' performs asynchronous writes, so
-  errors can also occur during the dumping process, which will not be
-  reported back to 'rndc', but which will still be logged by named.
-  :gl:`#4944`
+  The :option:`rndc dumpdb` command was not reporting errors that
+  occurred when :iscman:`named` started up the database dump process.
+  This has been fixed. :gl:`#4944`
 
 - Fix long-running incoming transfers.
 
   Incoming transfers that took longer than 30 seconds would stop reading
   from the TCP stream and the incoming transfer would be indefinitely
-  stuck causing BIND 9 to hang during shutdown.
+  stuck, causing BIND 9 to hang during shutdown.
 
-  This has been fixed and the `max-transfer-time-in` and `max-transfer-
-  idle-in` timeouts are now honoured. :gl:`#4949`
+  This has been fixed, and the :any:`max-transfer-time-in` and
+  :any:`max-transfer-idle-in` timeouts are now honored. :gl:`#4949`
 
-- Fix assertion failure when receiving DNS responses over TCP.
+- Fix an assertion failure when receiving DNS responses over TCP.
 
   When matching the received Query ID in the TCP connection, an invalid
-  received Query ID can very rarely cause assertion failure. :gl:`#4952`
+  Query ID could cause an assertion failure. This has been fixed.
+  :gl:`#4952`
 
 
 Known Issues