ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Tweak and reword release notes

Browse Source
This commit is contained in:
Michał Kępień
2021-01-08 16:16:51 +01:00
parent 09fa1c2b4c
commit 400ab0dd0b
1 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
doc/notes/notes-current.rst
View File

@@ -34,10 +34,10 @@ Removed Features
Feature Changes
~~~~~~~~~~~~~~~
- ``ipv4only.arpa`` is now served when ``dns64`` is configured. [GL #385]
- ``ipv4only.arpa`` is now served when DNS64 is configured. [GL #385]
- It is now possible to transition a zone from secure to insecure mode
without making it bogus in the process: changing to ``dnssec-policy
without making it bogus in the process; changing to ``dnssec-policy
none;`` also causes CDS and CDNSKEY DELETE records to be published, to
signal that the entire DS RRset at the parent must be removed, as
described in RFC 8078. [GL #1750]
@@ -46,18 +46,18 @@ Feature Changes
serial number, ``named`` and ``dnssec-signzone`` silently fell back to
the ``increment`` method to prevent the new serial number from being
smaller than the old serial number (using serial number arithmetics).
``dnsssec-signzone`` now prints a warning message, and ``named`` logs
a warning, when such a fallback happens. [GL #2058]
``dnssec-signzone`` now prints a warning message, and ``named`` logs a
warning, when such a fallback happens. [GL #2058]
Bug Fixes
~~~~~~~~~
- Only assign threads to CPUs in the CPU affinity set, so that ``named`` no
longer attempts to run threads on CPUs outside the affinity set. Thanks to
Ole Bjørn Hessen. [GL #2245]
- ``named`` no longer attempts to assign threads to CPUs outside the CPU
affinity set. Thanks to Ole Bjørn Hessen. [GL #2245]
- When reconfiguring ``named``, removing ``auto-dnssec`` did actually not turn
- When reconfiguring ``named``, removing ``auto-dnssec`` did not turn
off DNSSEC maintenance. This has been fixed. [GL #2341]
- Prevent rbtdb instances being destroyed by multiple threads at the same
time. This can trigger assertion failures. [GL #2355]
- Multiple threads could attempt to destroy a single RBTDB instance at
the same time, resulting in an unpredictable but low-probability
assertion failure in ``free_rbtdb()``. This has been fixed. [GL #2317]