|
BIND 9.10.5-S3 Release Notes
Author: Michael McNally Reference Number: AA-01505 Views: 2377 Created: 2017-06-29 19:46 Last Updated: 2017-06-29 19:46 |
0 Rating/ Voters
|
    |
Introduction
This is a release of the BIND 9.10 Supported Preview Edition,
a special feature preview branch of BIND which is available to
ISC customers.
This document summarizes significant changes since the last
production release of BIND on the corresponding major release
branch. Please see the file CHANGES for a complete list of bug
fixes and other changes, or CHANGES.SE for a list of changes
that have been applied specifically to the Supported Preview
edition.
BIND 9.10.5-S2 addresses the security issues described in
CVE-2017-3140 and CVE-2017-3141.
BIND 9.10.5-S3 addresses the security issues described in
CVE-2017-3142 and CVE-2017-3143. It also includes an update
to the address of the B root server.
The latest versions of BIND 9 software can always be found at
http://www.isc.org/downloads/.
There you will find additional information about each release,
source code, and pre-compiled versions for Microsoft Windows
operating systems.
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 managed-keys
statement, or if the pre-configured root key is enabled by using
dnssec-validation auto, 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
trusted-keys statement are not automatically
maintained. If your server is performing DNSSEC validation
and is configured using trusted-keys, 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.
This release includes an updated version of the
bind.keys file containing the new root
key. This file can also be downloaded from
https://www.isc.org/bind-keys
.
-
An error in TSIG handling could permit unauthorized zone
transfers or zone updates. These flaws are disclosed in
CVE-2017-3142 and CVE-2017-3143. [RT #45383]
-
The BIND installer on Windows used an unquoted service path,
which can enable privilege escalation. This flaw is disclosed
in CVE-2017-3141. [RT #45229]
-
With certain RPZ configurations, a response with TTL 0
could cause named to go into an infinite
query loop. This flaw is disclosed in CVE-2017-3140.
[RT #45181]
-
rndc "" could trigger an assertion failure
in named. This flaw is disclosed in
(CVE-2017-3138). [RT #44924]
-
Some chaining (i.e., type CNAME or DNAME) responses to upstream
queries could trigger assertion failures. This flaw is disclosed
in CVE-2017-3137. [RT #44734]
-
dns64 with break-dnssec yes;
can result in an assertion failure. This flaw is disclosed in
CVE-2017-3136. [RT #44653]
-
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]
-
A coding error in the nxdomain-redirect 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]
-
named could mishandle authority sections
with missing RRSIGs, triggering an assertion failure. This
flaw is disclosed in CVE-2016-9444. [RT #43632]
-
named 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]
-
named 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]
-
It was possible to trigger assertions when processing
responses containing answers of type DNAME. This flaw is
disclosed in CVE-2016-8864. [RT #43465]
-
Added the ability to specify the maximum number of records
permitted in a zone (max-records #; ).
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]
-
It was possible to trigger an assertion when rendering a
message using a specially crafted request. This flaw is
disclosed in CVE-2016-2776. [RT #43139]
-
Calling getrrsetbyname() with a non
absolute name could trigger an infinite recursion bug in
lwresd or named with
lwres configured if, when combined with
a search list entry from resolv.conf ,
the resulting name is too long. This flaw is disclosed in
CVE-2016-2775. [RT #42694]
-
This release introduces support for the EDNS CLIENT-SUBNET (ECS)
option in recursive servers.
-
ECS options are generated when sending recursive
queries to zones listed in
ecs-zones .
-
ECS options from the client are forwarded when sending queries
to whitelisted domains if the client is in allowed by the
ecs-forward ACL, or when the source prefix
length is 0
-
ECS options are never sent for DNS infrastructure types (i.e.,
NS, SOA, DNSKEY, etc) as these are presumed to be of global
scope. ECS queries can be further restricted to a specific set
of query types by using the
ecs-types option.
-
ECS options are sent using a default source prefix length of 24
for IPv4 queries and 56 for IPv6 queries. These defaults can be
reduced to lower values by using
ecs-bits , or
on a per-domain basis in the ecs-zones option.
-
Servers that do not support ECS can be blacklisted using
server IPADDR { ecs no; };
-
The dns_db API and the red-black tree database implementation
have been updated to allow storage and retrieval of data tagged
with ECS information.
See the ARM for more details of these options.
-
The EDNS CLIENT SUBNET (ECS) option is also experimentally
supported for authoritative servers: if an authoritative
query contains an ECS option, then ACLs containing
geoip or ecs elements
can be matched against the address or prefix encoded in the
option. This can be used to select a view for the query,
so that different answers can be provided depending on the
client network. Note, however, that this authoritative
support is based on an outdated version of the ECS specification;
in its current form it may be useful for testing, but is
not recommended for production use. Thanks to Vincent Bernat
for the contribution. [RT #36781]
-
This release supports dnstap, a fast,
flexible method for capturing and logging DNS traffic,
developed by Robert Edmonds at Farsight Security, Inc.,
whose assistance is gratefully acknowledged.
To enable dnstap at compile time,
the fstrm and protobuf-c
libraries must be available, and BIND must be configured with
--enable-dnstap .
dnstap data can be logged in two modes:
to a file, or to a UNIX-domain socket, from which it can be
collected by an external utility such as
fstrm_capture.
A new utility dnstap-read has been added
to allow dnstap data files to be presented in
a human-readable format.
rndc dnstap -roll causes dnstap
output files to be rolled like log files -- the most recent output
file is renamed with a .0 suffix, the next
most recent with .1 , etc. (Note that this
only works when dnstap output is being written
to a file, not to a UNIX domain socket.) An optional numerical
argument specifies how many backup log files to retain; if not
specified or if set to 0, there is no limit.
dnstap logfiles can also be configured to
automatically roll when they reach a specified size, by specifying
size and versions parameters
to the dnstap-output option.
<listitem>
</listitem>
For more information on dnstap, see
http://dnstap.info.
-
When answering recursive queries, SERVFAIL responses can now be
cached by the server for a limited time; subsequent queries for
the same query name and type will return another SERVFAIL until
the cache times out. This reduces the frequency of retries
when a query is persistently failing, which can be a burden
on recursive servers. The SERVFAIL cache timeout is controlled
by servfail-ttl , which defaults to 1 second
and has an upper limit of 30.
-
The nxdomain-redirect option specifies
a DNS namespace to use for NXDOMAIN redirection. When a
recursive lookup returns NXDOMAIN, a second lookup is
initiated with the specified name appended to the query
name. This allows NXDOMAIN redirection data to be supplied
by multiple zones configured on the server, or by recursive
queries to other servers. (The older method, using
a single type redirect zone, has
better average performance but is less flexible.) [RT #37989]
-
The rndc nta command can be used to
set a "negative trust anchor" (NTA), disabling DNSSEC validation for
a specific domain. This can be used when responses from a domain
are known to be failing validation due to administrative error
rather than because of a spoofing attack.
NTAs are strictly temporary; by default they expire after one
hour, but can be configured to last up to one week. The default
NTA lifetime can be changed by setting the
nta-lifetime in named.conf .
By default, the domain covered
by an NTA is checked periodically by named
to see if it can now be successfully validated; if it can, the
NTA is immediately removed. The recheck frequency can
be configured using the nta-recheck option,
which defaults to five minutes. Rechecks can be disabled on a
per-NTA basis by using the rndc nta -force
parameter.
When added, NTAs are stored in a
file (viewname .nta )
in order to persist across restarts of the named
server.
-
rndc can now return text output of arbitrary
size to the caller. Prior to this, certain commands such as
rndc tsig-list and
rndc zonestatus could return truncated output.
[RT #37731]
-
Added support for the EDNS TCP Keepalive option (RFC 7828);
this allows negotiation of longer-lived TCP sessions
to reduce the overhead of setting up TCP for individual
queries. [RT #42126]
-
Added support for the EDNS Padding option (RFC 7830),
which obfuscates packet size analysis when DNS queries
are sent over an encrypted channel. [RT #42094]
-
Added server-side support for pipelined TCP queries. Multiple
queries from a single client can be received over the same TCP
connection; the connection is no longer closed after the first
query. All queries received over such a connection are handled
in parallel.
To revert to the former behavior for a particular
client address or range of addresses, specify the address prefix
in the keep-response-order option.
To revert to the former behavior for all clients, use
keep-response order { any; };.
-
A read-only option is now available in the
controls statement to grant non-destructive
control channel access. In such cases, a restricted set of
rndc commands are allowed, which can
report information from named, but cannot
reconfigure or stop the server. By default, the control channel
access is not restricted to these
read-only operations.
-
The print-time option in the
logging configuration can now take arguments
local, iso8601 or
iso8601-utc to indicate the format in
which the date and time should be logged. For backward
compatibility, yes is a synonym for
local. [RT #42585]
-
When sending queries to authoritative name servers,
IPv6 servers are now given a slight preference over
IPv4 servers. The best server to use is chosen on the
basis of its measured round trip time (RTT); IPv4
servers are penalized by 50 milliseconds by default.
This value is configurable using the v6-bias
option.
-
NOTIFY messages now have separate rate limiting queues.
Instead of being limited by the serial-query-rate
option (which controls the rate at which SOA queries are sent
by slave zones to master zones), the rate at which NOTIFY
messages are sent to slaves is now controlled by
notify-rate and
startup-notify-rate (which applies to
NOTIFY messages sent when a server is first started).
This can improve startup time on servers hosting a large
number of zones. [RT #24454]
-
New classification options have been added for response rate
limiting (RRL):
-
Multiple
rate-limit statements can now be
configured, each defined by a specific domain .
This allows different rate limiting options to be applied for
different namespaces.
-
Each rate limiter may be configured with up to five
responses-per-second options, with the
value selected depending on the size of the response or
the ratio of the response size to the query size (i.e.,
the amplification factor). For example, responses could
rate limited to 10 per second in general, but only 2 per
second for responses larger than 1100 bytes.
-
Query logging now includes the ECS option, if one was
present in the query, in the format
"[ECS address/source/scope ]".
-
dnstap now stores both the local and remote
addresses for all messages, instead of only the remote address.
The default output format for dnstap-read 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]
-
The Response Policy Zone (RPZ) implementation has been
substantially refactored: updates to the RPZ summary
database are no longer directly performed by the zone
database but by a separate function that is called when
a policy zone is updated. This improves both performance
and reliability when policy zones receive frequent updates.
Summary database updates can be rate-limited by using the
min-update-interval option in a
response-policy statement. [RT #43449]
-
The names of the files used to store managed keys and added
zones for each view are no longer based on the SHA256 hash
of the view name, except when this is necessary because the
view name contains characters that would be incompatible with use
as a file name. For views whose names do not contain forward
slashes ('/'), backslashes ('\'), or capital letters - which
could potentially cause namespace collision problems on
case-insensitive filesystems - files will now be named
after the view (for example, internal.mkeys
or external.nzf ). However, to ensure
consistent behavior when upgrading, if a file using the old
name format is found to exist, it will continue to be used.
[RT #37704]
-
"rndc" can now return text output of arbitrary size to
the caller. (Prior to this, certain commands such as
"rndc tsig-list" and "rndc zonestatus" could return
truncated output.) [RT #37731]
-
The EDNS COOKIE option is now compiled in by default; it is
no longer necessary to use
configure --enable-sit to enable it.
-
Similarly, recursive fetch limits
(fetches-per-server and
fetches-per-zone ) are also compiled in by
default; it is no longer necessary to use
configure --enable-fetchlimit to enable them.
-
Expanded and improved the YAML output from
dnstap-read -y: it now includes packet
size and a detailed breakdown of message contents.
[RT #43622] [RT #43642]
-
A flag could be set in the wrong field when setting up
nonrecursive queries; this could cause the SERVFAIL cache to
cache responses it shouldn't, and in some circumstances
lead to an assertion failure. New querytrace logging has been
added which identified this error. [RT #41155]
-
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]
-
named could deadlock if multiple changes
to NSEC/NSEC3 parameters for the same zone were being processed
at the same time. [RT #42770]
-
named could trigger an assertion when
sending NOTIFY messages. [RT #44019]
The end of life for BIND 9.10 is yet to be determined but
will not be before BIND 9.12.0 has been released for 6 months.
BIND 9.10-S (Supported Preview Edition) releases
will continue to be published in tandem with BIND 9.10 releases
until the Supported Preview Edition moves to new branch. This
may happen before BIND 9.10 reaches end of life, but not later. See
https://www.isc.org/downloads/software-support-policy/
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
http://www.isc.org/donate/.
© 2001-2018 Internet Systems ConsortiumFor assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.
|
|
|
|
|
|
|