Security Fixes:
- DNS-over-HTTPS flooding fixes. (CVE-2024-12705)
- Limit additional section processing for large RDATA sets. (CVE-2024-11187)
New Features:
- Add a new option to configure the maximum number of outgoing queries per client request.
Bug Fixes:
- Fix nsupdate hang when processing a large update.
- Fix possible assertion failure when reloading server while processing update policy rules. [GL #5006]
- Fix dnssec-signzone signing non-DNSKEY RRsets with revoked keys.
- Fix improper handling of unknown directives in resolv.conf.
https://downloads.isc.org/isc/bind9/9.18.33/doc/arm/html/notes.html#notes-for-bind-9-18-33
Resolves: RHEL-48798
Drop original user creating in favor of sysusers file definition.
(cherry picked from commit 071ec07d27989a8d548834292fa46ca2312b4862)
Related: RHEL-48798
- Remove CHANGES file from package
Removed Features:
- Disable DLZ plugins, they are not shipped with bind anymore
New Features:
- new 2024 KSK root key
Feature Changes:
- max-records-per-type and max-types-per-name improved logging when
reached over their value
And NSEC3 and two dig bug fixes.
https://downloads.isc.org/isc/bind9/9.18.32/doc/arm/html/notes.html#notes-for-bind-9-18-32
Resolves: RHEL-48798
Security Fixes
- A malicious DNS client that sent many queries over TCP but never read the responses could cause a server to respond slowly or not at all for other clients. This has been fixed. (CVE-2024-0760) [GL #4481]
- It is possible to craft excessively large resource records sets, which have the effect of slowing down database processing. This has been addressed by adding a configurable limit to the number of records that can be stored per name and type in a cache or zone database. The default is 100, which can be tuned with the new max-records-per-type option. [GL #497] [GL #3405]
It is possible to craft excessively large numbers of resource record types for a given owner name, which has the effect of slowing down database processing. This has been addressed by adding a configurable limit to the number of records that can be stored per name and type in a cache or zone database. The default is 100, which can be tuned with the new max-types-per-name option. (CVE-2024-1737) [GL #3403]
ISC would like to thank Toshifumi Sakaguchi who independently discovered and responsibly reported the issue to ISC. [GL #4548]
- Validating DNS messages signed using the SIG(0) protocol (RFC 2931) could cause excessive CPU load, leading to a denial-of-service condition. Support for SIG(0) message validation was removed from this version of named. (CVE-2024-1975) [GL #4480]
- Due to a logic error, lookups that triggered serving stale data and required lookups in local authoritative zone data could have resulted in an assertion failure. This has been fixed. (CVE-2024-4076) [GL #4507]
Potential data races were found in our DoH implementation, related to HTTP/2 session object management and endpoints set object management after reconfiguration. These issues have been fixed. [GL #4473]
ISC would like to thank Dzintars and Ivo from nic.lv for bringing this to our attention.
When looking up the NS records of parent zones as part of looking up DS records, it was possible for named to trigger an assertion failure if serve-stale was enabled. This has been fixed. [GL #4661]
And bugfixes.
https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html
Resolves: RHEL-48798
New Features
- A new option signatures-jitter has been added to dnssec-policy to allow
signature expirations to be spread out over a period of time. [GL #4554]
Feature Changes
- DNSSEC signatures that are not valid because the current time falls
outside the signature inception and expiration dates are skipped
instead of causing an immediate validation failure. [GL #4586]
https://downloads.isc.org/isc/bind9/9.18.27/doc/arm/html/notes.html#notes-for-bind-9-18-27
Fixes security issues reported in:
https://downloads.isc.org/isc/bind9/9.18.24/doc/arm/html/notes.html#security-fixes
- Validating DNS messages containing a lot of DNSSEC signatures could cause excessive CPU
load, leading to a denial-of-service condition. This has been fixed. (CVE-2023-50387)
ISC would like to thank Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner
from the German National Research Center for Applied Cybersecurity ATHENE for bringing
this vulnerability to our attention. [GL #4424]
Preparing an NSEC3 closest encloser proof could cause excessive CPU load, leading to
a denial-of-service condition. This has been fixed. (CVE-2023-50868) [GL #4459]
Parsing DNS messages with many different names could cause excessive CPU load.
This has been fixed. (CVE-2023-4408)
ISC would like to thank Shoham Danino from Reichman University, Anat Bremler-Barr
from Tel-Aviv University, Yehuda Afek from Tel-Aviv University, and Yuval Shavitt
from Tel-Aviv University for bringing this vulnerability to our attention. [GL #4234]
Specific queries could cause named to crash with an assertion failure when
nxdomain-redirect was enabled. This has been fixed. (CVE-2023-5517) [GL #4281]
A bad interaction between DNS64 and serve-stale could cause named to crash with
an assertion failure, when both of these features were enabled. This has been fixed.
(CVE-2023-5679) [GL #4334]
Under certain circumstances, the DNS-over-TLS client code incorrectly attempted to
process more than one DNS message at a time, which could cause named to crash with
an assertion failure. This has been fixed. [GL #4487]
Increased release to be higher than c9s bind9.18 component.
; Resolves: CVE-2023-4408 CVE-2023-50387 CVE-2023-50868 CVE-2023-5517 CVE-2023-5679
Resolves: RHEL-48798
https://downloads.isc.org/isc/bind9/9.18.21/doc/arm/html/notes.html#notes-for-bind-9-18-21
Removed Features
- Support for using AES as the DNS COOKIE algorithm (cookie-algorithm aes;) has been deprecated and will be removed in a future release. Please use the current default, SipHash-2-4, instead. [GL #4421]
- The resolver-nonbackoff-tries and resolver-retry-interval statements have been deprecated. Using them now causes a warning to be logged. [GL #4405]
named contains high number of assertions checking expected state of the
daemon. That is part of defensive code style to prevent many attacks.
The most common failure is failing some assertion check in rare
circumstances. Even when this should not happen, try keeping the service
running. If such failed assertion produces coredump just from time to
time, avoid failing hard the whole service. coredumpctl will keep track
of all crashes anyway.
