documentation changes establishing the 9.14 stable branch

This commit is contained in:
Evan Hunt 2019-02-21 15:33:29 -08:00
parent 06d5da0204
commit 3396f9396f
14 changed files with 118 additions and 248 deletions

View file

@ -13,7 +13,7 @@ offer support on a "best effort" basis for some.
Regularly tested platforms
As of Jan 2019, BIND 9.13 is fully supported and regularly tested on the
As of Feb 2019, BIND 9.14 is fully supported and regularly tested on the
following systems:
* Debian 8, 9, 10
@ -51,7 +51,7 @@ Server 2012 R2, none of these are tested regularly by ISC.
Unsupported platforms
These are platforms on which BIND 9.13 is known not to build or run:
These are platforms on which BIND 9.14 is known not to build or run:
* Platforms without at least OpenSSL 1.0.2
* Windows 10 / x86

View file

@ -23,7 +23,7 @@ offer support on a "best effort" basis for some.
### Regularly tested platforms
As of Jan 2019, BIND 9.13 is fully supported and regularly tested on the
As of Feb 2019, BIND 9.14 is fully supported and regularly tested on the
following systems:
* Debian 8, 9, 10
@ -60,7 +60,7 @@ Server 2012 R2, none of these are tested regularly by ISC.
## Unsupported platforms
These are platforms on which BIND 9.13 is known *not* to build or run:
These are platforms on which BIND 9.14 is known *not* to build or run:
* Platforms without at least OpenSSL 1.0.2
* Windows 10 / x86

15
README
View file

@ -5,7 +5,7 @@ Contents
1. Introduction
2. Reporting bugs and getting help
3. Contributing to BIND
4. BIND 9.13 features
4. BIND 9.14 features
5. Building BIND
6. macOS
7. Dependencies
@ -100,17 +100,19 @@ If you prefer, you may also submit code by opening a GitLab Issue and
including your patch as an attachment, preferably generated by git
format-patch.
BIND 9.13 features
BIND 9.14 features
BIND 9.13 is the newest development branch of BIND 9. It includes a number
of changes from BIND 9.12 and earlier releases. New features include:
BIND 9.14.0 is the first release from a new stable branch of BIND 9,
incorporating all changes from the 9.13 development branch, updating the
most recent stable branch, 9.12. These changes include:
* A new "plugin" mechanism has been added to allow query functionality
to be extended using dynamically loadable libraries. The "filter-aaaa"
feature has been removed from named and is now implemented as a
plugin.
* Socket and task code has been refactored to improve performance.
* QNAME minimization, as described in RFC 7816, is now supported.
* Socket and task code has been refactored to improve performance on
most modern machines.
* "Root key sentinel" support, enabling validating resolvers to indicate
via a special query which trust anchors are configured for the root
zone.
@ -138,7 +140,8 @@ is now mandatory: building BIND without DNSSEC is no longer supported.
Special code to support certain legacy operating systems has also been
removed; see the file PLATFORMS.md for details of supported platforms. In
addition to OpenSSL, BIND now requires support for IPv6, threads, and
standard atomic operations provided by the C compiler.
standard atomic operations provided by the C compiler. Non-threaded builds
are no longer supported.
Building BIND

View file

@ -15,7 +15,7 @@
1. [Introduction](#intro)
1. [Reporting bugs and getting help](#help)
1. [Contributing to BIND](#contrib)
1. [BIND 9.13 features](#features)
1. [BIND 9.14 features](#features)
1. [Building BIND](#build)
1. [macOS](#macos)
1. [Dependencies](#dependencies)
@ -117,17 +117,18 @@ If you prefer, you may also submit code by opening a
including your patch as an attachment, preferably generated by
`git format-patch`.
### <a name="features"/> BIND 9.13 features
### <a name="features"/> BIND 9.14 features
BIND 9.13 is the newest development branch of BIND 9. It includes a
number of changes from BIND 9.12 and earlier releases. New features
include:
BIND 9.14.0 is the first release from a new stable branch of BIND 9,
incorporating all changes from the 9.13 development branch, updating
the most recent stable branch, 9.12. These changes include:
* A new "plugin" mechanism has been added to allow query functionality
to be extended using dynamically loadable libraries. The "filter-aaaa"
feature has been removed from named and is now implemented as a plugin.
* Socket and task code has been refactored to improve performance.
* QNAME minimization, as described in RFC 7816, is now supported.
* Socket and task code has been refactored to improve performance on most
modern machines.
* "Root key sentinel" support, enabling validating resolvers to indicate
via a special query which trust anchors are configured for the root zone.
* Secondary zones can now be configured as "mirror" zones; their contents
@ -157,7 +158,7 @@ Special code to support certain legacy operating systems has also
been removed; see the file [PLATFORMS.md](PLATFORMS.md) for details
of supported platforms. In addition to OpenSSL, BIND now requires
support for IPv6, threads, and standard atomic operations provided
by the C compiler.
by the C compiler. Non-threaded builds are no longer supported.
### <a name="build"/> Building BIND

View file

@ -7,7 +7,7 @@
# See the COPYRIGHT file distributed with this work for additional
# information regarding copyright ownership.
AC_INIT(BIND, [9.13], [info@isc.org], [], [https://www.isc.org/downloads/BIND/])
AC_INIT(BIND, [9.14], [info@isc.org], [], [https://www.isc.org/downloads/BIND/])
AC_PREREQ([2.60])
AC_CONFIG_HEADER(config.h)

View file

@ -21,44 +21,38 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="noteversion.xml"/>
<section xml:id="relnotes_intro"><info><title>Introduction</title></info>
<para>
BIND 9.13 is an unstable development release of BIND.
This document summarizes new features and functional changes that
have been introduced on this branch. With each development release
leading up to the stable BIND 9.14 release, this document will be
updated with additional features added and bugs fixed.
BIND 9.14.0 is the first release of a new stable branch of BIND.
This document summarizes new features and functional changes
that have been introduced, as well as features that have been
deprecated or removed, since the last stable branch, 9.12.
<para>
</para>
Please see the file <filename>CHANGES</filename> for a more
detailed list of changes and bug fixes.
</para>
</section>
<section xml:id="relnotes_versions"><info><title>Note on Version Numbering</title></info>
<para>
Prior to BIND 9.13, new feature development releases were tagged
as "alpha" and "beta", leading up to the first stable release
for a given development branch, which always ended in ".0".
</para>
<para>
Now, however, BIND has adopted the "odd-unstable/even-stable"
release numbering convention. There will be no "alpha" or "beta"
releases in the 9.13 branch, only increasing version numbers.
So, for example, what would previously have been called 9.13.0a1,
9.13.0a2, 9.13.0b1, and so on, will instead be called 9.13.0,
9.13.1, 9.13.2, etc.
</para>
<para>
The first stable release from this development branch will be
renamed as 9.14.0. Thereafter, maintenance releases will continue
on the 9.14 branch, while unstable feature development proceeds in
9.15.
As of BIND 9.13/9.14, BIND has adopted the "odd-unstable/even-stable"
release numbering convention. BIND 9.14 contains new features added
during the BIND 9.13 development process. Henceforth, the 9.14 branch
will be limited to bug fixes and new feature development will proceed
in the unstable 9.15 branch, and so forth.
</para>
</section>
<section xml:id="relnotes_platforms"><info><title>Supported Platforms</title></info>
<para>
BIND 9.13 has undergone substantial code refactoring and cleanup,
and some very old code has been removed that was needed to support
legacy platforms which are no longer supported by their vendors
and for which ISC is no longer able to perform quality assurance
testing. Specifically, workarounds for old versions of UnixWare,
BSD/OS, AIX, Tru64, SunOS, TruCluster and IRIX have been removed.
Since 9.12, BIND has undergone substantial code refactoring and
cleanup, and some very old code has been removed that was needed
to support legacy platforms which are no longer supported by their
vendors and for which ISC is no longer able to perform quality
assurance testing. Specifically, workarounds for old versions of
UnixWare, BSD/OS, AIX, Tru64, SunOS, TruCluster and IRIX have been
removed.
</para>
<para>
On UNIX-like systems, BIND now requires support for POSIX.1c
threads (IEEE Std 1003.1c-1995), the Advanced Sockets API for
IPv6 (RFC 3542), and standard atomic operations provided by the
@ -73,7 +67,7 @@
for systems that are still supported by their respective vendors.
</para>
<para>
As of BIND 9.13, the BIND development team has also made cryptography
As of BIND 9.14, the BIND development team has also made cryptography
(i.e., TSIG and DNSSEC) an integral part of the DNS server. The
OpenSSL cryptography library must be available for the target
platform. A PKCS#11 provider can be used instead for Public Key
@ -93,81 +87,6 @@
</para>
</section>
<section xml:id="relnotes_security"><info><title>Security Fixes</title></info>
<itemizedlist>
<listitem>
<para>
There was a long-existing flaw in the documentation for
<command>ms-self</command>, <command>krb5-self</command>,
<command>ms-subdomain</command>, and <command>krb5-subdomain</command>
rules in <command>update-policy</command> statements. Though
the policies worked as intended, operators who configured their
servers according to the misleading documentation may have
thought zone updates were more restricted than they were;
users of these rule types are advised to review the documentation
and correct their configurations if necessary. New rule types
matching the previously documented behavior will be introduced
in a future maintenance release. [GL !708]
</para>
</listitem>
<listitem>
<para>
When recursion is enabled but the <command>allow-recursion</command>
and <command>allow-query-cache</command> ACLs are not specified, they
should be limited to local networks, but they were inadvertently set
to match the default <command>allow-query</command>, thus allowing
remote queries. This flaw is disclosed in CVE-2018-5738. [GL #309]
</para>
</listitem>
<listitem>
<para>
<command>named</command> could crash during recursive processing
of DNAME records when <command>deny-answer-aliases</command> was
in use. This flaw is disclosed in CVE-2018-5740. [GL #387]
</para>
</listitem>
<listitem>
<para>
Code change #4964, intended to prevent double signatures
when deleting an inactive zone DNSKEY in some situations,
introduced a new problem during zone processing in which
some delegation glue RRsets are incorrectly identified
as needing RRSIGs, which are then created for them using
the current active ZSK for the zone. In some, but not all
cases, the newly-signed RRsets are added to the zone's
NSEC/NSEC3 chain, but incompletely -- this can result in
a broken chain, affecting validation of proof of nonexistence
for records in the zone. [GL #771]
</para>
</listitem>
<listitem>
<para>
<command>named</command> could crash if it managed a DNSSEC
security root with <command>managed-keys</command> and the
authoritative zone rolled the key to an algorithm not supported
by BIND 9. This flaw is disclosed in CVE-2018-5745. [GL #780]
</para>
</listitem>
<listitem>
<para>
<command>named</command> leaked memory when processing a
request with multiple Key Tag EDNS options present. ISC
would like to thank Toshifumi Sakaguchi for bringing this
to our attention. This flaw is disclosed in CVE-2018-5744.
[GL #772]
</para>
</listitem>
<listitem>
<para>
Zone transfer controls for writable DLZ zones were not
effective as the <command>allowzonexfr</command> method was
not being called for such zones. This flaw is disclosed in
CVE-2019-6465. [GL #790]
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="relnotes_features"><info><title>New Features</title></info>
<itemizedlist>
<listitem>
@ -181,15 +100,11 @@
</listitem>
<listitem>
<para>
A new secondary zone option, <command>mirror</command>,
enables <command>named</command> to serve a transferred copy
of a zone's contents without acting as an authority for the
zone. A zone must be fully validated against an active trust
anchor before it can be used as a mirror zone. DNS responses
from mirror zones do not set the AA bit ("authoritative answer"),
but do set the AD bit ("authenticated data"). This feature is
meant to facilitate deployment of a local copy of the root zone,
as described in RFC 7706. [GL #33]
Support for QNAME minimization was added and enabled by default
in <command>relaxed</command> mode, in which BIND will fall back
to normal resolution if the remote server returns something
unexpected during the query minimization process. This default
setting might change to <command>strict</command> in the future.
</para>
</listitem>
<listitem>
@ -205,6 +120,19 @@
as further plugins are implemented. [GL #15]
</para>
</listitem>
<listitem>
<para>
A new secondary zone option, <command>mirror</command>,
enables <command>named</command> to serve a transferred copy
of a zone's contents without acting as an authority for the
zone. A zone must be fully validated against an active trust
anchor before it can be used as a mirror zone. DNS responses
from mirror zones do not set the AA bit ("authoritative answer"),
but do set the AD bit ("authenticated data"). This feature is
meant to facilitate deployment of a local copy of the root zone,
as described in RFC 7706. [GL #33]
</para>
</listitem>
<listitem>
<para>
BIND now can be compiled against the <command>libidn2</command>
@ -231,15 +159,6 @@
signatures covering DNSKEY RRsets. [GL #145]
</para>
</listitem>
<listitem>
<para>
Support for QNAME minimization was added and enabled by default
in <command>relaxed</command> mode, in which BIND will fall back
to normal resolution if the remote server returns something
unexpected during the query minimization process. This default
setting might change to <command>strict</command> in the future.
</para>
</listitem>
<listitem>
<para>
When built on Linux, BIND now requires the <command>libcap</command>
@ -294,6 +213,22 @@
configuration is being reloaded.
</para>
</listitem>
<listitem>
<para>
The new <command>answer-cookie</command> option, if set to
<literal>no</literal>, prevents <command>named</command> from
returning a DNS COOKIE option to a client, even if such an
option was present in the request. This is only intended as
a temporary measure, for use when <command>named</command>
shares an IP address with other servers that do not yet
support DNS COOKIE. A mismatch between servers on the same
address is not expected to cause operational problems, but the
option to disable COOKIE responses so that all servers have the
same behavior is provided out of an abundance of caution.
DNS COOKIE is an important security mechanism, and this option
should not be used to disable it unless absolutely necessary.
</para>
</listitem>
</itemizedlist>
</section>
@ -437,51 +372,43 @@
</listitem>
<listitem>
<para>
Support for ECC-GOST (GOST R 34.11-94) algorithm has been
removed from BIND as the algorithm has been superseded by
GOST R 34.11-2012 in RFC6986 and it must not be used in new
deployments. BIND will neither create new DNSSEC keys,
signatures and digest, nor it will validate them.
Support for the RSAMD5 algorithm has been removed freom BIND as
the usage of the RSAMD5 algorithm for DNSSEC has been deprecated
in RFC6725, the security of the MD5 algorithm has been compromised,
and its usage is considered harmful.
</para>
</listitem>
<listitem>
<para>
Add the ability to not return a DNS COOKIE option when one
is present in the request. To prevent a cookie being returned
add 'answer-cookie no;' to named.conf. [GL #173]
</para>
<para>
<command>answer-cookie</command> is only intended as a temporary
measure, for use when <command>named</command> shares an IP address
with other servers that do not yet support DNS COOKIE. A mismatch
between servers on the same address is not expected to cause
operational problems, but the option to disable COOKIE responses so
that all servers have the same behavior is provided out of an
abundance of caution. DNS COOKIE is an important security mechanism,
and should not be disabled unless absolutely necessary.
</para>
<para>
Remove support for silently ignoring 'no-change' deltas from
BIND 8 when processing an IXFR stream. 'no-change' deltas
will now trigger a fallback to AXFR as the recovery mechanism.
</para>
<para>
BIND 9 will no longer build on platforms that doesn't have
proper IPv6 support. BIND 9 now also requires non-broken
POSIX-compatible pthread support. Such platforms are
usually long after their end-of-life date and they are
neither developed nor supported by their respective vendors.
Support for the ECC-GOST (GOST R 34.11-94) algorithm has been
removed from BIND, as the algorithm has been superseded by
GOST R 34.11-2012 in RFC6986 and it must not be used in new
deployments. BIND will neither create new DNSSEC keys,
signatures and digests, nor it will validate them.
</para>
</listitem>
<listitem>
<para>
Support for DSA and DSA-NSEC3-SHA1 algorithms has been
removed from BIND as the DSA key length is limited to 1024
bits and this is not considered secure enough.
</para>
</listitem>
<listitem>
<para>
Support for RSAMD5 algorithm has been removed freom BIND as the usage
of the RSAMD5 algorithm for DNSSEC has been deprecated in RFC6725 and
the security of MD5 algorithm has been compromised and the its usage
is considered harmful.
<command>named</command> will no longer ignore "no-change" deltas
when processing an IXFR stream. This had previously been
permitted for compatibility with BIND 8, but now "no-change"
deltas will trigger a fallback to AXFR as the recovery mechanism.
</para>
</listitem>
<listitem>
<para>
BIND 9 will no longer build on platforms that don't have
proper IPv6 support. BIND 9 now also requires POSIX-compatible
pthread support. Most of the platforms that lack these featuers
are long past their end-of-lifew dates, and they are neither
developed nor supported by their respective vendors.
</para>
</listitem>
<listitem>
@ -503,7 +430,7 @@
<para>
BIND will now always use the best CSPRNG (cryptographically-secure
pseudo-random number generator) available on the platform where
it is compiled. It will use <command>arc4random()</command>
it is compiled. It will use the <command>arc4random()</command>
family of functions on BSD operating systems,
<command>getrandom()</command> on Linux and Solaris,
<command>CryptGenRandom</command> on Windows, and the selected
@ -632,62 +559,6 @@
</itemizedlist>
</section>
<section xml:id="relnotes_bugs"><info><title>Bug Fixes</title></info>
<itemizedlist>
<listitem>
<para>
Running <command>rndc reconfig</command> could cause
<command>inline-signing</command> zones to stop signing.
[GL #439]
</para>
</listitem>
<listitem>
<para>
Reloading all zones caused zone maintenance to stop for
<command>inline-signing</command> zones. [GL #435]
</para>
</listitem>
<listitem>
<para>
Signatures loaded from the journal for the signed version
of an <command>inline-signing</command> zone were not scheduled
for refresh. [GL #482]
</para>
</listitem>
<listitem>
<para>
A referral response with a non-empty ANSWER section was
incorrectly treated as an error; this caused certain domains
to be non-resolvable. [GL #390]
</para>
</listitem>
<listitem>
<para>
When a negative trust anchor was added to multiple views
using <command>rndc nta</command>, the text returned via
<command>rndc</command> was incorrectly truncated after the
first line, making it appear that only one NTA had been
added. This has been fixed. [GL #105]
</para>
</listitem>
<listitem>
<para>
The view name is now included in the output of
<command>rndc nta -dump</command>, for consistency with
other options. [GL !816]
</para>
</listitem>
<listitem>
<para>
<command>named</command> now rejects excessively large
incremental (IXFR) zone transfers in order to prevent
possible corruption of journal files which could cause
<command>named</command> to abort when loading zones. [GL #339]
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="relnotes_license"><info><title>License</title></info>
<para>
BIND is open source software licenced under the terms of the Mozilla
@ -713,11 +584,6 @@
</section>
<section xml:id="end_of_life"><info><title>End of Life</title></info>
<para>
BIND 9.13 is an unstable development branch. When its development
is complete, it will be renamed to BIND 9.14, which will be a
stable branch.
</para>
<para>
The end of life date for BIND 9.14 has not yet been determined.
For those needing long term support, the current Extended Support

View file

@ -8,7 +8,7 @@
# 9.10-sub: 180-189
# 9.11: 160-169,1100-1199
# 9.12: 1200-1299
# 9.13: 1300-1399
# 9.13/9.14: 1300-1499
LIBINTERFACE = 1302
LIBREVISION = 1
LIBAGE = 0

View file

@ -8,7 +8,7 @@
# 9.10-sub: 180-189
# 9.11: 160-169,1100-1199
# 9.12: 1200-1299
# 9.13: 1300-1399
# 9.13/9.14: 1300-1499
LIBINTERFACE = 1306
LIBREVISION = 1
LIBAGE = 0

View file

@ -8,7 +8,7 @@
# 9.10-sub: 180-189
# 9.11: 160-169,1100-1199
# 9.12: 1200-1299
# 9.13: 1300-1399
# 9.13/9.14: 1300-1499
LIBINTERFACE = 1301
LIBREVISION = 3
LIBAGE = 0

View file

@ -8,7 +8,7 @@
# 9.10-sub: 180-189
# 9.11: 160-169,1100-1199
# 9.12: 1200-1299
# 9.13: 1300-1399
# 9.13/9.14: 1300-1499
LIBINTERFACE = 1306
LIBREVISION = 1
LIBAGE = 0

View file

@ -8,7 +8,7 @@
# 9.10-sub: 180-189
# 9.11: 160-169,1100-1199
# 9.12: 1200-1299
# 9.13: 1300-1399
# 9.13/9.14: 1300-1499
LIBINTERFACE = 1302
LIBREVISION = 0
LIBAGE = 0

View file

@ -8,7 +8,7 @@
# 9.10-sub: 180-189
# 9.11: 160-169,1100-1199
# 9.12: 1200-1299
# 9.13: 1300-1399
# 9.13/9.14: 1300-1499
LIBINTERFACE = 1302
LIBREVISION = 0
LIBAGE = 0

View file

@ -8,7 +8,7 @@
# 9.10-sub: 180-189
# 9.11: 160-169
# 9.12: 1200-1299
# 9.13: 1300-1399
# 9.13/9.14: 1300-1499
LIBINTERFACE = 1304
LIBREVISION = 2
LIBAGE = 0

10
version
View file

@ -2,10 +2,10 @@
# configure.
#
PRODUCT=BIND
DESCRIPTION="(Development Release)"
DESCRIPTION="(Stable Release)"
MAJORVER=9
MINORVER=13
PATCHVER=7
RELEASETYPE=
RELEASEVER=
MINORVER=14
PATCHVER=0
RELEASETYPE=rc
RELEASEVER=1
EXTENSIONS=