ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-01-08T21:01:02Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1578in HA hot-standby auto failover logs with off by 1 error2021-01-08T21:01:02ZWlodzimierz Wencelin HA hot-standby auto failover logs with off by 1 errorSmall error in HA hot-standby (load-balancing may be affected too but not tested). When server is configured with `"max-unacked-clients": 4,` standby server actually needs 5 clients with higher elapsed time/sec field to switch to `partne...Small error in HA hot-standby (load-balancing may be affected too but not tested). When server is configured with `"max-unacked-clients": 4,` standby server actually needs 5 clients with higher elapsed time/sec field to switch to `partner-down`kea1.9.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1577HA load balancing sometimes drop pkgs2020-11-26T17:01:53ZWlodzimierz WencelHA load balancing sometimes drop pkgsaffected: HA load-balancing in ST, MT mode, v4 and v6, with memfile, mysql, pgsql
configuration attached
[kea-dhcp6.conf1](/uploads/60c494b6270f7e1ffd52f3688776d617/kea-dhcp6.conf1)
[kea-dhcp6.conf](/uploads/c541b03ae04838db1faaed84d78...affected: HA load-balancing in ST, MT mode, v4 and v6, with memfile, mysql, pgsql
configuration attached
[kea-dhcp6.conf1](/uploads/60c494b6270f7e1ffd52f3688776d617/kea-dhcp6.conf1)
[kea-dhcp6.conf](/uploads/c541b03ae04838db1faaed84d789b41b/kea-dhcp6.conf)
logs:
[kea.log](/uploads/b57a83cc372c468a0f2d910651c032c1/kea.log)
[kea.log-CA](/uploads/8c97c1b65c2ba2cadb37a2c5912bb8aa/kea.log-CA)
[kea.log](/uploads/41b859db7e2c35236a9703f307940a38/kea.log)
[kea.log-CA](/uploads/4eb9f2c675a206e72614565e7b37c9d3/kea.log-CA)
What happens:
- client sends discover/solicit
- server gets discover/solicit and decide that this message is for him, and proceed with assigning lease
- server send offer/advertise
- client gets offer/advertise sends back request to the server
- server gets request and decide that this is not for him, drops request :(https://gitlab.isc.org/isc-projects/kea/-/issues/1576Forensic Logging: Option 82 values on renewals2021-05-07T15:39:09ZPeter DaviesForensic Logging: Option 82 values on renewalsForensic Logging: Option 82 values on renewals
Forensic logging correctly shows option 82 values on lease assignment
as: "... connected via relay at address: 10.0.0.1, identified by circuit-id: 01:02:03:04 and remote-id: 01:02:...Forensic Logging: Option 82 values on renewals
Forensic logging correctly shows option 82 values on lease assignment
as: "... connected via relay at address: 10.0.0.1, identified by circuit-id: 01:02:03:04 and remote-id: 01:02:03:04:05:06, ..."
However a number of dhcp client learn these values and include them in their renewal requests.
It would be of use to have these values presented if they were present as they would on an assignment.
An example of an assignment message:
2020-11-10 21:43:37 EET Address: 10.0.0.249 has been assigned for 1 hrs 0 mins 0 secs to a device with hardware address: hwtype=1 01:02:03:04:05:06, client-id: 01:02:03:04:05:06 connected via relay at address: 10.0.0.1, identified by circuit-id: 01:02:03:04:05:06 and remote-id: 01:02:03:04:05:06, context: { "ISC": { "relay-agent-info": "0x0102030405060708090A0B0C0D0E0F10111213141617191A1B1C1D1E1F202122232425262728292A2B" } }
An example of a renewal message: (with option 82 information)
2020-11-10 21:33:46 EET Address: 10.10.0.249 has been renewed for 1 hrs 0 mins 0 secs to a device with hardware address: hwtype=1 01:02:03:04:05:06, client-id: ff:24:6b:47:95:00:03:00:01:01:02:03:04:05:06, context: { "ISC": { "relay-agent-info": "0x0102030405060708090A0B0C0D0E0F10111213141617191A1B1C1D1E1F202122232425262728292A2B" } }
[RT #17277](https://support.isc.org/Ticket/Display.html?id=17277)kea1.9.8https://gitlab.isc.org/isc-projects/bind9/-/issues/2310BIND 9.11.25 has wrong formatted man pages2021-03-03T10:57:44ZPetr MenšíkBIND 9.11.25 has wrong formatted man pages### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps...### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps to reproduce
```
tar xzf bind-9.11.25.tar.gz
man bind-9.11.25/bin/named/named.8
```
### What is the current *bug* behavior?
```
NAMED(8) BIND9 NAMED(8)
.SH "NAME" named - Internet domain name server
.SH "SYNOPSIS"
.HP 144u
```
All generated manual pages have spaces before .SH, .PP etc. sections of man. At least man from Fedora cannot cope with it and display those sections when
### What is the expected *correct* behavior?
The same output as done on v9_11 branch
```
NAMED(8) BIND9 NAMED(8)
NAME
named - Internet domain name server
SYNOPSIS
named [[-4] | [-6]] [-c config-file] [-d debug-level] [-D string] [-E engine-name] [-f] [-g] [-L logfile] [-M option] [-m flag] [-n #cpus] [-p port]
[-s] [-S #max-socks] [-t directory] [-U #listeners] [-u user] [-v] [-V] [-X lock-file] [-x cache-file]
```
All manual pages seems to have the same issue, not just named.8.
### Relevant configuration files
none
### Relevant logs and/or screenshots
none
### Possible fixes
regenerate all pages with proper indentationDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michał KępieńMichał Kępieńhttps://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)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/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/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/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/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/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/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/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/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/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/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/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/stork/-/issues/458Replace 'appID' with server name or IP2021-03-01T20:15:48ZVicky Riskvicky@isc.orgReplace 'appID' with server name or IPthe appID is not useful to the humans (I realize it is useful to Stork). the human will be thinking of the Application by hostname or IP address. We need some naming scheme that is also implemented on the Kea server, so the same name can...the appID is not useful to the humans (I realize it is useful to Stork). the human will be thinking of the Application by hostname or IP address. We need some naming scheme that is also implemented on the Kea server, so the same name can be observed on Kea either directly or via Stork. One possibility is to have Stork get some sort of dhcp server 'name' from the Kea server. this could be a dns name but doesn't have to be.
Both users we tested with so far remarked that they didn't know what appID was or how to use it, and they were both searching for some key to associate a Kea server across multiple panels.0.15Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1565Sanity checks for Kea 1.9.2 rc12020-11-26T08:41:24ZjenkinsSanity checks for Kea 1.9.2 rc1```We are now at step SANITY CHECKS of Kea 1.9.2 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. ple...```We are now at step SANITY CHECKS of Kea 1.9.2 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. please, state in Sanity Checks issue in GitLab
what check you are doing in a thread/discussion (not as comment).
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/1.9.2-rc1
/data/shared/sweng/kea/releases/premium-1.9.2-rc1
/data/shared/sweng/kea/releases/subscription-1.9.2-rc1
SHA256 (kea-1.9.2.tar.gz) = da2585007783ed6cc904cd04a6817b040aedf7c5ecff66e3188db793a7939151
SHA256 (kea-premium-1.9.2.tar.gz) = 16f82cad89257cdf0914e6d2bfa8a502be776583e76d05684a6b581b5a754f3a
SHA256 (kea-subscription-1.9.2.tar.gz) = 14d90827cc08689df2f60526a3ef1cbf6045ab4adb41e3d28d33121598b59e23
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.isc.org/job/kea-dev/job/pkg/127/
Release version is 1.9.2-isc0009720201123144834 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```kea1.9.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/150Kea Migration Assistant2020-12-01T22:44:09ZAlexSSPKea Migration AssistantHi. Not found https://gitlab.isc.org/isc-projects/dhcp/-/archive/migration-assistant/dhcp-migration-assistant.tar.gzHi. Not found https://gitlab.isc.org/isc-projects/dhcp/-/archive/migration-assistant/dhcp-migration-assistant.tar.gz