| Author: Brian Conry Reference Number: AA-01256 Views: 10282 Created: 2015-02-25 22:48 Last Updated: 2015-02-25 22:48
0 Rating/ Voters
Release Notes for BIND Version 9.9.7
This document summarizes changes since the last production release
of BIND on the corresponding major release branch.
The latest versions of BIND 9 software can always be found at
There you will find additional information about each release,
source code, and pre-compiled versions for Microsoft Windows
On servers configured to perform DNSSEC validation using
managed trust anchors (i.e., keys configured explicitly
via managed-keys, or implicitly
via dnssec-validation auto; or
dnssec-lookaside auto;), revoking
a trust anchor and sending a new untrusted replacement
could cause named to crash with an
assertion failure. This could occur in the event of a
botched key rollover, or potentially as a result of a
deliberate attack if the attacker was in position to
monitor the victim's DNS traffic.
This flaw was discovered by Jan-Piet Mens, and is
disclosed in CVE-2015-1349. [RT #38344]
A flaw in delegation handling could be exploited to put
named into an infinite loop, in which
each lookup of a name server triggered additional lookups
of more name servers. This has been addressed by placing
limits on the number of levels of recursion
named will allow (default 7), and
on the number of queries that it will send before
terminating a recursive query (default 50).
The recursion depth limit is configured via the
max-recursion-depth option, and the query limit
The flaw was discovered by Florian Maury of ANSSI, and is
disclosed in CVE-2014-8500. [RT #37580]
NXDOMAIN responses to queries of type DS are now cached separately
from those for other types. This helps when using "grafted" zones
of type forward, for which the parent zone does not contain a
delegation, such as local top-level domains. Previously a query
of type DS for such a zone could cause the zone apex to be cached
as NXDOMAIN, blocking all subsequent queries. (Note: This
change is only helpful when DNSSEC validation is not enabled.
"Grafted" zones without a delegation in the parent are not a
NOTIFY messages that are sent because a zone has been updated
are now given priority above NOTIFY messages that were scheduled
when the server started up. This should mitigate delays in zone
propagation when servers are restarted frequently.
Errors reported when running rndc addzone
(e.g., when a zone file cannot be loaded) have been clarified
to make it easier to diagnose problems.
Added support for OPENPGPKEY type.
When encountering an authoritative name server whose name is
an alias pointing to another name, the resolver treats
this as an error and skips to the next server. Previously
this happened silently; now the error will be logged to
the newly-created "cname" log category.
If named is not configured to validate the answer then
allow fallback to plain DNS on timeout even when we know
the server supports EDNS. This will allow the server to
potentially resolve signed queries when TCP is being
dig, host and
nslookup aborted when encountering
a name which, after appending search list elements,
exceeded 255 bytes. Such names are now skipped, but
processing of other names will continue. [RT #36892]
The error message generated when
named-checkconf -z encounters a
$TTL directive without a value has
been clarified. [RT #37138]
Semicolon characters (;) included in TXT records were
incorrectly escaped with a backslash when the record was
displayed as text. This is actually only necessary when there
are no quotation marks. [RT #37159]
When files opened for writing by named,
such as zone journal files, were referenced more than once
named.conf, it could lead to file
corruption as multiple threads wrote to the same file. This
is now detected when loading
and reported as an error. [RT #37172]
dnssec-keygen -S failed to generate successor
keys for some algorithm types (including ECDSA and GOST) due to
a difference in the content of private key files. This has been
corrected. [RT #37183]
UPDATE messages that arrived too soon after
an rndc thaw could be lost. [RT #37233]
Forwarding of UPDATE messages did not work when they were
signed with SIG(0); they resulted in a BADSIG response code.
When checking for updates to trust anchors listed in
now revalidates keys based on the current set of
active trust anchors, without relying on any cached
record of previous validation. [RT #37506]
When NXDOMAIN redirection is in use, queries for a name
that is present in the redirection zone but a type that
is not present will now return NOERROR instead of NXDOMAIN.
When a zone contained a delegation to an IPv6 name server
but not an IPv4 name server, it was possible for a memory
reference to be left un-freed. This caused an assertion
failure on server shutdown, but was otherwise harmless.
Due to an inadvertent removal of code in the previous
release, when named encountered an
authoritative name server which dropped all EDNS queries,
it did not always try plain DNS. This has been corrected.
A regression caused nsupdate to use the default recursive servers
rather than the SOA MNAME server when sending the UPDATE.
Adjusted max-recursion-queries to better accommodate empty
Built-in "empty" zones did not correctly inherit the
"allow-transfer" ACL from the options or view. [RT #38310]
A mutex leak was fixed that could cause named
processes to grow to very large sizes. [RT #38454]
Fixed some bugs in RFC 5011 trust anchor management,
including a memory leak and a possible loss of state
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
© 2001-2016 Internet Systems ConsortiumPlease help us to improve the content of our knowledge base by letting us know below how we can improve this article. If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback. For 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.