ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-26T21:39:49Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4650dnssec-validation locks up server with 9.19.222024-03-26T21:39:49ZKlemen Mihevcdnssec-validation locks up server with 9.19.22Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [x] Search the existing issues in GitLab (both open and closed) to see if your report m...Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [x] Search the existing issues in GitLab (both open and closed) to see if your report might be a duplicate. We have a large database here and many issues have already been fixed in the latest versions!
- [x] Make sure this is **not** a support question. If you have specific trouble configuring or debugging your setup, please use the bind-users mailing list: https://lists.isc.org/mailman/listinfo/bind-users
- [x] You have read and understood the "out in the open" support policy: https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ . Even though it was written by the PowerDNS folks, we follow it as well!
Before continuing, **please select the appropriate issue template in the drop-down menu above, under the heading _Description_**.
i tried to use dnssec-validation (auto) with 9.19.22 and it makes server unresponsive. This didnt happen in 9.19.21. What happens is usually in first half an hour server starts to become unresponsive(LITTERALLY STUCK, need to kill -9) and cpu load rockets sky high without a reason (most i saw was 45% before i killed process manualy). This is not some high usage dns server, it serves for home domain and recursion on home network. There is nothing in the logs even with debug severity... Hopefully you can give me guidance how to help you resolve this issuehttps://gitlab.isc.org/isc-projects/kea/-/issues/3300Database connection retry/delay causes infinite loop2024-03-22T14:22:46ZMarcin GodzinaDatabase connection retry/delay causes infinite loopThis MR that started it: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2238
db_retry_legallog and db_retry_reservation system tests are failing - Kea goes into an indefinite loop trying to reconnect to the database without de...This MR that started it: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2238
db_retry_legallog and db_retry_reservation system tests are failing - Kea goes into an indefinite loop trying to reconnect to the database without delay
(Failing Tests on Jenkins https://jenkins.aws.isc.org/job/kea-dev/job/tarball-system-tests/1168/)
A problem appears when retrying the connection to reservation or legallog db. At first glance, the lease db connection is unaffected.
Config to reproduce (of course, change paths. You do not have to change the DB setting - there should be no DB running to connect to)
[kea-dhcp4.conf](/uploads/72df474f98af62208baeeb6b618a4c54/kea-dhcp4.conf)
Part of the Log from the test
[kea__1_.log](/uploads/f4297c0cf1520f4cee7f6b9f6da0a0d3/kea__1_.log)kea2.5.7Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4649All TSAN-enabled builds fail in AWS-based GitLab CI jobs2024-03-25T13:45:40ZMichał KępieńAll TSAN-enabled builds fail in AWS-based GitLab CI jobs[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSa...[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSanitizer: unexpected memory mapping 0x7d00e0772000-0x7d00e0c00000
While it is not clear what exactly happened, here are two jobs that were
run in CI for the same commit:
- [2024-03-20 14:24, passed][2]
- [2024-03-20 16:41, failed][3]
The refreshed TSAN image was pushed to the container registry at 15:13.
The TSAN builds seemingly still work fine with the refreshed TSAN image
on our bare metal runners, which use older kernels. This is consistent
with similar reports found online:
https://stackoverflow.com/questions/77850769/fatal-threadsanitizer-unexpected-memory-mapping-when-running-on-linux-kernels
The simplest course of action is to apply the workaround mentioned in
the StackOverflow post above (`sysctl vm.mmap_rnd_bits=28`) and remove
it once the issue resolves itself as kernels and packages get updated
over time.
[1]: https://gitlab.isc.org/isc-projects/images/-/pipelines/168133
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4142725
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143237April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4648pytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.py2024-03-21T12:09:20ZMark Andrewspytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.pyJob [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in...Job [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in _call_runtest_hook
INTERNALERROR> reraise = (runner.Exit,)
INTERNALERROR> AttributeError: module '_pytest.runner' has no attribute 'Exit'
INTERNALERROR> Traceback (most recent call last):
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4646CID 488065: Null pointer dereferences (REVERSE_INULL)2024-03-19T22:41:36ZMichal NowakCID 488065: Null pointer dereferences (REVERSE_INULL)Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROT...Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROTTL);
4802 }
4803 atomic_init(&newheader->count,
4804 atomic_fetch_add_relaxed(&init_count, 1));
>>> CID 488065: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
4805 if (version != NULL) {
4806 newheader->serial = version->serial;
4807
4808 if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
4809 DNS_SLABHEADER_SETATTR(newheader,
4810 DNS_SLABHEADERATTR_RESIGN);
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4645CID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", ...2024-03-19T22:41:36ZMichal NowakCID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences itCoverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 ...Coverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 changed->dirty = true;
1993 }
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1994 maybe_update_recordsandsize(false, version, header,
1995 nodename->length);
1996 }
1997 } else {
1998 /*
1999 * No non-IGNORED rdatasets of the given type exist at
/lib/dns/qpzone.c: 1972 in add()
1966 if (topheader_prev != NULL) {
1967 topheader_prev->next = newheader;
1968 } else {
1969 node->data = newheader;
1970 }
1971 newheader->next = topheader->next;
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1972 maybe_update_recordsandsize(false, version, header,
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
/lib/dns/qpzone.c: 1979 in add()
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
1978 resigninsert(qpdb, idx, newheader);
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "resigndelete", which dereferences it.
1979 resigndelete(qpdb, version,
1980 header DNS__DB_FLARG_PASS);
1981 }
1982 if (topheader_prev != NULL) {
1983 topheader_prev->next = newheader;
1984 } else {
/lib/dns/qpzone.c: 2061 in add()
2055 newheader->next = node->data;
2056 node->data = newheader;
2057 }
2058 }
2059 }
2060
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
2061 maybe_update_recordsandsize(true, version, newheader, nodename->length);
2062
2063 /*
2064 * Check if the node now contains CNAME and other data.
2065 */
2066 if (version != NULL && cname_and_other(node, version->serial)) {
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4644Make BIND 9.16.48 got warnings and got errors whtn configure with --enable-de...2024-03-18T03:31:51Znanwn147929@alibaba-inc.comMake BIND 9.16.48 got warnings and got errors whtn configure with --enable-developer<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
Compilation got error when configure with developer mode enabled.
### BIND version affected
BIND 9.16.48
### Steps to reproduce
1. Configure by default options `./configure`, and compile source code `make`
2. Configure by enable tests `./configure --with-cmocka --enable-developer`, and compile source code `make; make test`
### What is the current *bug* behavior?
1. Compilation by default configuration
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
gcc -std=gnu99 -include /home/wn147929/bind/bind-9.16.48/config.h -I/home/wn147929/bind/bind-9.16.48 -I../.. -I./unix/include -I./pthreads/include -I./include -I./include -I. -I/home/wn147929/bind/bind-9.16.48/lib/dns/include -I../../lib/dns/include -DOPENSSL_SUPPRESS_DEPRECATED -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c base64.c
In file included from ./include/isc/assertions.h:21:0,
from ./include/isc/list.h:16,
from ./include/isc/types.h:32,
from ./include/isc/base64.h:20,
from base64.c:18:
base64.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
```
2. Compilation with developer mode enabled
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
cc1: all warnings being treated as errors
```
### What is the expected *correct* behavior?
Compile success
### Relevant configuration files
<!-- Paste any relevant configuration files here - 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
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/63client-classes should allow definition of a class with no test line.2024-03-17T14:28:06ZDarren Ankneyclient-classes should allow definition of a class with no test line.See: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4
In global client-classes as you should be able to define an client class that doesn't have a test. Then select them in the reservation. ...See: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4
In global client-classes as you should be able to define an client class that doesn't have a test. Then select them in the reservation. Should still allow selection of client-classes that have a test inside the reservation as well, so no need to change anything inside reservations mechanism.
Won't need patch notes as is an oversight contained to the 0.3 version.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/62Disable output of "client-classes" in global if no classes defined2024-03-17T13:37:16ZDarren AnkneyDisable output of "client-classes" in global if no classes definedThis is placed in the configuration:
```
"client-classes": [],
```
in the global area when there are no classes defined. Stop that. It doesn't cause any problems, but it doesn't need to be there.This is placed in the configuration:
```
"client-classes": [],
```
in the global area when there are no classes defined. Stop that. It doesn't cause any problems, but it doesn't need to be there.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4642[dig] +ednsflags do not enable EDNS2024-03-17T03:16:43ZStéphane Bortzmeyer[dig] +ednsflags do not enable EDNS### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by mak...### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by make with default
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with liburcu version: 0.13.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
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): no
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
```
### Steps to reproduce
```
dig +noedns +ednsflags=0x4000 isc.org SOA
``
### What is the current *bug* behavior?
EDNS is still disabled
### What is the expected *correct* behavior?
+ednsflags should enable EDNS, like +nsid or +dnssec do. (Or may be only if the value is not-zero.)
/label ~Bughttps://gitlab.isc.org/isc-projects/bind9/-/issues/4641dig +ednsflags does not re-enable EDNS2024-03-17T03:12:44ZMark Andrewsdig +ednsflags does not re-enable EDNS+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the same+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the sameApril 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4640Checkzone in system test leaks queries2024-03-21T02:40:22ZMark AndrewsCheckzone in system test leaks queriesThe checkzone "checking with max ttl (text)" test leaks queries.The checkzone "checking with max ttl (text)" test leaks queries.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4639Add OpenSSL Flags to proxystream_test2024-03-14T23:42:27ZSamuel ChiangAdd OpenSSL Flags to proxystream_testproxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch pr...proxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch provided below :smile:
```
diff --git a/tests/isc/Makefile.am b/tests/isc/Makefile.am
index 5cdd915..6ee1935 100644
--- a/tests/isc/Makefile.am
+++ b/tests/isc/Makefile.am
@@ -115,10 +115,12 @@ proxyheader_test_SOURCES = \
proxyheader_test_data.h
proxystream_test_CPPFLAGS = \
- $(AM_CPPFLAGS)
+ $(AM_CPPFLAGS) \
+ $(OPENSSL_CFLAGS)
proxystream_test_LDADD = \
- $(LDADD)
+ $(LDADD) \
+ $(OPENSSL_LIBS)
proxystream_test_SOURCES = \
proxystream_test.c \
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4637host, dig and nslookup don't resolve IDN domains when not used in a tty2024-03-16T06:49:38ZDirk Stöckerhost, dig and nslookup don't resolve IDN domains when not used in a tty### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve t...### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve the domain.
See also my initial bug report to perl (https://github.com/Perl/perl5/issues/22080) which points to the exact code location for this bug.
### BIND version affected
I'm using bind-utils-9.18.24-1.1.x86_64 on openSUSE Tumbleweed. Same happens on older version (Ubuntu LTS).
### Steps to reproduce
See description above
1. Call `host stöcker.eu |cat` in Linux shell
### What is the current *bug* behavior?
Does not resolve a correct name
### What is the expected *correct* behavior?
Does resolve the name whether it's a tty or not.
### Relevant configuration files
none
### Relevant logs
noneNot plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/3292kea 2.4.x: make install fails with python 3.122024-03-21T14:57:02ZNatanael Copakea 2.4.x: make install fails with python 3.12kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bi...kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
/usr/bin/install -c kea-shell '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/usr/bin/install -c -m 644 kea_conn.py kea_connector3.py '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
Traceback (most recent call last):
File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'imp'
make[5]: *** [Makefile:528: install-pkgpythonPYTHON] Error 1
make[5]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[4]: *** [Makefile:740: install-am] Error 2
make[4]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[3]: *** [Makefile:577: install-recursive] Error 1
make[3]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[2]: *** [Makefile:464: install-recursive] Error 1
make[2]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin'
make[1]: *** [Makefile:462: install-recursive] Error 1
make[1]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src'
make: *** [Makefile:649: install-recursive] Error 1
```
From https://docs.python.org/3/whatsnew/3.12.html
> The asynchat, asyncore, and imp modules have been removed, along with several unittest.TestCase method aliases.https://gitlab.isc.org/isc-projects/kea/-/issues/3291stat-lease4-get does not return leases statistics correctly2024-03-15T10:00:43ZJohn Papstat-lease4-get does not return leases statistics correctly**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server'...**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server's CLI using curl. Although there are active leases for clients the Web UI displays 0 for assigned IPs on all subnets. Probably a bug in the stat-lease4-get API command.
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea server 2.0.2, Stork 1.15.0 and run them with the following configs: '...'
2. Configure several subnets.
2. Have 3 VMs act as clients on all subnets and get ip addresses from kea server
3. Clients get IP address but the Stork GUI shows 0 for all lease statistics.
**Expected behavior**
Stork GUI should display the leases statistics for the connected clients.
**Environment:**
- Kea version: 2.0.2
- Stork: 1.15.0
- OS: Ubuntu 22.04 x64
- Kea: Hooks libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Additional Information**
Querying the DHCP agent from the stork server using the cli and the management API I figured out that the stat-lease4-get command without arguments returns different results for the same subnet than the stat-lease4-get command having the subnet-id as an argument.
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"]}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 47, 56, 0, 0, 0 ], [ 51, 56, 0, 0, 0 ], [ 66, 41, 0, 0, 0 ] ], "timestamp": "2024-03-08 14:09:09.100431" } }, "result": 0, "text": "stat-lease4-get[all subnets]: 3 rows found" } ]
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"], "arguments": {"subnet-id" : 66}}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 66, 41, 0, 3, 0 ] ], "timestamp": "2024-03-08 14:09:17.884123" } }, "result": 0, "text": "stat-lease4-get[subnet-id=66]: 1 rows found" } ]
The second output above has the correct leases stats for subnet-id 66 while the first output shows 0 leases for subnet-id 66https://gitlab.isc.org/isc-projects/bind9/-/issues/4633Undefined behaviour in rdataslab.c2024-03-21T12:20:05ZMark AndrewsUndefined behaviour in rdataslab.cmemmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.memmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4632Intermittent hang in dns__db_findnode() during RPZ-enabled "stress" test2024-03-27T08:46:57ZMichał KępieńIntermittent hang in dns__db_findnode() during RPZ-enabled "stress" test`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation ...`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation differs):
https://gitlab.isc.org/isc-projects/bind9/-/jobs/4114341
Artifacts were retained for the failed job.
```
2024-03-12:09:46:32 ERROR: Core dump file /builds/isc-private/bind9/output/ns4/core.24295 found
Core was generated by `/builds/isc-private/bind9/.local/usr/local/sbin/named -f -c ./named.conf'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
225 if (read_indicator_isempty(rwl)) {
[Current thread is 1 (Thread 0x7ff91fc75600 (LWP 24295))]
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
#1 0x00007ff920ee4355 in isc_rwlock_wrlock (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:246
#2 0x00007ff920cdf797 in findnode (db=0x7ff91f859500, name=0x7ff91edf0400, create=<optimized out>, nodep=0x7fffc0aa4f58) at qpcache.c:2901
#3 0x00007ff920c4e924 in dns__db_findnode (db=<optimized out>, name=name@entry=0x7ff91edf0400, create=create@entry=true, nodep=nodep@entry=0x7fffc0aa4f58) at db.c:439
#4 0x00007ff920d41d31 in cache_name (fctx=fctx@entry=0x7ff8fa5eec00, name=0x7ff91edf0400, message=message@entry=0x7ff8f9f13c80, addrinfo=addrinfo@entry=0x7ff8f9f067f0, now=now@entry=1710232927) at resolver.c:5803
#5 0x00007ff920d4283d in cache_message (fctx=fctx@entry=0x7ff8fa5eec00, message=0x7ff8f9f13c80, addrinfo=0x7ff8f9f067f0, now=1710232927) at resolver.c:6223
#6 0x00007ff920d4caa2 in resquery_response (eresult=<optimized out>, region=0x7fffc0aa5470, arg=0x7ff8fa2c1000) at resolver.c:7625
#7 0x00007ff920c55e6f in udp_recv (handle=0x7ff8f9d30000, eresult=<optimized out>, region=0x7fffc0aa5470, arg=<optimized out>) at dispatch.c:619
#8 0x00007ff920ea6349 in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1856
#9 0x00007ff920ea641b in isc__nm_readcb (sock=sock@entry=0x7ff8fa58e500, uvreq=uvreq@entry=0x7ff8fa539200, eresult=eresult@entry=ISC_R_SUCCESS, async=async@entry=false) at netmgr/netmgr.c:1871
#10 0x00007ff920eb7b40 in isc__nm_udp_read_cb (handle=<optimized out>, nrecv=244, buf=0x7fffc0aa5540, addr=0x7fffc0aa5590, flags=0) at netmgr/udp.c:589
#11 0x00007ff9205bb72a in uv__udp_recvmsg (handle=0x7ff8fa58e7c0) at /usr/src/libuv-v1.48.0/src/unix/udp.c:267
#12 0x00007ff9205bb022 in uv__udp_io (loop=0x7ff91f837020, w=0x7ff8fa58e840, revents=1) at /usr/src/libuv-v1.48.0/src/unix/udp.c:142
#13 0x00007ff9205c0e70 in uv__io_poll (loop=0x7ff91f837020, timeout=612) at /usr/src/libuv-v1.48.0/src/unix/linux.c:1528
#14 0x00007ff9205a5fa4 in uv_run (loop=0x7ff91f837020, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.48.0/src/unix/core.c:448
#15 0x00007ff920ecc52d in loop_thread (arg=arg@entry=0x7ff91f837000) at loop.c:284
#16 0x00007ff920edd775 in thread_body (wrap=0x7ff91f8d8380) at thread.c:85
#17 0x00007ff920edd7ef in isc_thread_main (func=func@entry=0x7ff920ecc4a2 <loop_thread>, arg=0x7ff91f837000) at thread.c:116
#18 0x00007ff920ecd204 in isc_loopmgr_run (loopmgr=0x7ff91f80ea80) at loop.c:456
#19 0x0000000000425250 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1574
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4631CID 487884: Dead code in lib/dns/qpcache.c2024-03-14T11:50:20ZMichal NowakCID 487884: Dead code in lib/dns/qpcache.cCoverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->...Coverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->next = newheader;
3457 qpnode->dirty = 1;
3458 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3459 changed->dirty = true;
3460 }
3461 } else {
3462 /*
3463 * No rdatasets of the given type exist at the node.
3464 */
```
```c
/lib/dns/qpcache.c: 3409 in add()
3403 }
3404 newheader->next = topheader->next;
3405 newheader->down = topheader;
3406 topheader->next = newheader;
3407 qpnode->dirty = 1;
3408 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3409 changed->dirty = true;
3410 }
3411 mark_ancient(header);
3412 if (sigheader != NULL) {
3413 mark_ancient(sigheader);
3414 }
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4630CID 487883: Null pointer dereference in lib/dns/qpzone.c2024-03-14T00:31:50ZMichal NowakCID 487883: Null pointer dereference in lib/dns/qpzone.cCoverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferre...Coverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferred until closeversion() is called.
4933 */
4934 if (result == ISC_R_SUCCESS && version == NULL) {
>>> CID 487883: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "version" to "setsecure", which dereferences it.
4935 setsecure(db, version, qpdb->origin);
4936 }
4937
4938 return (result);
4939 }
4940
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)