Knowledge Base ISC Main Website Ask a Question/Contact ISC
BIND 9.10.5-S1 Release Notes
Author: Michael McNally Reference Number: AA-01488 Views: 5227 Created: 2017-04-19 21:57 Last Updated: 2017-04-19 21:57 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.

Download

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.

New DNSSEC Root Key

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 .

Security Fixes

  • 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]

New Features

  • 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.

Feature Changes

  • 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]

Performance Fixes

  • Adaptive read-write locks reduce system overhead when a lock is only held for a brief time. This can significantly increase performance on multiprocessor systems. [RT #37329]

Bug Fixes

  • 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]

End of Life

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

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-2017 Internet Systems Consortium

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.

Feedback
  • There is no feedback for this article
Quick Jump Menu