BIND 9.19 is an unstable development release of BIND. This document summarizes new features and functional changes that have been introduced on this branch. With each development release leading up to the stable BIND 9.20 release, this document will be updated with additional features added and bugs fixed. Please see the CHANGES file for a more detailed list of changes and bug fixes.
The latest versions of BIND 9 software can always be found at https://www.isc.org/download/. There you will find additional information about each release, and source code.
The DNSSEC algorithms RSASHA1 and NSEC3RSASHA1 are now automatically disabled on systems where they are disallowed by the security policy (e.g. Red Hat Enterprise Linux 9). Primary zones using those algorithms need to be migrated to new algorithms prior to running on these systems, as graceful migration to different DNSSEC algorithms is not possible when RSASHA1 is disallowed by the operating system. [GL #3469]
Log messages related to fetch limiting have been improved to provide more complete information. Specifically, the final counts of allowed and spilled fetches are now logged before the counter object is destroyed. [GL #3461]
When running as a validating resolver forwarding all queries to another resolver,
namedcould crash with an assertion failure. These crashes occurred when the configured forwarder sent a broken DS response and
namedfailed its attempts to find a proper one instead. This has been fixed. [GL #3439]
DNS compression is no longer applied to the root name (
.) if it is repeatedly used in the same RRset. [GL #3423]
glue-cacheoption has been removed. The glue cache feature still works and is now permanently enabled. [GL #2147]
dnssec-signzone -Hdefault value has been changed to 0 additional NSEC3 iterations. This change aligns the
dnssec-signzonedefault with the default used by the
dnssec-policyfeature. At the same time, documentation about NSEC3 has been aligned with the Best Current Practice. [GL #3395]
An assertion failure caused by a TCP connection closing between a connect (or accept) and a read from a socket has been fixed. [GL #3400]
When grafting non-delegated namespace onto delegated namespace,
synth-from-dnsseccould incorrectly synthesize non-existence of records within the non-delegated namespace using NSEC records from higher zones. [GL #3402]
namedimmediately returned a SERVFAIL response to the client when it received a FORMERR response from an authoritative server during recursive resolution. This has been fixed:
namedacting as a resolver now attempts to contact other authoritative servers for a given domain when it receives a FORMERR response from one of them. [GL #3152]
It was possible for a catalog zone consumer to process a catalog zone member zone when there was a configured pre-existing forward-only forward zone with the same name. This has been fixed. [GL #2506]
fetches-per-serverquota is designed to adjust itself downward automatically when an authoritative server times out too frequently. Due to a coding error, that adjustment was applied incorrectly, so that the quota for a congested server was always set to 1. This has been fixed. [GL #3327]
DNSSEC-signed catalog zones were not being processed correctly. This has been fixed. [GL #3380]
Key files were updated every time the
dnssec-policykey manager ran, whether the metadata had changed or not.
namednow checks whether changes were applied before writing out the key files. [GL #3302]
Previously, TLS socket objects could be destroyed prematurely, which triggered assertion failures in
namedinstances serving DNS-over-HTTPS (DoH) clients. This has been fixed.
ISC would like to thank Thomas Amgarten from arcade solutions ag for bringing this vulnerability to our attention. (CVE-2022-1183) [GL #3216]
Catalog Zones schema version 2, as described in the “DNS Catalog Zones” IETF draft version 5 document, is now supported by
named. All of the previously supported BIND-specific catalog zone custom properties (
allow-transfer), as well as the new Change of Ownership (
coo) property, are now implemented. Schema version 1 is still supported, with some additional validation rules applied from schema version 2: for example, the
versionproperty is mandatory, and a member zone PTR RRset must not contain more than one record. In the event of a validation error, a corresponding error message is logged to help with diagnosing the problem. [GL #3221] [GL #3222] [GL #3223] [GL #3224] [GL #3225]
The Object Identifier (OID) embedded at the start of a PRIVATEOID public key in a KEY, DNSKEY, CDNSKEY, or RKEY resource records is now checked to ensure that it is valid when reading from zone files or receiving data on the wire. The Object Identifier is now printed when the
dig +rrcommentsoption is used. Similarly, the name embedded at the start of a PRIVATEDNS public key is also checked for validity. [GL #3234]
The Object Identifier (OID) embedded at the start of a PRIVATEOID signature in a SIG, or RRSIG resource records is now checked to ensure that it is valid when reading from zone files or receiving data on the wire. Similarly, the name embedded at the start of a PRIVATEDNS public key is also checked for validity. [GL #3296]
Previously, CDS and CDNSKEY DELETE records were removed from the zone when configured with the
auto-dnssec maintain;option. This has been fixed. [GL #2931]
According to RFC 8310, Section 8.1, the
Subjectfield MUST NOT be inspected when verifying a remote certificate while establishing a DNS-over-TLS connection. Only
subjectAltNamemust be checked instead. Unfortunately, some quite old versions of cryptographic libraries might lack the ability to ignore the
Subjectfield. This should have minimal production-use consequences, as most of the production-ready certificates issued by certificate authorities will have
subjectAltNameset. In such cases, the
Subjectfield is ignored. Only old platforms are affected by this, e.g. those supplied with OpenSSL versions older than 1.1.1. [GL #3163]
BIND 9 is open source software licensed under the terms of the Mozilla Public
License, version 2.0 (see the
COPYING file for the full text).
Those wishing to discuss license compliance may contact ISC at https://www.isc.org/contact/.
BIND 9.19 is an unstable development branch. When its development is complete, it will be renamed to BIND 9.20, which will be a stable branch. The end-of-life date for BIND 9.20 has not yet been determined. For those needing long-term stability, the current Extended Support Version (ESV) is BIND 9.16, which will be supported until at least December 2023. See https://kb.isc.org/docs/aa-00896 for details of ISC’s software support policy.
Thank you to everyone who assisted us in making this release possible.