Running with BIND 9.18.18 and libuv 1.44.1 giving error that "libuv version is to new".
Summary
We have compiled the latest BIND 9.18.18 with libuv 1.44.1. The compilation was successfully done. At the runtime, we encounter the error "libuv version too new: running with libuv 1.44.1 when compiled with libuv 1.44.1 will lead to libuv failures".
As per the below link, a maximal libuv version check is introduced in lib/isc/netmgr/netmgr.c
file which says that the libuv version should not be greater than 1.34.99
!7480 (687a9e93)
As per the BIND release notes in section 11.10.2, second bullet point, Running with libuv higher than 1.34.2 is now a fatal error when named is built against libuv 1.34.2.
But in our case, the libuv version compiled version is 1.44.1 and runtime version is also same. Still as per the current code in netmgr.c file, we are getting the error that libuv version is too new.
BIND version used
BIND 9.18.18 (Extended Support Version) <id:1f8de2f>
running on Linux x86_64 4.18.0-372.64.1.el8_6.x86_64 #1 SMP Thu Jun 29 14:42:09 EDT 2023
built by make with '--prefix=/opt/af' '--sysconfdir=/etc/opt/af' '--with-openssl=no' '--disable-doh' 'PKG_CONFIG_PATH=/proj/vau/dev/bind/libuv/1.44.1/linux/libuv-v1.44.1:/proj/vau/dev/bind/jemalloc/5.3.0/linux/jemalloc-5.3.0/'
compiled by GCC 8.5.0 20210514 (Red Hat 8.5.0-16)
compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/opt/af/named.conf
rndc configuration: /etc/opt/af/rndc.conf
DNSSEC root key: /etc/opt/af/bind.keys
nsupdate session key: /opt/af/var/run/named/session.key
named PID file: /opt/af/var/run/named/named.pid
named lock file: /opt/af/var/run/named/named.lock
Steps to reproduce
- Compile the BIND 9.18.18 with libuv 1.44.1
- There are no errors in compilation.
- On runtime, the errors comes on the console that "libuv version too new: running with libuv 1.44.1 when compiled with libuv 1.44.1 will lead to libuv failures".
What is the current bug behavior?
The BIND does not able to start due to this strict validation check of libuv version of 1.34.99 in netmgr.c file at the runtime.
What is the expected correct behavior?
As per the recommendation from BIND, we should not use libuv 1.35 and 1.36 version. But even after using libuv 1.44.1, this check prevents the bind to start at runtime giving the error that libuv version is too new.
Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
named-checkconf -px
.)
Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code, as it's very hard to read otherwise.)
Possible fixes
The maximal libuv version check introduced in “lib/isc/netmgr/netmgr.c” file should be tweaked such that it should not fail at runtime when BIND is compiled with libuv version greater than 1.44.