<!DOCTYPE book [

<!ENTITY Scaron "&#x160;">

<!ENTITY ccaron "&#x10D;">

<!ENTITY aacute "&#x0E1;">

<!ENTITY mdash "&#8212;">

<!ENTITY ouml "&#xf6;">]>

<section xmlns:db="http://docbook.org/ns/docbook" version="5.0"><info/>

<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="noteversion.xml"/>

<section xml:id="relnotes_intro"><info><title>Introduction</title></info>

<para>

This document summarizes changes since the last production

release on the BIND 9.11 branch.

Please see the <filename>CHANGES</filename> file for a further

list of bug fixes and other changes.

</para>

</section>

<section xml:id="relnotes_download"><info><title>Download</title></info>

<para>

The latest versions of BIND 9 software can always be found at

<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.isc.org/downloads/">http://www.isc.org/downloads/</link>.

There you will find additional information about each release,

source code, and pre-compiled versions for Microsoft Windows

operating systems.

</para>

</section>

<section xml:id="root_key"><info><title>New DNSSEC Root Key</title></info>

<para>

ICANN is in the process of introducing a new Key Signing Key (KSK) for

the global root zone. BIND has multiple methods for managing DNSSEC

trust anchors, with somewhat different behaviors. If the root

key is configured using the <command>managed-keys</command>

statement, or if the pre-configured root key is enabled by using

<command>dnssec-validation auto</command>, then BIND can keep

keys up to date automatically. Servers configured in this way

will roll seamlessly to the new key when it is published in

the root zone. However, keys configured using the

<command>trusted-keys</command> statement are not automatically

maintained. If your server is performing DNSSEC validation

and is configured using <command>trusted-keys</command>, you are

advised to change your configuration before the root zone begins

signing with the new KSK. This is currently scheduled for

October 11, 2017.

</para>

<para>

This release includes an updated version of the

<filename>bind.keys</filename> file containing the new root

key. This file can also be downloaded from

<link xmlns:xlink="http://www.w3.org/1999/xlink"

xlink:href="https://www.isc.org/bind-keys">

https://www.isc.org/bind-keys

</link>.

</para>

</section>

<section xml:id="relnotes_license"><info><title>License Change</title></info>

<para>

With the release of BIND 9.11.0, ISC changed to the open

source license for BIND from the ISC license to the Mozilla

Public License (MPL 2.0).

</para>

<para>

The MPL-2.0 license requires that if you make changes to

licensed software (e.g. BIND) and distribute them outside

your organization, that you publish those changes under that

same license. It does not require that you publish or disclose

anything other than the changes you made to our software.

</para>

<para>

This new requirement will not affect anyone who is using BIND

without redistributing it, nor anyone redistributing it without

changes, therefore this change will be without consequence

for most individuals and organizations who are using BIND.

</para>

<para>

Those unsure whether or not the license change affects their

use of BIND, or who wish to discuss how to comply with the

license may contact ISC at <link

xmlns:xlink="http://www.w3.org/1999/xlink"

xlink:href="https://www.isc.org/mission/contact/">

https://www.isc.org/mission/contact/</link>.

</para>

</section>

<section xml:id="relnotes_security"><info><title>Security Fixes</title></info>

<itemizedlist>

<listitem>

<para>

If a server is configured with a response policy zone (RPZ)

that rewrites an answer with local data, and is also configured

for DNS64 address mapping, a NULL pointer can be read

triggering a server crash. This flaw is disclosed in

CVE-2017-3135. [RT #44434]

</para>

</listitem>

<listitem>

<para>

A coding error in the <option>nxdomain-redirect</option>

feature could lead to an assertion failure if the redirection

namespace was served from a local authoritative data source

such as a local zone or a DLZ instead of via recursive

lookup. This flaw is disclosed in CVE-2016-9778. [RT #43837]

</para>

</listitem>

<listitem>

<para>

<command>named</command> could mishandle authority sections

with missing RRSIGs, triggering an assertion failure. This

flaw is disclosed in CVE-2016-9444. [RT #43632]

</para>

</listitem>

<listitem>

<para>

<command>named</command> mishandled some responses where

covering RRSIG records were returned without the requested

data, resulting in an assertion failure. This flaw is

disclosed in CVE-2016-9147. [RT #43548]

</para>

</listitem>

<listitem>

<para>

<command>named</command> incorrectly tried to cache TKEY

records which could trigger an assertion failure when there was

a class mismatch. This flaw is disclosed in CVE-2016-9131.

[RT #43522]

</para>

</listitem>

<listitem>

<para>

It was possible to trigger assertions when processing

responses containing answers of type DNAME. This flaw is

disclosed in CVE-2016-8864. [RT #43465]

</para>

</listitem>

<listitem>

<para>

Added the ability to specify the maximum number of records

permitted in a zone (<option>max-records #;</option>).

This provides a mechanism to block overly large zone

transfers, which is a potential risk with slave zones from

other parties, as described in CVE-2016-6170.

[RT #42143]

</para>

</listitem>

</itemizedlist>

</section>

<section xml:id="relnotes_changes"><info><title>Feature Changes</title></info>

<itemizedlist>

<listitem>

<para>

<command>dnstap</command> now stores both the local and remote

addresses for all messages, instead of only the remote address.

The default output format for <command>dnstap-read</command> has

been updated to include these addresses, with the initiating

address first and the responding address second, separated by

"-%gt;" or "%lt;-" to indicate in which direction the message

was sent. [RT #43595]

</para>

</listitem>

<listitem>

<para>

Expanded and improved the YAML output from

<command>dnstap-read -y</command>: it now includes packet

size and a detailed breakdown of message contents.

[RT #43622] [RT #43642]

</para>

</listitem>

<listitem>

<para>

If an ACL is specified with an address prefix in which the

prefix length is longer than the address portion (for example,

192.0.2.1/8), <command>named</command> will now log a warning.

In future releases this will be a fatal configuration error.

[RT #43367]

</para>

</listitem>

</itemizedlist>

</section>

<section xml:id="relnotes_bugs"><info><title>Bug Fixes</title></info>

<itemizedlist>

<listitem>

<para>

A synthesized CNAME record appearing in a response before the

associated DNAME could be cached, when it should not have been.

This was a regression introduced while addressing CVE-2016-8864.

[RT #44318]

</para>

</listitem>

<listitem>

<para>

<command>named</command> could deadlock if multiple changes

to NSEC/NSEC3 parameters for the same zone were being processed

at the same time. [RT #42770]

</para>

</listitem>

<listitem>

<para>

<command>named</command> could trigger an assertion when

sending NOTIFY messages. [RT #44019]

</para>

</listitem>

<listitem>

<para>

Referencing a nonexistent zone in a <command>response-policy</command>

statement could cause an assertion failure during configuration.

[RT #43787]

</para>

</listitem>

<listitem>

<para>

<command>rndc addzone</command> could cause a crash

when attempting to add a zone with a type other than

<command>master</command> or <command>slave</command>.

Such zones are now rejected. [RT #43665]

</para>

</listitem>

<listitem>

<para>

<command>named</command> could hang when encountering log

file names with large apparent gaps in version number (for

example, when files exist called "logfile.0", "logfile.1",

and "logfile.1482954169"). This is now handled correctly.

[RT #38688]

</para>

</listitem>

<listitem>

<para>

If a zone was updated while <command>named</command> was

processing a query for nonexistent data, it could return

out-of-sync NSEC3 records causing potential DNSSEC validation

failure. [RT #43247]

</para>

</listitem>

</itemizedlist>

</section>

<section xml:id="relnotes_maint"><info><title>Maintenance</title></info>

<itemizedlist>

<listitem>

<para>

The built-in root hints have been updated to include an

IPv6 address (2001:500:12::d0d) for G.ROOT-SERVERS.NET.

</para>

</listitem>

</itemizedlist>

</section>

<section xml:id="relnotes_misc"><info><title>Miscellaneous Notes</title></info>

<itemizedlist>

<listitem>

<para>

Authoritative server support for the EDNS Client Subnet option

(ECS), introduced in BIND 9.11.0, was based on an early version

of the specification, and is now known to have incompatibilities

with other ECS implementations. It is also inefficient, requiring

a separate view for each answer, and is unable to correct for

overlapping subnets in the configuration. It is intended for

testing purposes but is not recommended for for production use.

This was not made sufficiently clear in the documentation at

the time of release.

</para>

</listitem>

</itemizedlist>

</section>

<section xml:id="end_of_life"><info><title>End of Life</title></info>

<para>

The end of life for BIND 9.11 is yet to be determined but

will not be before BIND 9.13.0 has been released for 6 months.

<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.isc.org/downloads/software-support-policy/">https://www.isc.org/downloads/software-support-policy/</link>

</para>

</section>

<section xml:id="relnotes_thanks"><info><title>Thank You</title></info>

<para>

Thank you to everyone who assisted us in making this release possible.

If you would like to contribute to ISC to assist us in continuing to

make quality open source software, please visit our donations page at

<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.isc.org/donate/">http://www.isc.org/donate/</link>.

</para>

</section>

</section>