ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-09-13T20:52:00Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2302DOT scalability, performance testing2021-09-13T20:52:00ZVicky Riskvicky@isc.orgDOT scalability, performance testingWe need to find a way to test with a large number of DOT connections for scalability. I understand our current perflab set up cannot do this.
The goals of this might include:
- checking that DOT scaling is equivalent to TCP scaling (if...We need to find a way to test with a large number of DOT connections for scalability. I understand our current perflab set up cannot do this.
The goals of this might include:
- checking that DOT scaling is equivalent to TCP scaling (if it is much worse we might consider that a bug)
- providing some guidance to users about throughput (e.g. as a % of UDP performance)
- verifying (functionally) that rate limits work as expected for DOThttps://gitlab.isc.org/isc-projects/dhcp/-/issues/152Support DHCP relay on interfaces with zero MAC address2022-03-09T19:06:03ZQingtao CaoSupport DHCP relay on interfaces with zero MAC addressThe dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC a...The dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC address, the ipsecX interfaces built upon such wwanX interfaces won't have L2 addresses, resulting in the dhcrelay daemon unable to use them.
I will try to propose a patchset to support such interfaces.Outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2303Override fetch-limits when stale-answer-enable is 'yes' for queries that are ...2021-06-08T09:11:23ZCathy AlmondOverride fetch-limits when stale-answer-enable is 'yes' for queries that are attempting to refresh positive stale RRsetsSee also #2066, #2273, #2247 and #2248
The final piece of the puzzle is having Serve Stale play nicely with fetch-limits.
See also [https://bugs.isc.org/Ticket/Display.html?id=41259](https://bugs.isc.org/Ticket/Display.html?id=41259)
...See also #2066, #2273, #2247 and #2248
The final piece of the puzzle is having Serve Stale play nicely with fetch-limits.
See also [https://bugs.isc.org/Ticket/Display.html?id=41259](https://bugs.isc.org/Ticket/Display.html?id=41259)
Q. When fetch-limits are triggered, how do you give precedence to known 'good' client queries?
A. You base this on the existence of stale content already in cache.
Q. How do you override fetch-limits in a safe way (so that you don't override fetch-limits for every 'good' client query and still overwhelm the authoritative servers?
A. You have to have serving of stale answers enabled - that way you already have a built-in mechanism to rate-limit the refresh retries.
The current (and soon to be improved) implementation of serve-stale still only triggers serving of stale content if there is a stale answer already in cache that could be used, AND an attempt to refresh the stale content has timed out. If we don't attempt to refresh it, then it won't be served stale and the stale-refresh-time countdown won't be started for this query.
The same also applies if we served it stale once, but the stale-refresh-time has now expired again, and we need to try again to contact the authoritative servers - if we get blocked by fetch-limits (fetches-per-zone or fetches-per-server) we still won't use the stale data.
My request is that if these three condition are met, that we bypass fetchlimits and try to resolve the query anyway. The conditions are:
- The server has `stale-answer-enable yes;`
- The name/type being resolved can be answered from cache, should it be necessary to serve a stale answer
- This is not a negative response (NXDOMAIN or NXRRSET)
The risk of bypassing fetchlimits is low
a) we know that this query has been resolved before, so it might be possible to again and it is a better candidate query to bypass fetchlimits than a brand new name that this resolver hasn't encountered before - particularly if this resolver is also being used to participate in a PRSD-style attack
b) even if the query times out, this will trigger serving of the stale answer to all other clients who arrive with the same query during `stale-refresh-time`
It would be really good to get this into the December releases with the other improvements to Serve Stalehttps://gitlab.isc.org/isc-projects/bind9/-/issues/2304Insecure data handling and null pointer dereferences in test-async.c2021-09-03T05:05:05ZMichal NowakInsecure data handling and null pointer dereferences in test-async.c@each Coverity identified following problems in the new `bin/tests/system/hooks/driver/test-async.c`:
```
*** CID 313488: Insecure data handling (TAINTED_SCALAR)
/bin/tests/system/hooks/driver/test-async.c: 345 in async_query_done_begi...@each Coverity identified following problems in the new `bin/tests/system/hooks/driver/test-async.c`:
```
*** CID 313488: Insecure data handling (TAINTED_SCALAR)
/bin/tests/system/hooks/driver/test-async.c: 345 in async_query_done_begin()
339 }
340
341 /* initial call */
342 state->async = true;
343 state->hookpoint = NS_QUERY_DONE_BEGIN;
344 state->origresult = *resp;
>>> CID 313488: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "qctx->client" to a tainted sink.
345 ns_query_hookasync(qctx, doasync, state);
346 return (NS_HOOK_RETURN);
347 }
348
349 static ns_hookresult_t
350 async_qctx_destroy(void *arg, void *cbdata, isc_result_t *resp) {
```
```
*** CID 281450: Null pointer dereferences (REVERSE_INULL)
/bin/tests/system/hooks/driver/test-async.c: 163 in plugin_register()
157
158 *instp = inst;
159
160 return (ISC_R_SUCCESS);
161
162 cleanup:
>>> CID 281450: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "inst" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
163 if (result != ISC_R_SUCCESS && inst != NULL) {
164 plugin_destroy((void **)&inst);
165 }
166
167 return (result);
168 }
```
More information at https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=37570751&defectInstanceId=11302475&mergedDefectId=313488.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/kea/-/issues/1567EXTRA_DIST issues found during 1.9.2 sanity checks2020-12-11T17:12:14ZAndrei Pavelandrei@isc.orgEXTRA_DIST issues found during 1.9.2 sanity checkskea1.9.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1568CA warnings when building tests2020-12-09T11:42:27ZRazvan BecheriuCA warnings when building testsfound during #1565
```
In file included from ca_cfg_mgr_unittests.cc:14:
../../../../src/bin/agent/tests/test_libraries.h:23:20: warning: ‘{anonymous}::BASIC_AUTH_LIBRARY’ defined but not used [-Wunused-variable]
23 | static const cha...found during #1565
```
In file included from ca_cfg_mgr_unittests.cc:14:
../../../../src/bin/agent/tests/test_libraries.h:23:20: warning: ‘{anonymous}::BASIC_AUTH_LIBRARY’ defined but not used [-Wunused-variable]
23 | static const char* BASIC_AUTH_LIBRARY = "/home/razvan/isc/releases/kea-1.9.2-rc1/kea-1.9.2-work/src/bin/agent/tests/.libs/libbasicauth.so";
| ^~~~~~~~~~~~~~~~~~
In file included from ca_response_creator_unittests.cc:20:
../../../../src/bin/agent/tests/test_libraries.h:20:20: warning: ‘{anonymous}::CALLOUT_LIBRARY’ defined but not used [-Wunused-variable]
20 | static const char* CALLOUT_LIBRARY = "/home/razvan/isc/releases/kea-1.9.2-rc1/kea-1.9.2-work/src/bin/agent/tests/.libs/libcallout.so";
| ^~~~~~~~~~~~~~~
CXX ca_unittests-parser_unittests.o
CXX ca_unittests-get_config_unittest.o
CXX libcallout_la-callout_library.lo
CXX libbasicauth_la-basic_auth_library.lo
In file included from get_config_unittest.cc:24:
test_libraries.h:23:20: warning: ‘{anonymous}::BASIC_AUTH_LIBRARY’ defined but not used [-Wunused-variable]
23 | static const char* BASIC_AUTH_LIBRARY = "/home/razvan/isc/releases/kea-1.9.2-rc1/kea-1.9.2-work/src/bin/agent/tests/.libs/libbasicauth.so";
| ^~~~~~~~~~~~~~~~~~
basic_auth_library.cc: In member function ‘virtual isc::http::HttpResponsePtr {anonymous}::ResponseCreator::createStockHttpResponse(const HttpRequestPtr&, const isc::http::HttpStatusCode&) const’:
basic_auth_library.cc:63:64: warning: unused parameter ‘request’ [-Wunused-parameter]
63 | ResponseCreator::createStockHttpResponse(const HttpRequestPtr& request,
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
basic_auth_library.cc: In member function ‘virtual isc::http::HttpResponsePtr {anonymous}::ResponseCreator::createDynamicHttpResponse(isc::http::HttpRequestPtr)’:
basic_auth_library.cc:72:59: warning: unused parameter ‘request’ [-Wunused-parameter]
72 | ResponseCreator::createDynamicHttpResponse(HttpRequestPtr request) {
```kea1.9.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1569link warnings on MacOs2020-12-21T13:53:04ZRazvan Becheriulink warnings on MacOsfound during #1565
```
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_linux.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(lib...found during #1565
```
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_linux.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_sun.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_linux.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_sun.o) has no symbols
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1570CB failures when using oracle mysql 8.0.222021-04-09T09:38:25ZRazvan BecheriuCB failures when using oracle mysql 8.0.22several unittests fail when upgrading to oracle mysql 8.0.22
```
[ PASSED ] 123 tests.
[ FAILED ] 6 tests, listed below:
[ FAILED ] MySqlConfigBackendDHCPv4Test.deleteSubnet4
[ FAILED ] MySqlConfigBackendDHCPv4Test.deleteSharedNe...several unittests fail when upgrading to oracle mysql 8.0.22
```
[ PASSED ] 123 tests.
[ FAILED ] 6 tests, listed below:
[ FAILED ] MySqlConfigBackendDHCPv4Test.deleteSubnet4
[ FAILED ] MySqlConfigBackendDHCPv4Test.deleteSharedNetwork4
[ FAILED ] MySqlConfigBackendDHCPv4Test.getAllOptionDefs4
[ FAILED ] MySqlConfigBackendDHCPv6Test.deleteSubnet6
[ FAILED ] MySqlConfigBackendDHCPv6Test.deleteSharedNetwork6
[ FAILED ] MySqlConfigBackendDHCPv6Test.getAllOptionDefs6
```
fount during sanity checks on 1.9.1 and 1.9.2 (28 oct 2020)
package release date for Ubuntu 20.04:
| 8.0.22-0ubuntu0.20.04.2 | security, updates (main) | 2020-10-27 |
```
[ RUN ] MySqlConfigBackendDHCPv4Test.deleteSubnet4
mysql_cb_dhcp4_unittest.cc:1738: Failure
Expected equality of these values:
1
deleted_count
Which is: 2
Google Test trace:
mysql_cb_dhcp4_unittest.cc:1733: one server
mysql_cb_dhcp4_unittest.cc:1759: Failure
Expected equality of these values:
1
deleted_count
Which is: 2
Google Test trace:
mysql_cb_dhcp4_unittest.cc:1754: one server
[ FAILED ] MySqlConfigBackendDHCPv4Test.deleteSubnet4 (272 ms)
[ RUN ] MySqlConfigBackendDHCPv4Test.deleteSharedNetwork4
mysql_cb_dhcp4_unittest.cc:2762: Failure
Expected equality of these values:
1
deleted_count
Which is: 2
Google Test trace:
mysql_cb_dhcp4_unittest.cc:2756: one server
[ FAILED ] MySqlConfigBackendDHCPv4Test.deleteSharedNetwork4 (200 ms)
[ RUN ] MySqlConfigBackendDHCPv4Test.getAllOptionDefs4
mysql_cb_dhcp4_unittest.cc:505: Failure
Expected equality of these values:
audit_entries_size_save + new_entries_num
Which is: 3
audit_entries_[tag].size()
Which is: 2
dhcp4_option_def, 29, 0, 2020-Nov-25 11:33:39, 1174, option definition set
dhcp4_option_def, 29, 1, 2020-Nov-25 11:33:39, 1175, option definition set
Google Test trace:
mysql_cb_dhcp4_unittest.cc:3221: CREATE audit entry for the option defnition fish
mysql_cb_dhcp4_unittest.cc:505: Failure
Expected equality of these values:
audit_entries_size_save + new_entries_num
Which is: 3
audit_entries_[tag].size()
Which is: 2
dhcp4_option_def, 29, 0, 2020-Nov-25 11:33:39, 1174, option definition set
dhcp4_option_def, 29, 1, 2020-Nov-25 11:33:39, 1175, option definition set
Google Test trace:
mysql_cb_dhcp4_unittest.cc:3221: CREATE audit entry for the option defnition whale
mysql_cb_dhcp4_unittest.cc:3230: Failure
Expected equality of these values:
test_option_defs_.size() - updates_num
Which is: 3
option_defs.size()
Which is: 1
[ FAILED ] MySqlConfigBackendDHCPv4Test.getAllOptionDefs4 (138 ms)
[ RUN ] MySqlConfigBackendDHCPv6Test.deleteSubnet6
mysql_cb_dhcp6_unittest.cc:1748: Failure
Expected equality of these values:
1
deleted_count
Which is: 2
Google Test trace:
mysql_cb_dhcp6_unittest.cc:1743: one server
mysql_cb_dhcp6_unittest.cc:1769: Failure
Expected equality of these values:
1
deleted_count
Which is: 2
Google Test trace:
mysql_cb_dhcp6_unittest.cc:1764: one server
[ FAILED ] MySqlConfigBackendDHCPv6Test.deleteSubnet6 (283 ms)
[ RUN ] MySqlConfigBackendDHCPv6Test.deleteSharedNetwork6
mysql_cb_dhcp6_unittest.cc:2797: Failure
Expected equality of these values:
1
deleted_count
Which is: 2
Google Test trace:
mysql_cb_dhcp6_unittest.cc:2791: one server
[ FAILED ] MySqlConfigBackendDHCPv6Test.deleteSharedNetwork6 (159 ms)
[ RUN ] MySqlConfigBackendDHCPv6Test.getAllOptionDefs6
mysql_cb_dhcp6_unittest.cc:552: Failure
Expected equality of these values:
audit_entries_size_save + new_entries_num
Which is: 3
audit_entries_[tag].size()
Which is: 2
dhcp6_option_def, 29, 0, 2020-Nov-25 11:33:49, 1236, option definition set
dhcp6_option_def, 29, 1, 2020-Nov-25 11:33:49, 1237, option definition set
Google Test trace:
mysql_cb_dhcp6_unittest.cc:3258: CREATE audit entry for the option definition fish
mysql_cb_dhcp6_unittest.cc:552: Failure
Expected equality of these values:
audit_entries_size_save + new_entries_num
Which is: 3
audit_entries_[tag].size()
Which is: 2
dhcp6_option_def, 29, 0, 2020-Nov-25 11:33:49, 1236, option definition set
dhcp6_option_def, 29, 1, 2020-Nov-25 11:33:49, 1237, option definition set
Google Test trace:
mysql_cb_dhcp6_unittest.cc:3258: CREATE audit entry for the option definition whale
mysql_cb_dhcp6_unittest.cc:3268: Failure
Expected equality of these values:
test_option_defs_.size() - updates_num
Which is: 3
option_defs.size()
Which is: 1
[ FAILED ] MySqlConfigBackendDHCPv6Test.getAllOptionDefs6 (129 ms)
```kea1.9.6https://gitlab.isc.org/isc-projects/kea/-/issues/1571make uninstall leaves manuals and sample configuration files behind2021-06-18T09:56:20ZAndrei Pavelandrei@isc.orgmake uninstall leaves manuals and sample configuration files behind```
$ find /opt/kea -type f
/opt/kea/share/man/man8/kea-admin.8
/opt/kea/share/man/man8/kea-ctrl-agent.8
/opt/kea/share/man/man8/kea-dhcp4.8
/opt/kea/share/man/man8/kea-dhcp6.8
/opt/kea/share/man/man8/kea-dhcp-ddns.8
/opt/kea/share/man/m...```
$ find /opt/kea -type f
/opt/kea/share/man/man8/kea-admin.8
/opt/kea/share/man/man8/kea-ctrl-agent.8
/opt/kea/share/man/man8/kea-dhcp4.8
/opt/kea/share/man/man8/kea-dhcp6.8
/opt/kea/share/man/man8/kea-dhcp-ddns.8
/opt/kea/share/man/man8/kea-lfc.8
/opt/kea/share/man/man8/kea-netconf.8
/opt/kea/share/man/man8/kea-shell.8
/opt/kea/share/man/man8/keactrl.8
/opt/kea/share/man/man8/perfdhcp.8
/opt/kea/etc/kea/keactrl.conf
/opt/kea/etc/kea/kea-dhcp4.conf
/opt/kea/etc/kea/kea-dhcp6.conf
/opt/kea/etc/kea/kea-dhcp-ddns.conf
/opt/kea/etc/kea/kea-ctrl-agent.conf
```
is this intended?outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/460Record Kea configuration hash and detect no config change2020-12-04T12:53:59ZMarcin SiodelskiRecord Kea configuration hash and detect no config changeStork is periodically pulling configurations from Kea. To prevent repeating CPU intensive examination of the received config we should first compare the hashes of the existing and new config. That way we can easily detect whether the con...Stork is periodically pulling configurations from Kea. To prevent repeating CPU intensive examination of the received config we should first compare the hashes of the existing and new config. That way we can easily detect whether the configuration remains the same and skip the update altogether. When the config change has been detected, we can also emit an event.
This will to some degree address #353.0.14Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1572Backport #1542: `lease4-update` command has no effect and falsely reports suc...2020-11-28T09:06:57ZTomek MrugalskiBackport #1542: `lease4-update` command has no effect and falsely reports success on multithreaded v4We need to backport #1542 to 1.8 branch. Note there are patches available as attachments in #1542 or the fix can be cherry-picked from !1015.We need to backport #1542 to 1.8 branch. Note there are patches available as attachments in #1542 or the fix can be cherry-picked from !1015.kea1.8.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2305Did we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?2020-12-16T20:50:12ZMichael McNallyDid we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about t...A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about this because the behavior differed from an earlier version of BIND which did not exhibit the issue.
After some troubleshooting, it turns out that, due to a combination of factors -- some specific to the domain but also some applying to the server, they are hitting the max-recursion-queries limit of 75 queries that was set as part of the remediation for [CVE-2020-8616](https://kb.isc.org/docs/cve-2020-8616) (intended to prevent an exploit, demonstrated as a proof-of-concept by the researchers who reported it, that could send a server chasing a huge number of queries when processing a referral.)
The situation reported by the customer seems to demonstrate that a server with a not-very-unusual configuration can hit the limit while processing a common, fairly high-profile zone. Should we then adjust the limit, make changes to the log message visibility when the limit is hit, and/or make other changes?December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2306Compilation broken on systems without <sys/un.h>2020-11-26T15:52:36ZMichal NowakCompilation broken on systems without <sys/un.h>Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
s...Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
ssu_external.c:59:31: warning: unused parameter ‘path’ [-Wunused-parameter]
59 | ux_socket_connect(const char *path) {
| ~~~~~~~~~~~~^~~~
getaddrinfo.c: In function ‘get_local’:
getaddrinfo.c:1243:32: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr_un’
1243 | ai = ai_alloc(AF_LOCAL, sizeof(*slocal));
| ^
getaddrinfo.c:1249:16: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
getaddrinfo.c:1249:47: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
```
I don't know what operating systems might be affected, probably none (even Solaris 10 has it), one can "emulate" it like this and rebuild with `autoreconf -fi`:
```patch
--- a/configure.ac
+++ b/configure.ac
@@ -1799,9 +1799,9 @@ AS_IF([test "$enable_linux_caps" = "yes"],
AC_SUBST([LIBCAP_LIBS])
AC_CHECK_HEADERS(sys/un.h,
-ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
-,
ISC_PLATFORM_HAVESYSUNH="#undef ISC_PLATFORM_HAVESYSUNH"
+,
+ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
)
AC_SUBST(ISC_PLATFORM_HAVESYSUNH)
```
I tried for a short while and followed the compiler in fixing warnings and disabling code with `#ifdef ISC_PLATFORM_HAVESYSUNH` but I end up with either failing `tsiggss` system test or crashing `named`.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/kea/-/issues/1573fix warnings when compiling with -pedantic or -Wpedantic2021-09-28T09:40:55ZAndrei Pavelandrei@isc.orgfix warnings when compiling with -pedantic or -Wpedanticonly if the problem that the compiler reports is real and if an agreeable fix can be done, of course
shouldn't be too big of an effort
i think we already are warning-free for `-Wall` and `-Wextra`
```
export CXXFLAGS='-pedantic'
./con...only if the problem that the compiler reports is real and if an agreeable fix can be done, of course
shouldn't be too big of an effort
i think we already are warning-free for `-Wall` and `-Wextra`
```
export CXXFLAGS='-pedantic'
./configure
make
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1574make shell tests and shell scripts more robust2021-01-28T10:33:49ZAndrei Pavelandrei@isc.orgmake shell tests and shell scripts more robustMainly I would like to add `set -eu` on all shell scripts so that they don't fail silently i.e. with a success error code e.g. like they did in [ut-basic#119](https://jenkins.isc.org/job/kea-dev/job/ut-basic/119/).
```
[2020-11-23T02:06...Mainly I would like to add `set -eu` on all shell scripts so that they don't fail silently i.e. with a success error code e.g. like they did in [ut-basic#119](https://jenkins.isc.org/job/kea-dev/job/ut-basic/119/).
```
[2020-11-23T02:06:45.668Z] Executing kea-shell (echo | /home/jenkins/workspace/kea-dev/ut-basic/src/bin/shell/kea-shell --host 127.0.0.1 --port 8081 --auth-user pet --auth-password meow list-commands > /home/jenkins/workspace/kea-dev/ut-basic/src/bin/shell/tests/shell-stdout.txt)
[2020-11-23T02:06:45.668Z] sh: fail: unknown operand
```
For the same test `shell_process_tests.sh`, on my computer, it runs in bash since it's missing a shebang so I get a different error:
```
Executing kea-shell (echo | /home/andrei/work/isc/kea/src/bin/shell/kea-shell --host 127.0.0.1 --port 8081 --auth-user pet --auth-password meow list-commands > /home/andrei/work/isc/kea/src/bin/shell/tests/shell-stdout.txt)
/home/andrei/work/isc/kea/src/bin/shell/tests/basic_auth_tests.sh: line 119: [: ==: unary operator expected
```
Regardless, the test passes even though there is an undefiend variable there.
Adding a `#!/bin/sh` shebang to all scripts is another action I would like to take.
And adding all scripts to Gitlab CI.
And so on...kea1.9.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1575warnings on raspian2020-12-21T14:05:18ZFrancis Dupontwarnings on raspianhttps://gitlab.isc.org/isc-projects/kea/-/issues/1568#note_178684https://gitlab.isc.org/isc-projects/kea/-/issues/1568#note_178684outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2307"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answering2022-04-26T13:32:59ZMichał Kępień"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answeringThis started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with ...This started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with the following `named.conf`:
```
options {
listen-on port 5300 { 127.0.0.1; };
listen-on-v6 { none; };
};
```
Test with: `dig @localhost isc.org.` - it will time out even though it
should not. This is a change in behavior that was caught by [automated
RPM tests][1].
[1]: https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/57751April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/dhcp/-/issues/153Maximum number of interfaces supported by ISC DHCP2020-12-03T15:11:54ZRajiv ManickamMaximum number of interfaces supported by ISC DHCPHi, could anyone advise what is the maximum number of interfaces supported by isc dhcp.
maximum how many subnets can we congigure?Hi, could anyone advise what is the maximum number of interfaces supported by isc dhcp.
maximum how many subnets can we congigure?https://gitlab.isc.org/isc-projects/bind9/-/issues/2308RUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone2021-10-28T10:31:03ZDan MahoneyRUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone<!--
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 do *NOT* report it here, but send an
email to [...<!--
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 do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
RUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone
### BIND version used
```
BIND 9.14.8 (Stable Release) <id:5d87f66>
running on FreeBSD amd64 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-openssl=/usr' '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--without-geoip2' '--without-gssapi' '--with-libidn2=/usr/local' '--with-libjson=/usr/local' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.0' 'build_alias=amd64-portbld-freebsd12.0' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)
compiled with OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked to OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Have been trying to reproduce, and cannot. Putting it here to note it.
This happened when I told named to retransfer my catalog zone, and then do an rndc reconfig. RNDC reported the connection had been closed, and I found in the logs:
### What is the current *bug* behavior?
Named crashes.
### What is the expected *correct* behavior?
Not a crash
### Relevant configuration files
```
options {
catalog-zones {
zone "catalog.example"
default-masters { red.ac.te.d; }
in-memory no
zone-directory "/usr/local/etc/namedb/catzones"
min-update-interval 10;
};
```
Pretty standard stuff.
### Relevant logs and/or screenshots
```
Nov 24 20:03:35 he 1 2020-11-24T20:03:35.194329+00:00 he.gushi.org named 12049 - - catz: catz_delzone_taskaction: zone 'redacted.com' deleted
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.087641+00:00 he.gushi.org named 12049 - - /usr/local/etc/namedb/named.conf:13: catz: catalog zone 'catalog.example' will not be reconfigured
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088032+00:00 he.gushi.org named 12049 - - ./server.c:2961: fatal error:
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088049+00:00 he.gushi.org named 12049 - - RUNTIME_CHECK(tresult == 0) failed
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088059+00:00 he.gushi.org named 12049 - - exiting (due to fatal error in library)
Nov 24 20:04:02 he kernel: pid 12049 (named), uid 53: exited on signal 6
Nov 24 20:04:13 he 1 2020-11-24T20:04:13.666558+00:00 he.gushi.org named 200 - - starting BIND 9.14.8 (Stable Release) <id:5d87f66>
```
### Possible fixes
As above, server.c:2961November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2309dig core dump on SIGINT2020-11-26T09:30:10ZPeter Daviesdig core dump on SIGINT
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# d...
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# dig @173.37.137.80 .
^Cdighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back trace
/usr/local/lib/libisc.so.1706(+0x3d3e9) [0x7f67f2fca3e9]
/usr/local/lib/libisc.so.1706(isc_assertion_failed+0x10) [0x7f67f2fca320]
dig(+0x1728a) [0x56374da2028a]
dig(+0xc5fd) [0x56374da155fd]
dig(+0x6bb0) [0x56374da0fbb0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f67f2afc1e3]
dig(+0x6bee) [0x56374da0fbee]
Aborted (core dumped)
```
### What is the current *bug* behavior?
Core dumps
### What is the expected *correct* behavior?
silent exit
### Relevant configuration files
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
(If you can, link to the line of code that might be responsible for the
problem.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)