<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>
<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>
<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>