Tweak release notes for BIND 9.16.2

This commit is contained in:
Stephen Morris 2020-04-08 22:49:00 +02:00 committed by Michał Kępień
parent aeb1eb20e8
commit 2b79ffb29c

View file

@ -15,9 +15,9 @@
<itemizedlist>
<listitem>
<para>
DNS rebinding protection was ineffective when BIND 9 is configured as
a forwarding DNS server. Found and responsibly reported by Tobias
Klein. [GL #1574]
DNS rebinding protection was ineffective when BIND 9 is configured as
a forwarding DNS server. Found and responsibly reported by Tobias
Klein. [GL #1574]
</para>
</listitem>
</itemizedlist>
@ -27,29 +27,25 @@
<itemizedlist>
<listitem>
<para>
None.
We have received reports that in some circumstances, receipt of an
IXFR can cause the processing of queries to slow significantly. Some
of these were related to RPZ processing, which has been fixed in this
release (see below). Others appear to occur where there are
NSEC3-related changes (such as an operator changing the NSEC3 salt
used in the hash calculation). These are being investigated.
[GL #1685]
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="relnotes-9.16.2-new"><info><title>New Features</title></info>
<itemizedlist>
<listitem>
<para>
None.
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="relnotes-9.16.2-changes"><info><title>Feature Changes</title></info>
<itemizedlist>
<listitem>
<para>
The DNSSEC sign statistics used lots of memory. The number of keys
to track is reduced to four per zone, which should be enough for
99% of all signed zones. [GL #1179]
The previous DNSSEC sign statistics used lots of memory. The number of
keys to track is reduced to four per zone, which should be enough for
99% of all signed zones. [GL #1179]
</para>
</listitem>
</itemizedlist>
@ -59,20 +55,25 @@
<itemizedlist>
<listitem>
<para>
When an RPZ policy zone was updated via zone transfer
and a large number of records were deleted, <command>named</command>
could become nonresponsive for a short period while deleted
names were removed from the RPZ summary database. This database
cleanup is now done incrementally over a longer period of time,
reducing such delays. [GL #1447]
When an RPZ policy zone was updated via zone transfer and a large
number of records was deleted, <command>named</command> could become
nonresponsive for a short period while deleted names were removed from
the RPZ summary database. This database cleanup is now done
incrementally over a longer period of time, reducing such delays.
[GL #1447]
</para>
</listitem>
<listitem>
<para>
Migration to dnssec-policy from existing DNSSEC strategy with
auto-dnssec maintain did not work due to bad initializing of the
key states. Fixed by looking closely at the time metadata to
set the key states to the correct values. [GL #1706]
When trying to migrate an already-signed zone from
<command>auto-dnssec maintain</command> to one based on
<command>dnssec-policy</command>, the existing keys were immediately
deleted and replaced with new ones. As the key rollover timing
constraints were not being followed, it was possible that some clients
would not have been able to validate responses until all old DNSSEC
information had timed out from caches. BIND now looks at the time
metadata of the existing keys and incorporates it into its DNSSEC
policy operation. [GL #1706]
</para>
</listitem>
</itemizedlist>