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
|
|
|
|
|
~~~~~~~~~~~~~~
|
|
|
|
|
|
2021-02-03 11:21:16 +11:00
|
|
|
- A malformed incoming IXFR transfer could trigger an assertion failure
|
|
|
|
|
in ``named``, causing it to quit abnormally. (CVE-2021-25214)
|
|
|
|
|
|
|
|
|
|
ISC would like to thank Greg Kuechle of SaskTel for bringing this
|
|
|
|
|
vulnerability to our attention. [GL #2467]
|
2021-03-18 15:58:15 +01:00
|
|
|
|
2021-03-01 16:08:21 +11:00
|
|
|
- ``named`` crashed when a DNAME record placed in the ANSWER section
|
|
|
|
|
during DNAME chasing turned out to be the final answer to a client
|
|
|
|
|
query. (CVE-2021-25215)
|
|
|
|
|
|
|
|
|
|
ISC would like to thank `Siva Kakarla`_ for bringing this
|
|
|
|
|
vulnerability to our attention. [GL #2540]
|
|
|
|
|
|
|
|
|
|
.. _Siva Kakarla: https://github.com/sivakesava1
|
|
|
|
|
|
2021-03-18 15:58:15 +01:00
|
|
|
Known Issues
|
|
|
|
|
~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
- None.
|
|
|
|
|
|
|
|
|
|
New Features
|
|
|
|
|
~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
- None.
|
|
|
|
|
|
|
|
|
|
Removed Features
|
|
|
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
- None.
|
|
|
|
|
|
|
|
|
|
Feature Changes
|
|
|
|
|
~~~~~~~~~~~~~~~
|
|
|
|
|
|
2021-04-12 12:15:45 +02:00
|
|
|
- The ISC implementation of SPNEGO was removed from BIND 9 source code.
|
|
|
|
|
Instead, BIND 9 now always uses the SPNEGO implementation provided by
|
|
|
|
|
the system GSSAPI library when it is built with GSSAPI support. All
|
|
|
|
|
major contemporary Kerberos/GSSAPI libraries contain an implementation
|
|
|
|
|
of the SPNEGO mechanism. This change was introduced 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-22 15:53:47 +01:00
|
|
|
- Implement ``draft-vandijk-dnsop-nsec-ttl``, NSEC(3) TTL values are now set to
|
|
|
|
|
the minimum of the SOA MINIMUM value and the SOA TTL. [GL #2347].
|
|
|
|
|
|
2021-04-21 11:45:56 +10:00
|
|
|
- Reduce the supported maximum number of iterations that can be
|
|
|
|
|
configured in an NSEC3 zones to 150. [GL #2642]
|
|
|
|
|
|
2021-03-18 15:58:15 +01:00
|
|
|
Bug Fixes
|
|
|
|
|
~~~~~~~~~
|
|
|
|
|
|
2021-04-12 12:15:45 +02:00
|
|
|
- TCP idle and initial timeouts were being incorrectly applied: only the
|
|
|
|
|
``tcp-initial-timeout`` was applied on the whole connection, even if
|
|
|
|
|
the connection were still active, which could prevent a large zone
|
|
|
|
|
transfer from being 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
|
|
|
|
|
has been fixed. [GL #2583]
|
2021-03-26 12:25:20 +01:00
|
|
|
|
|
|
|
|
- When ``stale-answer-client-timeout`` was set to a positive value and
|
2021-04-12 12:15:45 +02:00
|
|
|
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]
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
2021-04-12 12:15:45 +02:00
|
|
|
- CDS/CDNSKEY DELETE records are now removed when a zone transitions
|
|
|
|
|
from a secure to an insecure state. ``named-checkzone`` also no longer
|
|
|
|
|
reports an error when such records are found in an unsigned zone.
|
|
|
|
|
[GL #2517]
|
|
|
|
|
|
|
|
|
|
- Zones using KASP could not be thawed after they were frozen using
|
|
|
|
|
``rndc freeze``. This has been fixed. [GL #2523]
|
|
|
|
|
|
|
|
|
|
- After ``rndc checkds -checkds`` or ``rndc dnssec -rollover`` is used,
|
|
|
|
|
``named`` now immediately attempts to reconfigure zone keys. This
|
|
|
|
|
change prevents unnecessary key rollover delays. [GL #2488]
|
|
|
|
|
|
|
|
|
|
- ``named`` crashed after skipping a primary server while transferring a
|
|
|
|
|
zone over TLS. This has been fixed. [GL #2562]
|
|
|
|
|
|
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]
|
2021-04-12 10:43:56 +10:00
|
|
|
|
|
|
|
|
- ``named`` would overwrite a zone file unconditionally when it recovered from
|
|
|
|
|
a corrupted journal. [GL #2623]
|
2021-04-19 16:24:26 +02:00
|
|
|
|
|
|
|
|
- After the networking manager was introduced to ``named`` to handle
|
|
|
|
|
incoming traffic, it was discovered that the recursive performance had been
|
|
|
|
|
degraded compared to the previous version (9.11). This has been now fixed by
|
|
|
|
|
running internal tasks inside the networking manager worker threads, so
|
|
|
|
|
they do not compete for resources. [GL #2638]
|
2021-04-12 16:25:49 +02:00
|
|
|
|
|
|
|
|
- With ``dnssec-policy``, when creating new keys also check for keyid conflicts
|
|
|
|
|
between the new keys too. [GL #2628]
|
