bind bind9 9.16.13

[Douglas R. Reno]

New point version

See ticket #14683 for reasoning behind revert to 9.16.11.

[Douglas R. Reno]

Now 9.16.13

[Douglas R. Reno]

Notes for BIND 9.16.13
New Features

    A new purge-keys option has been added to dnssec-policy. It sets the period of time that key files are retained after becoming obsolete due to a key rollover; the default is 90 days. This feature can be disabled by setting purge-keys to 0. [GL #2408]

Feature Changes

    When serve-stale is enabled and stale data is available, named now returns stale answers upon encountering any unexpected error in the query resolution process. This may happen, for example, if the fetches-per-server or fetches-per-zone limits are reached. In this case, named attempts to answer DNS requests with stale data, but does not start the stale-refresh-time window. [GL #2434]

Bug Fixes

    Zone journal (.jnl) files created by versions of named prior to 9.16.12 were no longer compatible; this could cause problems when upgrading if journal files were not synchronized first. This has been corrected: older journal files can now be read when starting up. When an old-style journal file is detected, it is updated to the new format immediately after loading.

    Note that journals created by the current version of named are not usable by versions prior to 9.16.12. Before downgrading to a prior release, users are advised to ensure that all dynamic zones have been synchronized using rndc sync -clean.

    A journal file’s format can be changed manually by running named-journalprint -d (downgrade) or named-journalprint -u (upgrade). Note that this must not be done while named is running. [GL #2505]

    named crashed when it was allowed to serve stale answers and stale-answer-client-timeout was triggered without any (stale) data available in the cache to answer the query. [GL #2503]

    If an outgoing packet exceeded max-udp-size, named dropped it instead of sending back a proper response. To prevent this problem, the IP_DONTFRAG option is no longer set on UDP sockets, which has been happening since BIND 9.16.11. [GL #2466]

    NSEC3 records were not immediately created when signing a dynamic zone using dnssec-policy with nsec3param. This has been fixed. [GL #2498]

    A memory leak occurred when named was reconfigured after adding an inline-signed zone with auto-dnssec maintain enabled. This has been fixed. [GL #2041]

    An invalid direction field (not one of N, S, E, W) in a LOC record resulted in an INSIST failure when a zone file containing such a record was loaded. [GL #2499]

Notes for BIND 9.16.12
Security Fixes

    When tkey-gssapi-keytab or tkey-gssapi-credential was configured, a specially crafted GSS-TSIG query could cause a buffer overflow in the ISC implementation of SPNEGO (a protocol enabling negotiation of the security mechanism to use for GSSAPI authentication). This flaw could be exploited to crash named. Theoretically, it also enabled remote code execution, but achieving the latter is very difficult in real-world conditions. (CVE-2020-8625)

    This vulnerability was responsibly reported to us as ZDI-CAN-12302 by Trend Micro Zero Day Initiative. [GL #2354]

New Features

    When a secondary server receives a large incremental zone transfer (IXFR), it can have a negative impact on query performance while the incremental changes are applied to the zone. To address this, named can now limit the size of IXFR responses it sends in response to zone transfer requests. If an IXFR response would be larger than an AXFR of the entire zone, it will send an AXFR response instead.

    This behavior is controlled by the max-ixfr-ratio option - a percentage value representing the ratio of IXFR size to the size of a full zone transfer. The default is 100%. [GL #1515]

    A new option, stale-answer-client-timeout, has been added to improve named’s behavior with respect to serving stale data. The option defines the amount of time named waits before attempting to answer the query with a stale RRset from cache. If a stale answer is found, named continues the ongoing fetches, attempting to refresh the RRset in cache until the resolver-query-timeout interval is reached.

    The default value is 1800 (in milliseconds) and the maximum value is limited to resolver-query-timeout minus one second. A value of 0 causes any available cached RRset to immediately be returned while still triggering a refresh of the data in cache.

    This new behavior can be disabled by setting stale-answer-client-timeout to off or disabled. The new option has no effect if stale-answer-enable is disabled. [GL #2247]

Feature Changes

    As part of an ongoing effort to use RFC 8499 terminology, primaries can now be used as a synonym for masters in named.conf. Similarly, notify primary-only can now be used as a synonym for notify master-only. The output of rndc zonestatus now uses primary and secondary terminology. [GL #1948]

    The default value of max-stale-ttl has been changed from 12 hours to 1 day and the default value of stale-answer-ttl has been changed from 1 second to 30 seconds, following RFC 8767 recommendations. [GL #2248]

    The SONAMEs for BIND 9 libraries now include the current BIND 9 version number, in an effort to tightly couple internal libraries with a specific release. This change makes the BIND 9 release process both simpler and more consistent while also unequivocally preventing BIND 9 binaries from silently loading wrong versions of shared libraries (or multiple versions of the same shared library) at startup. [GL #2387]

    When check-names is in effect, A records below an _spf, _spf_rate, or _spf_verify label (which are employed by the exists SPF mechanism defined in RFC 7208 section 5.7/appendix D.1) are no longer reported as warnings/errors. [GL #2377]

Bug Fixes

    named failed to start when its configuration included a zone with a non-builtin allow-update ACL attached. [GL #2413]

    Previously, dnssec-keyfromlabel crashed when operating on an ECDSA key. This has been fixed. [GL #2178]

    KASP incorrectly set signature validity to the value of the DNSKEY signature validity. This has been fixed. [GL #2383]

    When migrating to KASP, BIND 9 considered keys with the Inactive and/or Delete timing metadata to be possible active keys. This has been fixed. [GL #2406]

    Fix the “three is a crowd” key rollover bug in KASP. When keys rolled faster than the time required to finish the rollover procedure, the successor relation equation failed because it assumed only two keys were taking part in a rollover. This could lead to premature removal of predecessor keys. BIND 9 now implements a recursive successor relation, as described in the paper “Flexible and Robust Key Rollover” (Equation (2)). [GL #2375]

    Performance of the DNSSEC verification code (used by dnssec-signzone, dnssec-verify, and mirror zones) has been improved. [GL #2073]

We had a security patch to fix the security vulnerability fixed in 9.16.12, so we don't have to worry about that.

However, there was something noteworthy in the announcement:

About a zone transfer timeout issue introduced in BIND 9.16.11
--------------------------------------------------------------

As part of the reworking of BIND's networking code, the 9.16 branch has
been incorporating work done in the 9.17 experimental development branch.
Unfortunately, an error was introduced causing zone transfers that take
a substantial amount of time to be improperly marked as timed out,
as a result of which they are abandoned without completing.

The timeout error was introduced into the 9.16 branch in BIND 9.16.11
(via a backport from the development branch) and affects connections
which last longer than the value set for tcp-initial-timeout (which
defaults to a value of 30 seconds).  Zone transfers that cannot complete in
less than this period (due either to extreme size or very slow connections)
will time out, even if they were proceeding properly.

We plan to prioritize a fix for this at our first available opportunity,
but in the meantime a workaround which will serve for most operators
is to adjust the value set for "tcp-initial-timeout" to its maximum
allowed value of 1200 (representing a time period of 120 seconds).
This can be accomplished by adding the line:

     tcp-initial-timeout 1200;

to named.conf and restarting or reconfiguring the server, or can be
applied without requiring a configuration file change by using the
"rndc tcp-timeouts" command.

If your server deals with zones that are expected to take more than
120s to transfer, please visit the open ticket devoted to this issue
in our Gitlab issue tracker and ask about alternatives there:

     https://gitlab.isc.org/isc-projects/bind9/-/issues/2583

We apologize once again for the inconvenience.  We considered delaying
the March releases in order to include a fix, but there are operators
who are waiting for other changes that are included in those releases.
And despite the zone transfer timeout issue having been present in the
9.16 release branch since January, we have had only a single confirmed
report (owing to the fact that the vast majority of zone transfers can
be completed before the default timeout value comes into play).
We decided, therefore, to proceed with the release but with this context
added so that operators can make an informed decision based on the needs
of their own production environment.

I will make a patch rolling the upstream fix for this and drop it into the book. It'll be almost a month before the next release.

Fix for the TCP Timeout Regression can be found at ​https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4819

Additional fixes from upstream include:

​https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4832

​https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4811

​https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4833

[Douglas R. Reno]

The patch does introduce a couple of intermittent test failures, which seem to be due to queries taking a few milliseconds longer than expected. I suspect that will be fixed in the next version of BIND. In the meantime, functionality is not impacted, and the TCP timeout regression has been fixed.

[Douglas R. Reno]

Fixed at r24399

[Bruce Dubbs]

Milestone renamed