2021-03-18 15:58:15 +01:00
|
|
|
..
|
|
|
|
|
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
|
|
|
|
|
|
|
|
|
|
This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
file, you can obtain one at https://mozilla.org/MPL/2.0/.
|
|
|
|
|
|
|
|
|
|
See the COPYRIGHT file distributed with this work for additional
|
|
|
|
|
information regarding copyright ownership.
|
|
|
|
|
|
|
|
|
|
Notes for BIND 9.17.12
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
Security Fixes
|
|
|
|
|
~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
- None.
|
|
|
|
|
|
|
|
|
|
Known Issues
|
|
|
|
|
~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
- None.
|
|
|
|
|
|
|
|
|
|
New Features
|
|
|
|
|
~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
- None.
|
|
|
|
|
|
|
|
|
|
Removed Features
|
|
|
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
- None.
|
|
|
|
|
|
|
|
|
|
Feature Changes
|
|
|
|
|
~~~~~~~~~~~~~~~
|
|
|
|
|
|
2021-04-01 10:28:06 +02:00
|
|
|
- The GSSAPI no longer uses the ISC implementation of the SPNEGO
|
|
|
|
|
mechanism and instead relies on the SPNEGO implementation from the
|
|
|
|
|
system Kerberos library. All major Kerberos libraries contain the
|
|
|
|
|
SPNEGO mechanism implementation. This change was implemented in BIND
|
|
|
|
|
9.17.2, but it was not included in the release notes at the time.
|
|
|
|
|
[GL #2607]
|
2021-03-18 15:58:15 +01:00
|
|
|
|
2021-04-02 14:33:54 +02:00
|
|
|
- The default value for the ``stale-answer-client-timeout`` option was
|
|
|
|
|
changed from ``1800`` (ms) to ``off``. The default value may be
|
|
|
|
|
changed again in future releases as this feature matures. [GL #2608]
|
|
|
|
|
|
2021-03-18 15:58:15 +01:00
|
|
|
Bug Fixes
|
|
|
|
|
~~~~~~~~~
|
|
|
|
|
|
2021-03-17 15:57:34 +01:00
|
|
|
- When calling ``rndc dnssec -rollover`` or ``rndc checkds -checkds``,
|
|
|
|
|
``named`` now updates the keys immediately, avoiding unnecessary rollover
|
|
|
|
|
delays. [#2488]
|
|
|
|
|
|
2021-03-18 15:58:15 +01:00
|
|
|
- Dynamic zones with ``dnssec-policy`` that were frozen could not be thawed.
|
|
|
|
|
This has been fixed. [GL #2523]
|
|
|
|
|
|
2021-03-17 10:09:59 +01:00
|
|
|
- CDS/CDNSKEY DELETE records are now removed when a zone transitioned from
|
|
|
|
|
secure to insecure. "named-checkzone" no longer complains if such records
|
|
|
|
|
exist in an unsigned zone. [GL #2517]
|
|
|
|
|
|
2021-03-18 15:58:15 +01:00
|
|
|
- Fix a crash when transferring a zone over TLS, after "named" previously
|
|
|
|
|
skipped a master. [GL #2562]
|
2021-03-17 13:42:19 +01:00
|
|
|
|
|
|
|
|
- It was discovered that the TCP idle and initial timeouts were incorrectly
|
|
|
|
|
applied in the BIND 9.16 and 9.17 branches. Only the ``tcp-initial-timeout``
|
|
|
|
|
was applied on the whole connection, even if the connection were still active,
|
|
|
|
|
which could cause a large zone transfer to be sent back to the client. The
|
|
|
|
|
default setting for ``tcp-initial-timeout`` was 30 seconds, which meant that
|
|
|
|
|
any TCP connection taking more than 30 seconds was abruptly terminated. This
|
2021-03-26 12:25:20 +01:00
|
|
|
has been fixed. [GL #2573]
|
|
|
|
|
|
|
|
|
|
- When ``stale-answer-client-timeout`` was set to a positive value and
|
|
|
|
|
recursion for a client query completed when ``named`` was about to look for
|
|
|
|
|
a stale answer, an assertion could fail in ``query_respond()``, resulting in
|
|
|
|
|
a crash. This has been fixed. [GL #2594]
|
2021-03-31 15:15:19 +11:00
|
|
|
|
|
|
|
|
- After upgrading to the previous release, journal files for trust anchor
|
|
|
|
|
databases (e.g., ``managed-keys.bind.jnl``) could be left in a corrupt
|
|
|
|
|
state. (Other zone journal files were not affected.) This has been
|
|
|
|
|
fixed. If a corrupt journal file is detected, ``named`` can now recover
|
|
|
|
|
from it. [GL #2600]
|
Fix nonsensical stale TTL values in cache dump
When introducing change 5149, "rndc dumpdb" started to print a line
above a stale RRset, indicating how long the data will be retained.
At that time, I thought it should also be possible to load
a cache from file. But if a TTL has a value of 0 (because it is stale),
stale entries wouldn't be loaded from file. So, I added the
'max-stale-ttl' to TTL values, and adjusted the $DATE accordingly.
Since we actually don't have a "load cache from file" feature, this
is premature and is causing confusion at operators. This commit
changes the 'max-stale-ttl' adjustments.
A check in the serve-stale system test is added for a non-stale
RRset (longttl.example) to make sure the TTL in cache is sensible.
Also, the comment above stale RRsets could have nonsensical
values. A possible reason why this may happen is when the RRset was
marked a stale but the 'max-stale-ttl' has passed (and is actually an
RRset awaiting cleanup). This would lead to the "will be retained"
value to be negative (but since it is stored in an uint32_t, you would
get a nonsensical value (e.g. 4294362497).
To mitigate against this, we now also check if the header is not
ancient. In addition we check if the stale_ttl would be negative, and
if so we set it to 0. Most likely this will not happen because the
header would already have been marked ancient, but there is a possible
race condition where the 'rdh_ttl + serve_stale_ttl' has passed,
but the header has not been checked for staleness.
2021-03-10 12:09:16 +01:00
|
|
|
|
|
|
|
|
- When dumping the cache to file, TTLs were being increased with
|
|
|
|
|
``max-stale-ttl``. Also the comment above stale RRsets could have nonsensical
|
|
|
|
|
values if the RRset was still marked a stale but the ``max-stale-ttl`` has
|
|
|
|
|
passed (and is actually an RRset awaiting cleanup). Both issues have now
|
|
|
|
|
been fixed. [GL #389] [GL #2289]
|
