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

Tweak release notes for BIND 9.17.1

Browse Source
This commit is contained in:
Stephen Morris
2020-04-08 22:12:57 +02:00
committed by Michał Kępień
parent dfe4009c30
commit 623b6c94c0
1 changed files with 39 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
doc/arm/notes-9.17.1.xml
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,7 +27,13 @@
<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>
@@ -37,8 +43,17 @@
<itemizedlist>
<listitem>
<para>
None.
</para>
A new option, <command>nsdname-wait-recurse</command>, has been added
to the <command>response-policy</command> clause in the configuration
file. When set to <command>no</command>, RPZ NSDNAME rules are only
applied if the authoritative nameservers for the query name have been
looked up and are present in the cache. If this information is not
present, the RPZ NSDNAME rules are ignored, but the information is
looked up in the background and applied to subsequent queries. The
default is <command>yes</command>, meaning that RPZ NSDNAME rules
should always be applied, even if the information needs to be looked
up first. [GL #1138]
</para>
</listitem>
</itemizedlist>
</section>
@@ -47,9 +62,9 @@
<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 +74,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>