ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-11-23T15:00:13Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3164RFC3442 support case when client requests the Classless Static Routes option ...2023-11-23T15:00:13ZPiotrek ZadrogaRFC3442 support case when client requests the Classless Static Routes option and also requests either or both of the Router option and the Static Routes optionAs per RFC3442:
```
DHCP Server Administrator Responsibilities
Many clients may not implement the Classless Static Routes option.
DHCP server administrators should therefore configure their DHCP
servers to send both a Router o...As per RFC3442:
```
DHCP Server Administrator Responsibilities
Many clients may not implement the Classless Static Routes option.
DHCP server administrators should therefore configure their DHCP
servers to send both a Router option and a Classless Static Routes
option, and should specify the default router(s) both in the Router
option and in the Classless Static Routes option.
When a DHCP client requests the Classless Static Routes option and
also requests either or both of the Router option and the Static
Routes option, and the DHCP server is sending Classless Static Routes
options to that client, the server SHOULD NOT include the Router or
Static Routes options.
```
This should be discussed if Kea should follow this once support of Classless Static Routes is implemented.
Source: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2135#note_414489backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4446deprecate --enable-fixed-rrset / rrset-order fixed2024-03-07T19:20:29ZPetr Špačekpspacek@isc.orgdeprecate --enable-fixed-rrset / rrset-order fixed### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I th...### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I think it will get in our way when we fix #3405.
### Proposal
Deprecate deprecate `configure --enable-fixed-rrset` / `rrset-order fixed` statement in 9.20, remove in 9.21.
### Links / referencesBIND 9.19.xhttps://gitlab.isc.org/isc-projects/kea/-/issues/3163unstable unit tests2024-03-20T11:23:33ZAndrei Pavelandrei@isc.orgunstable unit testsThe following tests failed irregularly in the past fortnight:
* `AllocEngine6Test.reservedAddressInPoolReassignedOther` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/AllocEngine6Test/all___debian_1...The following tests failed irregularly in the past fortnight:
* `AllocEngine6Test.reservedAddressInPoolReassignedOther` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/AllocEngine6Test/all___debian_11_amd64___debian_11_amd64_results___reservedAddressInPoolReassignedOther/
```
test_utils.cc:88
Expected equality of these values:
first->cltt_
Which is: 1700075018
second->cltt_
Which is: 1700075019
```
* `HttpClientTest.unreachable` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1273/testReport/junit/(root)/HttpClientTest/all___alpine_3_16_amd64___alpine_3_16_amd64_results___unreachable/
```
server_client_unittests.cc:437
Failed
Timeout occurred while running the test!
```
* `MemfileLeaseQueryImpl6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1274/testReport/junit/(root)/MemfileLeaseQueryImpl6ProcessTest/all___debian_12_amd64___debian_12_amd64_results___queryByClientIdActiveLeases/
```
lease_query_impl6_unittest.cc:1783
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `MySQLBulkLeaseQuery6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1280/testReport/junit/(root)/MySQLBulkLeaseQuery6ProcessTest/all___freebsd_13_0_amd64___freebsd_13_0_amd64_results___queryByClientIdActiveLeases/
```
bulk_lease_query6_unittest.cc:458
Expected equality of these values:
lease->valid_lft_ - elapsed
Which is: 3500
iaaddr_opt->getValid()
Which is: 3499
```
* `MySQLLeaseQueryImpl6ProcessTest.makeClientOptionSingleLink` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1265/testReport/junit/(root)/PgSQLLeaseQueryImpl6ProcessTest/all___alpine_3_15_amd64___alpine_3_15_amd64_results___makeClientOptionSingleLink/
```
lease_query_impl6_unittest.cc:880
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `MySQLLeaseQueryImpl6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/MySQLLeaseQueryImpl6ProcessTest/all___debian_10_amd64___debian_10_amd64_results___queryByClientIdActiveLeases/
```
lease_query_impl6_unittest.cc:1783
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `MySQLLeaseQueryImpl6ProcessTest.queryByIpAddressActiveLease` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/MySQLLeaseQueryImpl6ProcessTest/all___ubuntu_20_04_amd64___ubuntu_20_04_amd64_results___queryByIpAddressActiveLease/
```
lease_query_impl6_unittest.cc:1581
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `PgSQLBulkLeaseQuery6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1275/testReport/junit/(root)/PgSQLBulkLeaseQuery6ProcessTest/all___fedora_38_amd64___fedora_38_amd64_results___queryByClientIdActiveLeases/
```
bulk_lease_query6_unittest.cc:458
Expected equality of these values:
lease->valid_lft_ - elapsed
Which is: 3500
iaaddr_opt->getValid()
Which is: 3499
```
* `PgSQLLeaseQueryImpl6ProcessTest.makeClientOptionSingleLink` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/PgSQLLeaseQueryImpl6ProcessTest/all___fedora_38_amd64___fedora_38_amd64_results___makeClientOptionSingleLink/
```
lease_query_impl6_unittest.cc:880
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `PgSQLLeaseQueryImpl6ProcessTest.queryByIpAddressActiveLease` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1270/testReport/junit/(root)/PgSQLLeaseQueryImpl6ProcessTest/all___rhel_9_amd64___rhel_9_amd64_results___queryByIpAddressActiveLease/
```
lease_query_impl6_unittest.cc:1581
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3162Kea does not look at all IP addresses on an interface when attempting to matc...2023-11-23T14:57:47Zmpratik-aristaKea does not look at all IP addresses on an interface when attempting to match incoming packet with subnetSay that Kea has started a DHCPv4 server instance and the interface (on which Kea is listening) has multiple IP addresses configured on it (say using `sudo ip addr add ADDR/MASK dev IFACE`). Now if Kea receives a packet from a directly c...Say that Kea has started a DHCPv4 server instance and the interface (on which Kea is listening) has multiple IP addresses configured on it (say using `sudo ip addr add ADDR/MASK dev IFACE`). Now if Kea receives a packet from a directly connected client on the interface, the Kea code appears to fetch the first available address on the interface, specifically the code here -> https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/lib/dhcp/iface_mgr.cc#L225. This IP address is then used during subnet selection.
In the example (which is also our setup) below, the interface on which kea is listening is vlan42. The primary IP address configured on the interface is 152.44.134.1/16 (configured earlier) and the secondary IP Address configured on the interface is 169.254.4.3/16 (configured later). I see the following traces ->
```
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.dhcpsrv/23369.139809668667520] DHCPSRV_PRINT_ATTR Attribute: iface.address = 152.44.134.1 (I added this log where I printed the IP address that Kea selected for subnet matching)
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.packets/23369.139809668667520] DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 56:83:3f:7a:76:07], cid=[no info], tid=0xb02e9d17: failed to select subnet for the client
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.bad-packets/23369.139809668667520] DHCP4_PACKET_DROP_0002 [hwtype=1 56:83:3f:7a:76:07], cid=[no info], tid=0xb02e9d17, from interface vlan42: no suitable subnet configured for a direct client
```
I verified that Kea successfully adds both the primary and secondary IP address in the Netlink::ipaddrs_get function for vlan42. My expectation was that Kea would look at all the IP addresses active on the interface and then check if any subnet configured in the Kea config file matches these IPs
The Kea config only had a subnet associated with the secondary IP 169.254.4.3/16 so understandably the packet could not be matched to any subnet. We want to be able to provide addresses from the subnet 169.254.0.0 to the clients who are sending their Discover packets on vlan42.
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with the attached config and configure an interface with two IP addresses so that Kea is listening on this interface using both these IPs.
2. Let a directly connected client does A send a Discover packet to the interface that Kea listens on
3. The server will not be able to provide an IP back to the client as it will not match a subnet.
4. This same behavior is seen regardless of whether I add the following block of code.
```
"interfaces-config": {
"interfaces": [
"vlan42/169.254.4.3"
]
}
```
Expected behavior:
The client would have obtained IP address 169.254.5.5 (first available IP from the subnet 169.254.0.0/16 as specified in the Kea config file) since the IP address is getting added to the interface's address list.
We used Kea-2.0.0 for this experiment[kea-dhcp4-default.conf.rtf](/uploads/b771e974c2c29aa7357bbc6e4e9de553/kea-dhcp4-default.conf.rtf)next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4444TCP fallback does not happen on bind 9.18.112023-12-19T09:16:56ZShota HinoTCP fallback does not happen on bind 9.18.11
### Summary
After upgrading bind9 from v9.18.10 to v9.18.11, we found that TCP fallback no longer happens. The previous behavior on bind v9.18.10 was that after UDP queries time out, named falls back to TCP. We identified that this ch...
### Summary
After upgrading bind9 from v9.18.10 to v9.18.11, we found that TCP fallback no longer happens. The previous behavior on bind v9.18.10 was that after UDP queries time out, named falls back to TCP. We identified that this change in behavior was introduced by this change https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7212.
### BIND version used
v9.18.11
### Steps to reproduce
1. Block UDP queries.
2. Observe that named does not fall back to TCP
### What is the current *bug* behavior?
TCP fallback does not happen after UDP queries time out.
### What is the expected *correct* behavior?
After UDP timeout, named falls back to use TCP.
### Relevant configuration files
```
options {
listen-on { 192.168.4.1; 127.0.0.1; }; # see warning above before changing
version "not currently available";
forwarders {
75.75.75.75;
75.75.76.76;
8.8.8.8;
8.8.4.4;
208.67.222.222;
208.67.220.220;
};
querylog yes;
# Cache and forward
recursion yes;
forward only;
# Enable dnssec
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
max-cache-size 2m;
max-cache-ttl 3600;
# Default path is at the root directory, which is not writable by bind.
dump-file "/run/named/named_dump.db";
};
```
### Relevant logs and/or screenshots
This is the packet capture from the working version - v9.18.10. You can see that TCP fallback happens.
![Screenshot_from_2023-11-21_12-19-39](/uploads/9b85a9cac9e0b2900ac60c3baa619668/Screenshot_from_2023-11-21_12-19-39.png)
### Possible fixes
I have not fully traced the code, but TCP fallback might have been happening via the code here? https://gitlab.isc.org/isc-projects/bind9/-/blob/bind-9.18/lib/dns/resolver.c?ref_type=heads#L2600-2625.
With the said commit https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7249/diffs?commit_id=095f634f48d621da1e26e5ada5026b5427e0a0bb#23711d1cafba45a6f9e0b84f76c786435421f0e8_2631_2631, this may not happen if the retry counter never gets incremented. I could be wrong on this analysis because I did not carefully trace the code, so please take this with a grain of salt.BIND 9.21.xhttps://gitlab.isc.org/isc-projects/stork/-/issues/1227Put hook binaries outside /var by default2024-02-02T12:57:44ZSlawek FigielPut hook binaries outside /var by defaultThe problem was reported [on our mailing list](https://lists.isc.org/pipermail/stork-users/2023-November/000231.html).
The default hook directories are `/var/lib/stork-agent/hooks` and `/var/lib/stork-server/hooks`.
But the various Linu...The problem was reported [on our mailing list](https://lists.isc.org/pipermail/stork-users/2023-November/000231.html).
The default hook directories are `/var/lib/stork-agent/hooks` and `/var/lib/stork-server/hooks`.
But the various Linux distros in the `enforcing` mode disallow the libraries from the `/var` directory.
It causes the Stork hooks not to be loaded, producing the message: `failed to map segment from shared object`.1.16https://gitlab.isc.org/isc-projects/stork/-/issues/1226Add missing configuration change events2023-11-21T14:52:07ZMarcin SiodelskiAdd missing configuration change eventsWe have added many new configuration features for host and subnet management but we didn't add any events indicating the configuration changes. With this ticket we should focus on identifying these gaps and addressing them. For example, ...We have added many new configuration features for host and subnet management but we didn't add any events indicating the configuration changes. With this ticket we should focus on identifying these gaps and addressing them. For example, we should have events saying: "Subnet 192.0.2.0/24 configuration has been updated by Marcin in servers foo and bar."backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3160Too many nullable fields in DB schema?2023-11-23T14:48:53ZDavid KraeutmannToo many nullable fields in DB schema?I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but onl...I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but only relay_id and remote_id are actually possibly set to NULL in the Kea code.
What is the design decision behind that?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3159ThreadSanitize: SEGSV complain on dhcp4 UT when postgresql isn't running2023-11-23T14:46:57ZThomas MarkwalderThreadSanitize: SEGSV complain on dhcp4 UT when postgresql isn't runningThis ism ore of an inconvenience than anything else but it might be a sign of something else too. When postgresql is compiled in but server is not running, kea-dhcp4 builtin for TSAN, UT throws the following error:
```
[----------] 2 t...This ism ore of an inconvenience than anything else but it might be a sign of something else too. When postgresql is compiled in but server is not running, kea-dhcp4 builtin for TSAN, UT throws the following error:
```
[----------] 2 tests from DORAPgSQLTest
[ RUN ] DORAPgSQLTest.multiStageBoot
wipePgSQLData failed:[export PGPASSWORD=keatest; sh /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/wipe_data.sh 19.0 --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null ]
runPgSQLSchema failed: export PGPASSWORD=keatest; cat < /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/dhcpdb_drop.pgsql | psql --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null
unknown file: Failure
C++ exception with description "runPgSQLSchema failed: export PGPASSWORD=keatest; cat < /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/dhcpdb_drop.pgsql | psql --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null " thrown in the test fixture's constructor.
ThreadSanitizer:DEADLYSIGNAL
==71954==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55d4686f55bf bp 0x000000000000 sp 0x7ffd8d3170e0 T71954)
==71954==The signal is caused by a READ memory access.
==71954==Hint: address points to the zero page.
#0 testing::Test::DeleteSelf_() /opt/googletest-release-1.8.0/googletest/include/gtest/gtest.h:453 (dhcp4_unittests+0x7735bf)
#1 void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2402 (dhcp4_unittests+0x781869)
#2 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2438 (dhcp4_unittests+0x781869)
#3 testing::TestInfo::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2661 (dhcp4_unittests+0x76f514)
#4 testing::TestCase::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2774 (dhcp4_unittests+0x76f871)
#5 testing::internal::UnitTestImpl::RunAllTests() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:4649 (dhcp4_unittests+0x76ff25)
#6 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2402 (dhcp4_unittests+0x781fa9)
#7 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2438 (dhcp4_unittests+0x781fa9)
#8 testing::UnitTest::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:4257 (dhcp4_unittests+0x7704a5)
#9 RUN_ALL_TESTS() /opt/googletest-release-1.8.0/googletest/include/gtest/gtest.h:2233 (dhcp4_unittests+0x18f59b)
#10 main /home/tmark/labs/build/keadev/open/git.3084/kea/src/bin/dhcp4/tests/dhcp4_unittests.cc:23 (dhcp4_unittests+0x18f59b)
#11 __libc_start_main ../csu/libc-start.c:308 (libc.so.6+0x24082)
#12 _start <null> (dhcp4_unittests+0x1c66dd)
```
Of course if postgresql is running it's not an issue.next-stable-2.6https://gitlab.isc.org/isc-projects/stork/-/issues/1224e2e tests: remove protractor, decide next steps2024-02-02T12:56:44ZTomek Mrugalskie2e tests: remove protractor, decide next stepsWhen Stork's angular project was created a long time ago (in 2020), it added the default end-2-end tests with protractor. AFAICT this was never used. The protractor tool has reached [EOL in Aug 2023](https://www.protractortest.org/#/). W...When Stork's angular project was created a long time ago (in 2020), it added the default end-2-end tests with protractor. AFAICT this was never used. The protractor tool has reached [EOL in Aug 2023](https://www.protractortest.org/#/). We should clean up this outdated mess and...
- [x] get rid of Protractor (and likely all of the default files in `webui/e2e`)
- [ ] decide if we want to develop end 2 end tests
- [ ] if the answer is yes, evaluate [alternatives](https://www.browserstack.com/guide/protractor-alternatives)
- [ ] add a few e2e tests using new testing framework
As for now, the five leading alternatives seem to be Nightwatch.js (11.5k), Cypress (45.2k), Playwright (56.6k), TestCafe (9.7k), WebDriverIO (8.4k). The number in brackets show number of stars on github, which is some indicator of popularity. Other aspects to consider: some frameworks use Selenium (which @wlodek had bad experiences with). Playwright is developed by Microsoft, which might be a factor. The link above contains example test cases.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3151Reject RADIUS config with multiple default NAS ports2023-11-23T14:42:38ZAndrei Pavelandrei@isc.orgReject RADIUS config with multiple default NAS portsA default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accor...A default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accordingly.next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4434dispatch unit test is unstable2024-03-28T14:42:25ZMichal Nowakdispatch unit test is unstableEven after #4392, we keep seeing failures of the `dispatch` unit test.
`dispatch_getnext`:
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_415175
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_416028
`dis...Even after #4392, we keep seeing failures of the `dispatch` unit test.
`dispatch_getnext`:
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_415175
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_416028
`dispatch_newtcp`: Job [#3799293](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3799293) failed for 25cfec4d2b7b2d33c041a8543ab7f21191e6241c.
```
[==========] Running 10 test(s).
[ RUN ] dispatch_gettcp
[ OK ] dispatch_gettcp
[ RUN ] dispatch_newtcp
[ OK ] dispatch_newtcp
[ RUN ] dispatch_timeout_udp_response
[ OK ] dispatch_timeout_udp_response
[ RUN ] dispatchset_create
[ OK ] dispatchset_create
[ RUN ] dispatchset_get
[ OK ] dispatchset_get
[ RUN ] dispatch_timeout_tcp_response
[ OK ] dispatch_timeout_tcp_response
[ RUN ] dispatch_timeout_tcp_connect
[ OK ] dispatch_timeout_tcp_connect
[ RUN ] dispatch_tcp_response
[ OK ] dispatch_tcp_response
[ RUN ] dispatch_tls_response
[ OK ] dispatch_tls_response
[ RUN ] dispatch_getnext
0x2 != 0
[ LINE ] --- dispatch_test.c:419: error: Failure!I:dispatch_test:Core dump found: ./core.23758
D:dispatch_test:backtrace from ./core.23758 start
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
[New LWP 23758]
[New LWP 23799]
[New LWP 23798]
[New LWP 24634]
Downloading separate debug info for /lib/x86_64-linux-gnu/libcmocka.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libuv.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libssl.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libcrypto.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libz.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libjson-c.so.5...
Downloading separate debug info for /lib/x86_64-linux-gnu/libnghttp2.so.14...
Downloading separate debug info for /lib/x86_64-linux-gnu/libxml2.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu.so.8...
Downloading separate debug info for /root/.cache/debuginfod_client/be4446e17e11dc07dd007465b7e3008bc69f905a/debuginfo...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu-common.so.8...
Downloading separate debug info for /lib/x86_64-linux-gnu/libgssapi_krb5.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkrb5.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libmaxminddb.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libfstrm.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libprotobuf-c.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/liblmdb.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu-cds.so.8...
Downloading separate debug info for /lib/x86_64-linux-gnu/libicuuc.so.72...
Downloading separate debug info for /root/.cache/debuginfod_client/0bc79e91cbc31da5a4c73b10bff30734ec138da0/debuginfo...
Downloading separate debug info for /lib/x86_64-linux-gnu/liblzma.so.5...
Downloading separate debug info for /lib/x86_64-linux-gnu/libk5crypto.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libcom_err.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkrb5support.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkeyutils.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libicudata.so.72...
Downloading separate debug info for /lib/x86_64-linux-gnu/libstdc++.so.6...
Downloading separate debug info for /lib/x86_64-linux-gnu/libgcc_s.so.1...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/tests/dns/.libs/dispatch_test'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c.
44 ./nptl/pthread_kill.c: Inappropriate ioctl for device.
[Current thread is 1 (Thread 0x7f91a32d6b80 (LWP 23758))]
Thread 4 (LWP 24634):
#0 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x0
Thread 3 (Thread 0x7f91a304d680 (LWP 23798)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f91a55bcbf4 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x557352879600) at ../include/urcu/futex.h:81
No locals.
#2 futex_async (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x557352879600) at ../include/urcu/futex.h:113
ret = <optimized out>
ret = <optimized out>
#3 futex_wait (futex=futex@entry=0x557352879600) at ./src/workqueue.c:135
__func__ = "futex_wait"
#4 0x00007f91a55bd035 in workqueue_thread (arg=0x5573528795c0) at ./src/workqueue.c:246
cbs_tmp_n = <optimized out>
splice_ret = <optimized out>
cbs_tmp_head = {node = {next = 0x55735285fa40}, lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}
cbs_tmp_tail = {p = 0x557352898e50}
cbs = <optimized out>
cbcount = <optimized out>
workqueue = 0x5573528795c0
rt = 0
__func__ = "workqueue_thread"
__PRETTY_FUNCTION__ = "workqueue_thread"
#5 0x00007f91a5ea63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
ret = <optimized out>
pd = <optimized out>
out = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140263530586416, -6319514938243892525, -808, 0, 140723762111680, 140263473598464, 6300488242360924883, 6300493485668219603}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f91a5f26a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 2 (Thread 0x7f91a284c680 (LWP 23799)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f91a626d3ad in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x557352852020) at ../include/urcu/futex.h:81
No locals.
#2 futex_noasync (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x557352852020) at ../include/urcu/futex.h:90
ret = <optimized out>
ret = <optimized out>
#3 call_rcu_wait (crdp=0x557352851fe0) at ./src/urcu-call-rcu-impl.h:248
__func__ = "call_rcu_wait"
#4 call_rcu_thread (arg=0x557352851fe0) at ./src/urcu-call-rcu-impl.h:400
cbs_tmp_n = <optimized out>
splice_ret = <optimized out>
cbs_tmp_head = {node = {next = 0x55735287d778}, lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}
cbs_tmp_tail = {p = 0x557352876df0}
cbs = <optimized out>
cbcount = <optimized out>
crdp = 0x557352851fe0
rt = 0
__func__ = "call_rcu_thread"
__PRETTY_FUNCTION__ = "call_rcu_thread"
#5 0x00007f91a5ea63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
ret = <optimized out>
pd = <optimized out>
out = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140263530586416, -6319514938243892525, -808, 115, 140723762111824, 140263465205760, 6300491538211453651, 6300493485668219603}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f91a5f26a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 1 (Thread 0x7f91a32d6b80 (LWP 23758)):
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {24576}}
ret = <optimized out>
#1 0x00007f91a5ea815f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
No locals.
#2 0x00007f91a5e5a472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x00007f91a5e444b2 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {93953797214704, 140263484650848, 4294934528, 7, 140263531945088, 7, 0, 12880216814053340279, 9278577283777313019, 6439199540737383679, 93953794348112, 140263536447415, 140263530288466, 8, 140263530288466, 0}}, sa_flags = 1373274116, sa_restorer = 0x1a3}
#4 0x00007f91a63b7f45 in exit_test (quit_application=1) at ./src/cmocka.c:404
env = 0x7ffccdda8a0a "1"
abort_test = <optimized out>
#5 0x00007f91a63b7fda in _fail (file=file@entry=0x557351da8004 "dispatch_test.c", line=line@entry=419) at ./src/cmocka.c:2196
output = <optimized out>
#6 0x00007f91a63ba0bf in _assert_int_equal (a=<optimized out>, b=b@entry=0, file=file@entry=0x557351da8004 "dispatch_test.c", line=line@entry=419) at ./src/cmocka.c:1800
No locals.
#7 0x0000557351da695a in response_getnext (result=<optimized out>, region=<optimized out>, arg=0x55735283e170) at dispatch_test.c:419
test = 0x55735283e170
#8 0x00007f91a60596e5 in udp_recv (handle=0x557352899450, eresult=ISC_R_TIMEDOUT, region=0x7ffccdda6bb0, arg=<optimized out>) at dispatch.c:618
resp = 0x557352898340
disp = <optimized out>
id = 0
dres = <optimized out>
source = {magic = 1384304336, base = 0x6e8, length = 1494, used = 0, current = 3453643520, active = 32764, extra = 1384304336, dynamic = 115, link = {prev = 0x7f91a64127d8 <add_trace_entry+296>, next = 0x8}, mctx = 0x1a800000000}
flags = 3453643280
peer = {type = {sa = {sa_family = 27408, sa_data = "\332\315\374\177\000\000\212GA\246\221\177\000"}, sin = {sin_family = 27408, sin_port = 52698, sin_addr = {s_addr = 32764}, sin_zero = "\212GA\246\221\177\000"}, sin6 = {sin6_family = 27408, sin6_port = 52698, sin6_flowinfo = 32764, sin6_addr = {__in6_u = {__u6_addr8 = "\212GA\246\221\177\000\000 k\332\315\374\177\000", __u6_addr16 = {18314, 42561, 32657, 0, 27424, 52698, 32764, 0}, __u6_addr32 = {2789296010, 32657, 3453643552, 32764}}}, sin6_scope_id = 1384603504}, ss = {ss_family = 27408, __ss_padding = "\332\315\374\177\000\000\212GA\246\221\177\000\000 k\332\315\374\177\000\000p_\207RsU\000\000p_\207RsU\000\000\240\255\264RsU\000\000\000\000\000\000\000\000\000\000`\232\203RsU\000\000`k\332\315\374\177\000\000\324EA\246\221\177\000\000@k\332\315\374\177\000\000{\240C\246\221\177\000\000\000\000\000\000\000\000\000\000\326\005", '\000' <repeats 13 times>, __ss_align = 93953794203504}}, length = 1384603504, link = {prev = 0x7f91a643a07b, next = 0x0}}
netaddr = {family = 2789449851, type = {in = {s_addr = 32657}, in6 = {__in6_u = {__u6_addr8 = "\221\177\000\000\240\255\264RsU\000\000w\264\2517", __u6_addr16 = {32657, 0, 44448, 21172, 21875, 0, 46199, 14249}, __u6_addr32 = {32657, 1387572640, 21875, 933868663}}}, un = "\221\177\000\000\240\255\264RsU\000\000w\264\2517\363\270\277\262%\310%\001\304\370\241\215\221\237\355\250li\301\345\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\320k\332\315\374\177\000\0008e\207RsU\000\000\001", '\000' <repeats 15 times>, "`\232\203RsU\000\000\240\255\264RsU\000\000\320\316\202RsU\000"}, zone = 64}
match = 32764
timeout = <optimized out>
respond = <optimized out>
now = {seconds = 1533, nanoseconds = 0}
done = <optimized out>
#9 0x00007f91a63e8f28 in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1764
uvreq = 0x557352b4ada0
region = {base = 0x0, length = 0}
#10 isc__nm_readcb (sock=sock@entry=0x557352875f70, uvreq=<optimized out>, eresult=eresult@entry=ISC_R_TIMEDOUT, async=async@entry=false) at netmgr/netmgr.c:1779
No locals.
#11 0x00007f91a63e9009 in isc__nmsocket_readtimeout_cb (timer=0x5573528763b0) at netmgr/netmgr.c:1113
req = <optimized out>
sock = 0x557352875f70
#12 0x00007f91a638def6 in uv__run_timers (loop=loop@entry=0x55735287c5b0) at ./src/timer.c:178
heap_node = 0x557352876418
handle = 0x5573528763b0
#13 0x00007f91a639243a in uv_run (loop=loop@entry=0x55735287c5b0, mode=mode@entry=UV_RUN_DEFAULT) at ./src/unix/core.c:465
timeout = <optimized out>
r = <optimized out>
can_sleep = <optimized out>
#14 0x00007f91a640f554 in loop_thread (arg=arg@entry=0x55735287c590) at loop.c:282
loop = 0x55735287c590
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#15 0x00007f91a641f893 in thread_body (wrap=0x55735283e170) at thread.c:85
func = 0x7f91a640f4d0 <loop_thread>
arg = 0x55735287c590
ret = 0x0
jemalloc_enforce_init = 0x557352b52d00
#16 isc_thread_main (func=func@entry=0x7f91a640f4d0 <loop_thread>, arg=0x55735287c590) at thread.c:116
No locals.
#17 0x00007f91a64106ac in isc_loopmgr_run (loopmgr=0x55735287d4c0) at loop.c:454
__func__ = "isc_loopmgr_run"
#18 0x0000557351da5766 in run_test_dispatch_getnext (state=<optimized out>) at dispatch_test.c:741
setup_loop = 0x0
teardown_loop = 0x0
#19 0x00007f91a63ba8f8 in cmocka_run_one_test_or_fixture (function_name=0x557351da813c "dispatch_getnext", test_func=0x557351da5740 <run_test_dispatch_getnext>, setup_func=setup_func@entry=0x0, teardown_func=teardown_func@entry=0x0, state=<optimized out>, state@entry=0x55735282ac80, heap_check_point=heap_check_point@entry=0x0) at ./src/cmocka.c:2801
check_point = 0x7f91a32d68d0
handle_exceptions = <optimized out>
current_state = 0x0
rc = 0
#20 0x00007f91a63bafdb in cmocka_run_one_tests (test_state=0x55735282ac70) at ./src/cmocka.c:2909
start = {tv_sec = 1700007173, tv_nsec = 801457005}
finish = {tv_sec = 0, tv_nsec = 0}
rc = 0
start = <optimized out>
finish = <optimized out>
rc = <optimized out>
#21 _cmocka_run_group_tests (group_name=group_name@entry=0x557351da806e "tests", tests=tests@entry=0x557351da9be0 <tests>, num_tests=num_tests@entry=10, group_setup=group_setup@entry=0x0, group_teardown=group_teardown@entry=0x0) at ./src/cmocka.c:3040
cmtest = 0x55735282ac70
test_number = 10
cm_tests = 0x55735282aac0
group_check_point = <optimized out>
group_state = 0x0
total_tests = <optimized out>
total_failed = <optimized out>
total_passed = 9
total_executed = 9
total_errors = 0
total_skipped = 0
total_runtime = 20.010910813999995
i = 9
rc = <optimized out>
#22 0x0000557351da5493 in main () at dispatch_test.c:855
r = <optimized out>
D:dispatch_test:backtrace from ./core.23758 end
FAIL dispatch_test (exit status: 134)
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4427Various improvements to hashing and hash table management2024-02-24T08:19:32ZMichał KępieńVarious improvements to hashing and hash table managementThis is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
...This is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
[1]: https://mattermost.isc.org/isc/pl/rsyemrkwhtfcbxhtyxddhkn58yMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4426Feature request - client.bind chaos class queries2023-11-20T10:39:24ZRay BellisFeature request - client.bind chaos class queriesNot plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/3144redetect-interfaces command2024-02-08T14:35:31ZTomek Mrugalskiredetect-interfaces commandThe idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is tha...The idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is that Kea could be told that some new interfaces appeared or disappeared (VLAN, PPP, some other tunnel etc.) and Kea should redetect them. For an added bonus, there should be a way to tell Kea to open sockets on those new interfaces. This can be done either by telling Kea to open the on any newly detected interfaces or perhaps return a list of interfaces and have a dedicated call `open-socket` or something similar? Anyway, this would be useful to have a mini-design for.
This problem is not new and there are many requests in this problem space:
- A [nicely described use case in #3040](https://gitlab.isc.org/isc-projects/kea/-/issues/3040#note_414899)
- #1084
- #3062
- possibly couple morenext-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4423named starts up slow when many zones reference the same dnssec-policy2024-02-24T07:54:22ZMatthijs Mekkingmatthijs@isc.orgnamed starts up slow when many zones reference the same dnssec-policyWhile rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones af...While rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones after reload/reconfig and CPU usage of the named process remains at 100% and it takes quite a few minutes for named to start responding to queries after such a reload/reconfig request.
When spreading my zones to 10 identical policies, cpu usage goes well above 100% (using more threads I assume) and this is speeding
things up really nice.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4422No supported algorithms on platform2024-02-29T15:26:01ZMark AndrewsNo supported algorithms on platformJob [#3783240](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3783240) failed for 5d20a7ce254dabe1d4a99f7bd0fd1cfa6309124b:
```
$ PYTHON="$(source bin/tests/system/conf.sh; echo $PYTHON)"
Traceback (most recent call last):
File "/bu...Job [#3783240](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3783240) failed for 5d20a7ce254dabe1d4a99f7bd0fd1cfa6309124b:
```
$ PYTHON="$(source bin/tests/system/conf.sh; echo $PYTHON)"
Traceback (most recent call last):
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 241, in <module>
main()
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 227, in main
algs = filter_supported(algs)
^^^^^^^^^^^^^^^^^^^^^^
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 138, in filter_supported
raise RuntimeError(
RuntimeError: no DEFAULT algorithm from "stable" set supported on this platform
$
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/kea/-/issues/3140Feature request: Add Statistics Counters for dropped packets (for various dif...2024-03-27T12:51:09ZCathy AlmondFeature request: Add Statistics Counters for dropped packets (for various different reasons)---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
...---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
This is loosely related to issue #3125 for counting some dropped packets due to HA (#3125 is more about not logging them unnecessarily though, or being able to disable the per-event logging).
This is a request to add a specific packet counts for both HA and for other dropped packets such as ones dropped due to kea being disabled.
Customer requesting this feature currently has an issue where they can't tell if an operator has misconfigured their network such that Kea wasn't receiving any traffic or if it was in a disabled state due to Kea HA sync.
Version 2.2
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3137Audit revision conflicts between IPv4 and IPv6 due to shared session variable2023-11-23T14:37:03ZMaurice MakaayAudit revision conflicts between IPv4 and IPv6 due to shared session variable**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_rev...**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_revision_id`. These session variables tightly couple the two paths, which can lead to conflicts.
**To Reproduce**
Here's an example scenario for a conflict:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, ok
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, fail
```
Because the global revision id now points at 2, but only `dhcp6_audit` with id 1 exists, we get:
```
ERROR: insert or update on table "dhcp6_audit" violates foreign key constraint "fk_dhcp6_audit_revision"
DETAIL: Key (revision_id)=(2) is not present in table "dhcp6_audit_revision".
CONTEXT: SQL statement "INSERT INTO dhcp6_audit (object_type, object_id, modification_type, revision_id)
VALUES (object_type_val, object_id_val,
(SELECT id FROM modification WHERE modification_type = modification_type_val),
audit_revision_id)"
PL/pgSQL function createauditentrydhcp6(character varying,bigint,character varying) line 11 at SQL statement
SQL statement "SELECT createAuditEntryDHCP6('dhcp6_client_class', NEW.id, 'create')"
PL/pgSQL function func_dhcp6_client_class_ains() line 4 at PERFORM
```
In this case, the INSERT breaks, because the DHCP6 audit record points to a non-existent `dhcp6_audit_revision` id.
Another scenario is possible, where coincidentally the incorrect revision id does exist. In that case, the audit will be assigned to an old revision in the audit trail, changing history. An example scenario for this one:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('one'); -- uses audit_revision_id = 1, ok
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('two'); -- uses audit_revision_id = 2, ok
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 1, ok
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('three'); -- uses audit_revision_id = 1, fail
```
**Expected behavior**
The audit revisions should be independent and use their own specific session variables, instead of shared ones.
When running the first scenario from the reproduction scenario:
- It must not fail
- The DHCP6 change must be logged in `dhcp6_audit` with `revision_id` = 1
- The DHCP4 change must be logged in `dhcp4_audit` with `revision_id` = 2
When running the second scenario:
- DHCP4 client class 'one' must be related to `dhcp4_audit' with `revision_id` = 1
- DHCP4 client class 'two' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP4 client class 'three' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP6 client class 'something' must be related to `dhcp6_audit' with `revision_id` = 1
**Environment:**
- Kea version: 2.5.3 and before
- Affects both MySQL and PostgreSQL
**Work-around**
To prevent issues with the current database schema, make sure that DHCP4 and DHCP6 updates are separated in the query sequence:
- create DHCP4 audit revision
- perform all DHCP4 updates
- create DHCP6 audit revision
- perform all DHCP6 updates
**Contacting you**
You can reach me at account-gitlab-isc@makaay.nloutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4416ccmsg doesn't support multiple message read in the single TCP read2023-11-09T09:35:42ZDominik Thalhammerccmsg doesn't support multiple message read in the single TCP read### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_be...### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_beta`
```
BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-B5s8Yi/bind9-9.18.12=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
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 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 json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
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/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Send multiple requests via rndc in rapid succession. The particular program used to initially observe the issue is closed source and tightly integrated, however the following script using `bind9-rndc-node` experiences the same behaviour.
```js
var RNDC = require('bind9-rndc');
var key = 'BzDBJ1B/JbQg9iXJYAGZLQ==';
var session = RNDC.connect('172.17.0.2', 953, key, 'md5');
var test_count = 10;
var recv_count = 0;
session.on('ready', () => {
for(var i = 0; i < test_count; i++)
session.send('status');
});
session.on('data', (obj) => {
recv_count++;
console.log("Got " + recv_count);
console.log(obj);
});
session.on('error', console.log);
```
### What is the current *bug* behavior?
Bind correctly handles some of the requests but drops others. Depending on the message size and timing the indices of the recognized messages vary and sometimes bind looses track entirely until it drops the connection with a timeout.
### What is the expected *correct* behavior?
The number of responses is equal to the number of requests (the order can vary, thats what `_ser` is for) and the stream stays in sync, regardless of the timing when sending messages. If bind can not keep up with the client it should use the tcp blocking to signal this instead of dropping data.
### Relevant configuration files
named.conf
```
key "rndc-key" {
algorithm hmac-md5;
secret "BzDBJ1B/JbQg9iXJYAGZLQ==";
};
controls {
inet 0.0.0.0 allow { any; } keys { "rndc-key"; };
};
options {
directory "/var/cache/bind";
version none;
allow-query { any; };
allow-recursion { any; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { };
listen-on { any; };
};
```
### Relevant logs and/or screenshots
Sample output of script (note theres a rather long pause before `warning: unread...`):
```
(node:10142) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Got 1
Map(0) {
type: 'status',
result: '0',
text: 'version: BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:> (version.bind/txt/ch disabled)\n' +
'running on 54d01852d58b: Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2\n' +
'boot time: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'last configured: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'configuration file: /etc/bind/named.conf\n' +
'CPUs found: 16\n' +
'worker threads: 16\n' +
'UDP listeners per interface: 16\n' +
'number of zones: 101 (99 automatic)\n' +
'debug level: 0\n' +
'xfers running: 0\n' +
'xfers deferred: 0\n' +
'soa queries in progress: 0\n' +
'query logging is OFF\n' +
'recursive clients: 0/900/1000\n' +
'tcp clients: 0/150\n' +
'TCP high-water: 0\n' +
'server is up and running'
}
warning: unread data left over
```
Relevant log output for this transaction:
`04-Nov-2023 15:12:17.519 invalid command from 172.17.0.1#40764: timed out`
### Possible fixes
I am not familiar with the bind9 source code, but I will take a look if I can find something (along with retesting on the master branch).
A fix for clients is to ensure that there is never more than one message in flight. This fixes the issue, but vastly degrades performance if the latency between server and client is huge.Not planned