Merge branch 'prep-release' into v9_16_10-release

Prepare release notes for BIND 9.16.10

See merge request isc-private/bind9!225

CHANGES

@@ -1,5 +1,7 @@
-5544.	[func]		Restore the default value of nocookie-udp-size to 4096.
-			[GL #2250]
+	--- 9.16.10 released ---
+
+5544.	[func]		Restore the default value of "nocookie-udp-size" to 4096
+			bytes. [GL #2250]
 
 5541.	[func]		Adjust the "max-recursion-queries" default from 75 to
 			100. [GL #2305]
@@ -10,14 +12,13 @@
 5539.	[bug]		Tighten handling of missing DNS COOKIE responses over
 			UDP by falling back to TCP. [GL #2275]
 
-5538.	[func]		Add NSEC3 support for zones that manage DNSSEC with
-			the 'dnssec-policy' configuration. A new option
-			'nsec3param' can be used to set the NSEC3 parameters.
-			This now also detects salt collisions, and logs salt
-			generation messages with zone context.
-			[GL #1620]
+5538.	[func]		Add NSEC3 support to KASP. A new option for
+			"dnssec-policy", "nsec3param", can be used to set the
+			desired NSEC3 parameters. NSEC3 salt collisions are
+			automatically prevented during resalting. Salt
+			generation is now logged with zone context. [GL #1620]
 
-5534.	[bug]		The synthesised CNAME from a DNAME was incorrectly
+5534.	[bug]		The CNAME synthesized from a DNAME was incorrectly
 			followed when the QTYPE was CNAME or ANY. [GL #2280]
 
 	--- 9.16.9 released ---

CONTRIBUTING

@@ -30,8 +30,8 @@ BIND is maintained by Internet Systems Consortium, a public-benefit 501(c)
 source, but only ISC employees have commit access. In the past, the source
 could only be seen once ISC had published a release; read access to the
 source repository was restricted just as commit access was. That has
-changed, as ISC now provides a public git mirror to the BIND source tree
-(see below).
+changed, as ISC now provides a public git repository of the BIND source
+tree (see below).
 
 At ISC, we're committed to building communities that are welcoming and
 inclusive: environments where people are encouraged to share ideas, treat
@@ -44,13 +44,11 @@ Access to source code
 
 Public BIND releases are always available from the ISC FTP site.
 
-A public-access GIT repository is also available at https://gitlab.isc.org
-. This repository is a mirror, updated several times per day, of the
-source repository maintained by ISC. It contains all the public release
-branches; upcoming releases can be viewed in their current state at any
-time. It does not contain development branches or unreviewed work in
-progress. Commits which address security vulnerablilities are withheld
-until after public disclosure.
+A public-access git repository is also available at https://gitlab.isc.org
+. This repository contains all public release branches. Upcoming releases
+can be viewed in their current state at any time. Short-lived development
+branches contain unreviewed work in progress. Commits which address
+security vulnerablilities are withheld until after public disclosure.
 
 You can browse the source online via https://gitlab.isc.org/isc-projects/
 bind9

CONTRIBUTING.md

@@ -39,7 +39,7 @@ anyone can see the source, but only ISC employees have commit access.
 In the past, the source could only be seen once ISC had published
 a release; read access to the source repository was restricted just
 as commit access was.  That has changed, as ISC now provides a
-public git mirror to the BIND source tree (see below).
+public git repository of the BIND source tree (see below).
 
 At ISC, we're committed to
 building communities that are welcoming and inclusive: environments where people
@@ -55,14 +55,12 @@ the industry.
 Public BIND releases are always available from the
 [ISC FTP site](ftp://ftp.isc.org/isc/bind9).
 
-A public-access GIT repository is also available at
-[https://gitlab.isc.org](https://gitlab.isc.org).
-This repository is a mirror, updated several times per day, of the
-source repository maintained by ISC.  It contains all the public release
-branches; upcoming releases can be viewed in their current state at any
-time.  It does *not* contain development branches or unreviewed work in
-progress.  Commits which address security vulnerablilities are withheld
-until after public disclosure.
+A public-access git repository is also available at
+[https://gitlab.isc.org](https://gitlab.isc.org).  This repository
+contains all public release branches. Upcoming releases can be viewed in
+their current state at any time.  Short-lived development branches
+contain unreviewed work in progress.  Commits which address security
+vulnerablilities are withheld until after public disclosure.
 
 You can browse the source online via
 [https://gitlab.isc.org/isc-projects/bind9](https://gitlab.isc.org/isc-projects/bind9)

PLATFORMS

@@ -54,7 +54,7 @@ The following are platforms on which BIND is known to build and run. ISC
 makes every effort to fix bugs on these platforms, but may be unable to do
 so quickly due to lack of hardware, less familiarity on the part of
 engineering staff, and other constraints. With the exception of Windows
-Server 2012 R2, none of these are tested regularly by ISC.
+Server 2016, none of these are tested regularly by ISC.
 
   * Windows Server 2012 R2, 2016 / x64
   * Windows 10 / x64

PLATFORMS.md

@@ -61,7 +61,7 @@ The following are platforms on which BIND is known to build and run.
 ISC makes every effort to fix bugs on these platforms, but may be unable to
 do so quickly due to lack of hardware, less familiarity on the part of
 engineering staff, and other constraints. With the exception of Windows
-Server 2012 R2, none of these are tested regularly by ISC.
+Server 2016, none of these are tested regularly by ISC.
 
 * Windows Server 2012 R2, 2016 / x64
 * Windows 10 / x64

configure

@@ -17815,7 +17815,6 @@ esac
 
 
 
-
 DNS_CRYPTO_LIBS="$DNS_GSSAPI_LIBS"
 
 #
@@ -22304,7 +22303,6 @@ BIND9_MAJOR="MAJOR=${MAJORVER}.${MINORVER}"
 BIND9_VERSIONSTRING="${PRODUCT} ${MAJORVER}.${MINORVER}${PATCHVER:+.}${PATCHVER}${RELEASETYPE}${RELEASEVER}${EXTENSIONS}${DESCRIPTION:+ }${DESCRIPTION}"
 
 
-
 BIND9_SRCID="SRCID=unset_id"
 if test -f "${srcdir}/srcid"; then
 	. "${srcdir}/srcid"

doc/arm/notes.rst

@@ -59,7 +59,7 @@ https://www.isc.org/download/. There you will find additional
 information about each release, source code, and pre-compiled versions
 for Microsoft Windows operating systems.
 
-.. include:: ../notes/notes-current.rst
+.. include:: ../notes/notes-9.16.10.rst
 .. include:: ../notes/notes-9.16.9.rst
 .. include:: ../notes/notes-9.16.8.rst
 .. include:: ../notes/notes-9.16.7.rst

doc/arm/reference.rst

@@ -4738,235 +4738,200 @@ can be found, the initializing key is also compiled directly into
 
 .. _dnssec_policy_grammar:
 
+``dnssec-policy`` Statement Grammar
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 .. include:: ../misc/dnssec-policy.grammar.rst
 
 .. _dnssec_policy:
 
-The ``dnssec-policy`` statement defines a key and
-signing policy (KASP) for zones.
+``dnssec-policy`` Statement Definition and Usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A KASP determines how one or more zones is signed
-with DNSSEC. For example, it specifies how often keys should
-roll, which cryptographic algorithms to use, and how often RRSIG
-records need to be refreshed.
+The ``dnssec-policy`` statement defines a key and signing policy (KASP)
+for zones.
 
-Keys are not shared among zones, which means that one set of keys
-per zone is generated even if they have the same policy.
-If multiple views are configured with different versions of the
-same zone, each separate version uses the same set of signing
-keys.
+A KASP determines how one or more zones are signed with DNSSEC.  For
+example, it specifies how often keys should roll, which cryptographic
+algorithms to use, and how often RRSIG records need to be refreshed.
 
-Multiple key and signing policies can be configured.  To
-attach a policy to a zone, add a ``dnssec-policy``
-option to the ``zone`` statement, specifying the
-name of the policy that should be used.
+Keys are not shared among zones, which means that one set of keys per
+zone is generated even if they have the same policy.  If multiple views
+are configured with different versions of the same zone, each separate
+version uses the same set of signing keys.
 
-Key rollover timing is computed for each key according to
-the key lifetime defined in the KASP.  The lifetime may be
-modified by zone TTLs and propagation delays, to
-prevent validation failures.  When a key reaches the end of its
-lifetime,
-``named`` generates and publishes a new key
-automatically, then deactivates the old key and activates the
-new one, and finally retires the old key according to a computed
-schedule.
+Multiple key and signing policies can be configured.  To attach a policy
+to a zone, add a ``dnssec-policy`` option to the ``zone`` statement,
+specifying the name of the policy that should be used.
 
-Zone-signing key (ZSK) rollovers require no operator input.
-Key-signing key (KSK) and combined-signing key (CSK) rollovers
-require action to be taken to submit a DS record to the parent.
-Rollover timing for KSKs and CSKs is adjusted to take into account
-delays in processing and propagating DS updates.
+Key rollover timing is computed for each key according to the key
+lifetime defined in the KASP.  The lifetime may be modified by zone TTLs
+and propagation delays, to prevent validation failures.  When a key
+reaches the end of its lifetime, ``named`` generates and publishes a new
+key automatically, then deactivates the old key and activates the new
+one; finally, the old key is retired according to a computed schedule.
 
-There are two predefined ``dnssec-policy`` names:
-``none`` and ``default``.
-Setting a zone's policy to
-``none`` is the same as not setting
-``dnssec-policy`` at all; the zone is not
-signed.  Policy ``default`` causes the
-zone to be signed with a single combined-signing key (CSK)
-using algorithm ECDSAP256SHA256; this key has an
-unlimited lifetime. (A verbose copy of this policy
-may be found in the source tree, in the file
-``doc/misc/dnssec-policy.default.conf``.)
+Zone-signing key (ZSK) rollovers require no operator input.  Key-signing
+key (KSK) and combined-signing key (CSK) rollovers require action to be
+taken to submit a DS record to the parent.  Rollover timing for KSKs and
+CSKs is adjusted to take into account delays in processing and
+propagating DS updates.
 
-.. note::
+There are two predefined ``dnssec-policy`` names: ``none`` and
+``default``.  Setting a zone's policy to ``none`` is the same as not
+setting ``dnssec-policy`` at all; the zone is not signed.  Policy
+``default`` causes the zone to be signed with a single combined-signing
+key (CSK) using algorithm ECDSAP256SHA256; this key has an unlimited
+lifetime.  (A verbose copy of this policy may be found in the source
+tree, in the file ``doc/misc/dnssec-policy.default.conf``.)
 
-   The default signing policy may change in future releases.
-   This could require changes to a signing policy
-   when upgrading to a new version of BIND. Check
-   the release notes carefully when upgrading to be informed
-   of such changes. To prevent policy changes on upgrade,
-   use an explicitly defined ``dnssec-policy``,
-   rather than ``default``.
+.. note:: The default signing policy may change in future releases.
+   This could require changes to a signing policy when upgrading to a
+   new version of BIND.  Check the release notes carefully when
+   upgrading to be informed of such changes.  To prevent policy changes
+   on upgrade, use an explicitly defined ``dnssec-policy``, rather than
+   ``default``.
 
-If a ``dnssec-policy`` statement is modified
-and the server restarted or reconfigured, ``named``
-attempts to change the policy smoothly from the old one to
-the new. For example, if the key algorithm is changed, then
-a new key is generated with the new algorithm, and the old
-algorithm is retired when the existing key's lifetime ends.
+If a ``dnssec-policy`` statement is modified and the server restarted or
+reconfigured, ``named`` attempts to change the policy smoothly from the
+old one to the new.  For example, if the key algorithm is changed, then
+a new key is generated with the new algorithm, and the old algorithm is
+retired when the existing key's lifetime ends.
 
-.. note::
-
-  Rolling to a new policy while another key rollover is
-  already in progress is not yet supported, and may result in
-  unexpected behavior.
+.. note:: Rolling to a new policy while another key rollover is already
+   in progress is not yet supported, and may result in unexpected
+   behavior.
 
 The following options can be specified in a ``dnssec-policy`` statement:
 
   ``dnskey-ttl``
-    This indicates the TTL to use when generating DNSKEY resource records. The default is 1
-    hour (3600 seconds).
+    This indicates the TTL to use when generating DNSKEY resource
+    records.  The default is 1 hour (3600 seconds).
 
   ``keys``
     This is a list specifying the algorithms and roles to use when
-    generating keys and signing the zone.
-    Entries in this list do not represent specific
-    DNSSEC keys, which may be changed on a regular basis,
-    but the roles that keys play in the signing policy.
-    For example, configuring a KSK of algorithm RSASHA256 ensures
-    that the DNSKEY RRset always includes a key-signing key
-    for that algorithm.
+    generating keys and signing the zone.  Entries in this list do not
+    represent specific DNSSEC keys, which may be changed on a regular
+    basis, but the roles that keys play in the signing policy.  For
+    example, configuring a KSK of algorithm RSASHA256 ensures that the
+    DNSKEY RRset always includes a key-signing key for that algorithm.
 
-    Here is an example (for illustration purposes only) of
-    some possible entries in a ``keys``
-    list:
+    Here is an example (for illustration purposes only) of some possible
+    entries in a ``keys`` list:
 
     ::
 
         keys {
-               ksk key-directory lifetime unlimited algorithm rsasha1 2048;
-               zsk lifetime P30D algorithm 8;
-               csk lifetime P6MT12H3M15S algorithm ecdsa256;
-	};
+            ksk key-directory lifetime unlimited algorithm rsasha1 2048;
+            zsk lifetime P30D algorithm 8;
+            csk lifetime P6MT12H3M15S algorithm ecdsa256;
+        };
 
-       This example specifies that three keys should be used
-       in the zone. The first token determines which role the
-       key plays in signing RRsets.  If set to
-       ``ksk``, then this is
-       a key-signing key; it has the KSK flag set and
-       is only used to sign DNSKEY, CDS, and CDNSKEY RRsets.
-       If set to ``zsk``, this is
-       a zone-signing key; the KSK flag is unset, and
-       the key signs all RRsets *except*
-       DNSKEY, CDS, and CDNSKEY. If set to
-       ``csk``, the key has the KSK
-       flag set and is used to sign all RRsets.
+    This example specifies that three keys should be used in the zone.
+    The first token determines which role the key plays in signing
+    RRsets.  If set to ``ksk``, then this is a key-signing key; it has
+    the KSK flag set and is only used to sign DNSKEY, CDS, and CDNSKEY
+    RRsets.  If set to ``zsk``, this is a zone-signing key; the KSK flag
+    is unset, and the key signs all RRsets *except* DNSKEY, CDS, and
+    CDNSKEY.  If set to ``csk``, the key has the KSK flag set and is
+    used to sign all RRsets.
 
-       An optional second token determines where the key is
-       stored.  Currently, keys can only be stored in the
-       configured ``key-directory``. This token
-       may be used in the future to store keys in hardware
-       service modules or separate directories.
+    An optional second token determines where the key is stored.
+    Currently, keys can only be stored in the configured
+    ``key-directory``.  This token may be used in the future to store
+    keys in hardware service modules or separate directories.
 
-       The ``lifetime`` parameter specifies how
-       long a key may be used before rolling over.  In the
-       example above, the first key has an unlimited
-       lifetime, the second key may be used for 30 days, and the
-       third key has a rather peculiar lifetime of 6 months,
-       12 hours, 3 minutes, and 15 seconds.  A lifetime of 0
-       seconds is the same as ``unlimited``.
+    The ``lifetime`` parameter specifies how long a key may be used
+    before rolling over.  In the example above, the first key has an
+    unlimited lifetime, the second key may be used for 30 days, and the
+    third key has a rather peculiar lifetime of 6 months, 12 hours, 3
+    minutes, and 15 seconds.  A lifetime of 0 seconds is the same as
+    ``unlimited``.
 
-       Note that the lifetime of a key may be extended if
-       retiring it too soon would cause validation failures.
-       For example, if the key were configured to roll more
-       frequently than its own TTL, its lifetime would
-       automatically be extended to account for this.
+    Note that the lifetime of a key may be extended if retiring it too
+    soon would cause validation failures.  For example, if the key were
+    configured to roll more frequently than its own TTL, its lifetime
+    would automatically be extended to account for this.
 
-       The ``algorithm`` parameter specifies
-       the key's algorithm, expressed either as a string
-       ("rsasha256", "ecdsa384", etc.) or as a decimal number.
-       An optional second parameter specifies the key's size
-       in bits. If it is omitted, as shown in the
-       example for the second and third keys, an appropriate
-       default size for the algorithm is used.
+    The ``algorithm`` parameter specifies the key's algorithm, expressed
+    either as a string ("rsasha256", "ecdsa384", etc.) or as a decimal
+    number.  An optional second parameter specifies the key's size in
+    bits.  If it is omitted, as shown in the example for the second and
+    third keys, an appropriate default size for the algorithm is used.
 
-    ``publish-safety``
-       This is a margin that is added to the pre-publication
-       interval in rollover timing calculations, to give some
-       extra time to cover unforeseen events. This increases
-       the time between when keys are published and they become active.
-       The default is ``PT1H`` (1 hour).
+  ``publish-safety``
+    This is a margin that is added to the pre-publication interval in
+    rollover timing calculations, to give some extra time to cover
+    unforeseen events.  This increases the time between when keys are
+    published and when they become active.  The default is ``PT1H`` (1
+    hour).
 
-     ``retire-safety``
-       This is a margin that is added to the post-publication interval
-       in rollover timing calculations, to give some extra time
-       to cover unforeseen events. This increases the time a key
-       remains published after it is no longer active.  The
-       default is ``PT1H`` (1 hour).
+  ``retire-safety``
+    This is a margin that is added to the post-publication interval in
+    rollover timing calculations, to give some extra time to cover
+    unforeseen events.  This increases the time a key remains published
+    after it is no longer active.  The default is ``PT1H`` (1 hour).
 
-     ``signatures-refresh``
-       This determines how frequently an RRSIG record needs to be
-       refreshed.  The signature is renewed when the time until
-       the expiration time is closer than the specified interval.
-       The default is ``P5D`` (5 days), meaning
-       signatures that expire in 5 days or sooner are
-       refreshed.
+  ``signatures-refresh``
+    This determines how frequently an RRSIG record needs to be
+    refreshed.  The signature is renewed when the time until the
+    expiration time is less than the specified interval.  The default is
+    ``P5D`` (5 days), meaning signatures that expire in 5 days or sooner
+    are refreshed.
 
-     ``signatures-validity``
-       This indicates the validity period of an RRSIG record (subject to
-       inception offset and jitter). The default is
-       ``P2W`` (2 weeks).
+  ``signatures-validity``
+    This indicates the validity period of an RRSIG record (subject to
+    inception offset and jitter).  The default is ``P2W`` (2 weeks).
 
-     ``signatures-validity-dnskey``
-       This is similar to ``signatures-validity``, but for
-       DNSKEY records. The default is ``P2W``
-       (2 weeks).
+  ``signatures-validity-dnskey``
+    This is similar to ``signatures-validity``, but for DNSKEY records.
+    The default is ``P2W`` (2 weeks).
 
-     ``max-zone-ttl``
-       Like the ``max-zone-ttl`` zone option,
-       this specifies the maximum permissible TTL value in
-       seconds for the zone. When loading a zone file using
-       a `masterfile-format` of
-       ``text`` or ``raw``,
-       any record encountered with a TTL higher than
-       `max-zone-ttl` is capped at the
-       maximum permissible TTL value.
+  ``max-zone-ttl``
+    Like the ``max-zone-ttl`` zone option, this specifies the maximum
+    permissible TTL value, in seconds, for the zone.  When loading a
+    zone file using a ``masterfile-format`` of ``text`` or ``raw``, any
+    record encountered with a TTL higher than ``max-zone-ttl`` is capped
+    at the maximum permissible TTL value.
 
-       This is needed in DNSSEC-maintained zones because when
-       rolling to a new DNSKEY, the old key needs to remain
-       available until RRSIG records have expired from caches.
-       The `max-zone-ttl` option guarantees that
-       the largest TTL in the zone is no higher than the
-       set value.
+    This is needed in DNSSEC-maintained zones because when rolling to a
+    new DNSKEY, the old key needs to remain available until RRSIG
+    records have expired from caches.  The ``max-zone-ttl`` option
+    guarantees that the largest TTL in the zone is no higher than the
+    set value.
 
-       .. note::
-	  Because ``map``-format files
-	  load directly into memory, this option cannot be
-	  used with them.
+    .. note:: Because ``map``-format files load directly into memory,
+       this option cannot be used with them.
 
-       The default value is ``PT24H`` (24 hours).
-       A `max-zone-ttl` of zero is treated as if
-       the default value were in use.
+    The default value is ``PT24H`` (24 hours).  A ``max-zone-ttl`` of
+    zero is treated as if the default value were in use.
 
-     ``nsec3param``
-       Use NSEC3 instead of NSEC, and optionally set the NSEC3 parameters.
+  ``nsec3param``
+    Use NSEC3 instead of NSEC, and optionally set the NSEC3 parameters.
 
-       Here is an example of an ``nsec3`` configuration:
+    Here is an example of an ``nsec3`` configuration:
 
-       ::
+    ::
 
-          nsec3param iterations 5 optout no salt-length 8;
+        nsec3param iterations 5 optout no salt-length 8;
 
-       The default is to use NSEC. The ``iterations``, ``optout``
-       and ``salt-length`` parts are optional, but if not set, the
-       values in the example above are the default NSEC3 parameters.
+    The default is to use NSEC.  The ``iterations``, ``optout`` and
+    ``salt-length`` parts are optional, but if not set, the values in
+    the example above are the default NSEC3 parameters.
 
-     ``zone-propagation-delay``
-       This is the expected propagation delay from the time when a zone
-       is first updated to the time when the new version of the
-       zone is served by all secondary servers.  The default
-       is ``PT5M`` (5 minutes).
+  ``zone-propagation-delay``
+    This is the expected propagation delay from the time when a zone is
+    first updated to the time when the new version of the zone is served
+    by all secondary servers.  The default is ``PT5M`` (5 minutes).
 
-     ``parent-ds-ttl``
-       This is the TTL of the DS RRset that the parent zone uses.  The
-       default is ``P1D`` (1 day).
+  ``parent-ds-ttl``
+    This is the TTL of the DS RRset that the parent zone uses.  The
+    default is ``P1D`` (1 day).
 
-     ``parent-propagation-delay``
-       This is the expected propagation delay from the time when the
-       parent zone is updated to the time when the new version
-       is served by all of the parent zone's name servers.
-       The default is ``PT1H`` (1 hour).
+  ``parent-propagation-delay``
+    This is the expected propagation delay from the time when the parent
+    zone is updated to the time when the new version is served by all of
+    the parent zone's name servers.  The default is ``PT1H`` (1 hour).
 
 .. _managed-keys:
 

doc/notes/notes-9.16.10.rst

@@ -0,0 +1,50 @@
+.. 
+   Copyright (C) Internet Systems Consortium, Inc. ("ISC")
+   
+   This Source Code Form is subject to the terms of the Mozilla Public
+   License, v. 2.0. If a copy of the MPL was not distributed with this
+   file, you can obtain one at https://mozilla.org/MPL/2.0/.
+   
+   See the COPYRIGHT file distributed with this work for additional
+   information regarding copyright ownership.
+
+Notes for BIND 9.16.10
+----------------------
+
+New Features
+~~~~~~~~~~~~
+
+- NSEC3 support was added to KASP. A new option for ``dnssec-policy``,
+  ``nsec3param``, can be used to set the desired NSEC3 parameters.
+  NSEC3 salt collisions are automatically prevented during resalting.
+  [GL #1620]
+
+Feature Changes
+~~~~~~~~~~~~~~~
+
+- The default value of ``max-recursion-queries`` was increased from 75
+  to 100. Since the queries sent towards root and TLD servers are now
+  included in the count (as a result of the fix for CVE-2020-8616),
+  ``max-recursion-queries`` has a higher chance of being exceeded by
+  non-attack queries, which is the main reason for increasing its
+  default value. [GL #2305]
+
+- The default value of ``nocookie-udp-size`` was restored back to 4096
+  bytes. Since ``max-udp-size`` is the upper bound for
+  ``nocookie-udp-size``, this change relieves the operator from having
+  to change ``nocookie-udp-size`` together with ``max-udp-size`` in
+  order to increase the default EDNS buffer size limit.
+  ``nocookie-udp-size`` can still be set to a value lower than
+  ``max-udp-size``, if desired. [GL #2250]
+
+Bug Fixes
+~~~~~~~~~
+
+- Handling of missing DNS COOKIE responses over UDP was tightened by
+  falling back to TCP. [GL #2275]
+
+- The CNAME synthesized from a DNAME was incorrectly followed when the
+  QTYPE was CNAME or ANY. [GL #2280]
+
+- Building with native PKCS#11 support for AEP Keyper has been broken
+  since BIND 9.16.6. This has been fixed. [GL #2315]

doc/notes/notes-current.rst

@@ -1,67 +0,0 @@
-.. 
-   Copyright (C) Internet Systems Consortium, Inc. ("ISC")
-   
-   This Source Code Form is subject to the terms of the Mozilla Public
-   License, v. 2.0. If a copy of the MPL was not distributed with this
-   file, you can obtain one at https://mozilla.org/MPL/2.0/.
-   
-   See the COPYRIGHT file distributed with this work for additional
-   information regarding copyright ownership.
-
-Notes for BIND 9.16.10
-----------------------
-
-Security Fixes
-~~~~~~~~~~~~~~
-
-- None.
-
-Known Issues
-~~~~~~~~~~~~
-
-- None.
-
-New Features
-~~~~~~~~~~~~
-
-- None.
-
-Removed Features
-~~~~~~~~~~~~~~~~
-
-- None.
-
-Feature Changes
-~~~~~~~~~~~~~~~
-
-- None.
-
-- Add NSEC3 support for zones that manage their DNSSEC with the `dnssec-policy`
-  configuration. A new option 'nsec3param' can be used to set the desired
-  NSEC3 parameters, and will detect collisions when resalting. [GL #1620].
-
-- Adjust the ``max-recursion-queries`` default from 75 to 100. Since the
-  queries sent towards root and TLD servers are now included in the
-  count (as a result of the fix for CVE-2020-8616), ``max-recursion-queries``
-  has a higher chance of being exceeded by non-attack queries, which is the
-  main reason for increasing its default value. [GL #2305]
-
-- Restore the ``nocookie-udp-size`` default from 1232 to 4096. Normally the
-  EDNS buffer size is configured by ``max-udp-size``, but this configuration
-  option overrides the value, but most people don't and won't realize there's
-  an extra configuration option that needs to be tweaked. By changing the
-  default here, we allow the the ``max-udp-size`` to be the sole option that
-  needs to be changed when operator wants to change the default EDNS buffer
-  size. [GL #2250]
-
-Bug Fixes
-~~~~~~~~~
-
-- The synthesised CNAME from a DNAME was incorrectly followed when the QTYPE
-  was CNAME or ANY. [GL #2280]
-
-- Tighten handling of missing DNS COOKIE responses over UDP by
-  falling back to TCP. [GL #2275]
-
-- Building with native PKCS#11 support for AEP Keyper has been broken
-  since BIND 9.16.6. This has been fixed. [GL #2315]

lib/dns/api

@@ -10,6 +10,6 @@
 # 9.12: 1200-1299
 # 9.13/9.14: 1300-1499
 # 9.15/9.16: 1500-1699
-LIBINTERFACE = 1609
+LIBINTERFACE = 1610
 LIBREVISION = 0
 LIBAGE = 0

lib/isc/api

@@ -11,5 +11,5 @@
 # 9.13/9.14: 1300-1499
 # 9.15/9.16: 1500-1699
 LIBINTERFACE = 1608
-LIBREVISION = 0
+LIBREVISION = 1
 LIBAGE = 0

lib/isccfg/api

@@ -10,6 +10,6 @@
 # 9.12: 1200-1299
 # 9.13/9.14: 1300-1499
 # 9.15/9.16: 1500-1699
-LIBINTERFACE = 1601
-LIBREVISION = 1
+LIBINTERFACE = 1602
+LIBREVISION = 0
 LIBAGE = 0

lib/ns/api

@@ -11,5 +11,5 @@
 # 9.13/9.14: 1300-1499
 # 9.15/9.16: 1500-1699
 LIBINTERFACE = 1606
-LIBREVISION = 0
+LIBREVISION = 1
 LIBAGE = 0

util/copyrights

@@ -1461,6 +1461,7 @@
 ./doc/misc/stub.zoneopt				X	2018,2019,2020
 ./doc/notes/notes-9.16.0.rst			RST	2020
 ./doc/notes/notes-9.16.1.rst			RST	2020
+./doc/notes/notes-9.16.10.rst			RST	2020
 ./doc/notes/notes-9.16.2.rst			RST	2020
 ./doc/notes/notes-9.16.3.rst			RST	2020
 ./doc/notes/notes-9.16.4.rst			RST	2020
@@ -1469,7 +1470,6 @@
 ./doc/notes/notes-9.16.7.rst			RST	2020
 ./doc/notes/notes-9.16.8.rst			RST	2020
 ./doc/notes/notes-9.16.9.rst			RST	2020
-./doc/notes/notes-current.rst			RST	2020
 ./docutil/HTML_COPYRIGHT			X	2001,2004,2016,2018,2019,2020
 ./docutil/MAN_COPYRIGHT				X	2001,2004,2016,2018,2019,2020
 ./docutil/patch-db2latex-duplicate-template-bug	X	2007,2018,2019,2020

version

@@ -5,7 +5,7 @@ PRODUCT=BIND
 DESCRIPTION="(Stable Release)"
 MAJORVER=9
 MINORVER=16
-PATCHVER=9
+PATCHVER=10
 RELEASETYPE=
 RELEASEVER=
 EXTENSIONS=