ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-10-07T08:59:06Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2198CID 309658: Null pointer dereferences (REVERSE_INULL) in lib/dns/zone.c2020-10-07T08:59:06ZMichal NowakCID 309658: Null pointer dereferences (REVERSE_INULL) in lib/dns/zone.cCoverity Scan identified null pointer dereference on [`main`](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=36270434&defectInstanceId=11118673&mergedDefectId=309658) and later on [`v9_16`](https://scan8.coverity.com...Coverity Scan identified null pointer dereference on [`main`](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=36270434&defectInstanceId=11118673&mergedDefectId=309658) and later on [`v9_16`](https://scan8.coverity.com/reports.htm#v38342/p12582/fileInstanceId=36271991&defectInstanceId=11118776&mergedDefectId=309658):
```
*** CID 309658: Null pointer dereferences (REVERSE_INULL)
/lib/dns/zone.c: 13461 in create_query()
13455 if (qname != NULL) {
13456 dns_message_puttempname(message, &qname);
13457 }
13458 if (qrdataset != NULL) {
13459 dns_message_puttemprdataset(message, &qrdataset);
13460 }
>>> CID 309658: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "message" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
13461 if (message != NULL) {
13462 dns_message_detach(&message);
13463 }
13464 return (result);
13465 }
13466
```
Adding to %"October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.17.6)" milestone as this slipped-in this milestone.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/kea/-/issues/1451Allow linking with libgtest.so2024-01-22T08:32:18ZAndrei Pavelandrei@isc.orgAllow linking with libgtest.soCurrently Kea reports that googletest is missing even though `libgtest.so` is available. It only looks for `libgtest.a`. On Fedora 32 and maybe other distributions, only `libgtest.so` is provided with the out-of-the-box installed package...Currently Kea reports that googletest is missing even though `libgtest.so` is available. It only looks for `libgtest.a`. On Fedora 32 and maybe other distributions, only `libgtest.so` is provided with the out-of-the-box installed package and it would be nice to link with it rather than having to build googletest from sources.kea1.9.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1450Log every authentication attempt2020-12-04T13:12:42ZVicky Riskvicky@isc.orgLog every authentication attemptIt is important to log every authentication attempt, whether successful or failed, and the userID used.
Then, in the log for api calls, we should also add the authenticated userID who made that api call.
This was either not implemented ...It is important to log every authentication attempt, whether successful or failed, and the userID used.
Then, in the log for api calls, we should also add the authenticated userID who made that api call.
This was either not implemented in the basic authentication ticket, or it is not working.
see https://support.isc.org/Ticket/Display.html?id=17184kea1.9.1Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/415Basic access control Stork user -> Kea access2022-11-03T14:54:25ZVicky Riskvicky@isc.orgBasic access control Stork user -> Kea accessThe Kea administrator would like to be able to control who can access Kea. This includes individual Stork users, as Stork is just one channel for accessing Kea.
At the moment Stork is read-only, but it won't always be, and even control...The Kea administrator would like to be able to control who can access Kea. This includes individual Stork users, as Stork is just one channel for accessing Kea.
At the moment Stork is read-only, but it won't always be, and even controlling read-only access is important.
So it would be desirable if Stork would forward the userID of the authenticated Stork user to the Stork agent, and for this userID to be used to control the user's access to Kea, based on the privileges assigned to that user in Kea.
It is also as important as controlling access to log that access, with a time/date stamp, and what commands/api calls were executed. When there is write access (in the future) via Stork to make configuration changes, it will be particularly critical to identify who changed the configuration at what time.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1449Same vendor-specific-option has been attached multiple times under option 17 ...2020-12-04T09:00:28ZShubham GaurSame vendor-specific-option has been attached multiple times under option 17 if always-send flag is set true.---
name: Bug report
about: Setting "always-send" flag to true results in multiple instances of vendor-specific-option attached.
Further, these instances keep on incrementing within subsequent frames.
---
# Environment Specifica...---
name: Bug report
about: Setting "always-send" flag to true results in multiple instances of vendor-specific-option attached.
Further, these instances keep on incrementing within subsequent frames.
---
# Environment Specification
```
OS: CentOS 7 Virtual Machine
Server: kea-server-1.8 hosted over CentOS 8 Container
Client: isc-dhclient-4.3.6 configured over CentOS 8 Container
```
# Problem Description
I'm configuring dhcpv6 server with kea 1.8 stable version. I want to encapsulate vendor-specific information within option 17.
I faced certain issues and came across a workaround which had success with some undesirable behaviour.
1. Option defined under vendor option space (Eg vendor-12345) is not being sent automatically as part of option 17.
1. Forcing these options resulted in attaching and incrementing that vendor-specific-option within subsequent frames.
# Wireshark feeds
* Here, I have provided the snippet of Wireshark capture. The complete capture can be found in attachments.
```
Frame 4: 186 bytes on wire (1488 bits), 186 bytes captured (1488 bits)
Ethernet II, Src: 02:42:ac:12:00:02 (02:42:ac:12:00:02), Dst: 02:42:ac:12:00:03 (02:42:ac:12:00:03)
Internet Protocol Version 6, Src: fe80::42:acff:fe12:2, Dst: fe80::42:acff:fe12:3
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
Message type: Advertise (2)
Transaction ID: 0x01e550
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: 20
Value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Enterprise ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Frame 14: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits)
Ethernet II, Src: 02:42:ac:12:00:02 (02:42:ac:12:00:02), Dst: 02:42:ac:12:00:03 (02:42:ac:12:00:03)
Internet Protocol Version 6, Src: fe80::42:acff:fe12:2, Dst: fe80::42:acff:fe12:3
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
Message type: Advertise (2)
Transaction ID: 0x613d68
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Enterprise ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```
# Configurations & logs
[dhclient.conf](/uploads/87b37a1704f3ef58939d139606a57247/dhclient.conf)
[file-v2.pcap](/uploads/88d4a2a176591769166072cb2b4d96c8/file-v2.pcap)
[kea-dhcp6.conf](/uploads/ed6ed11c2a9ac3286fc236f68b7e3bc7/kea-dhcp6.conf)
## Help required
* Filing this scenario as a bug since I could not find any documentation to resolve this issue or meet my requirements.
* I have attached the configuration files. Please verify the same; whether, I have wrongly configured any option or missing out any option, that has to be handled within the conf file.
> PS: Testing env has been set up over container network. Logs/ Pcaps has been attached for the same.kea1.9.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/140Client Link-Layer Address Option in DHCPv62020-11-12T20:22:29ZChristian RebischkeClient Link-Layer Address Option in DHCPv6---
name: Client Link-Layer Address Option in DHCPv6
about: Add Client Link-Layer Address Option in DHCPv6
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? **not sur...---
name: Client Link-Layer Address Option in DHCPv6
about: Add Client Link-Layer Address Option in DHCPv6
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? **not sure**
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a **not sure**
good time to consider migration? **not sure**
- Are you sure what you would like to do is not possible using some other mechanisms? **not sure**
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists? **no**
**Is your feature request related to a problem? Please describe.**
I would like to see this feature in ISC-DHCP: https://tools.ietf.org/html/rfc6939
**Describe the solution you'd like**
See above
**Describe alternatives you've considered**
There is no real alternative right now, as far as I am aware.
**Additional context**
none
**Funding its development**
Sorry, I can't fund.
**Participating in development**
I would be willing to donate a PR, but my C skills are a little bit rusty and I would need some 'direction' where I need to add this feature. How complicated is this to add? The RFC seems pretty short.
**Contacting you**
christian.rebischke@avency.dehttps://gitlab.isc.org/isc-projects/bind9/-/issues/21979.16.6 exited with assertion failure after minor in-flight configuration change2022-01-25T16:56:10ZHåvard Eidnes9.16.6 exited with assertion failure after minor in-flight configuration change<!--
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
10s after a minor configuration change, BIND exited with an assertion failure.
After a restart, it has continued working as normal.
### BIND version used
```
BIND 9.16.6 (Stable Release) <id:25846cf>
running on NetBSD amd64 9.0_RC1 NetBSD 9.0_RC1 (GENERIC) #0: Sat Dec 14 12:36:33 UTC 2019 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--enable-dnstap' '--with-protobuf-c=/usr/pkg' '--with-libfstrm=/usr/pkg' '--sysconfdir=/etc' '--localstatedir=/var'
compiled by GCC 7.4.0
compiled with OpenSSL version: OpenSSL 1.1.1c 28 May 2019
linked to OpenSSL version: OpenSSL 1.1.1c 28 May 2019
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with zlib version: 1.2.10
linked to zlib version: 1.2.10
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
The configuration changes introduced were:
```
--- named.conf 2020/10/02 10:02:54 1.23
+++ named.conf 2020/10/02 10:06:18 1.24
@@ -1,7 +1,6 @@
options {
directory "/etc/namedb";
- dnssec-enable yes;
dnssec-validation yes;
managed-keys-directory "keys";
@@ -17,6 +16,10 @@
// minimization for now. May be related to forwarding...
//qname-minimization off;
+ // Be nice, conform to DNS flag day 2020
+ edns-udp-size 1232;
+ max-udp-size 1232;
+
// Force these in preparation for anycast addresses
// which we never want to use as query source
query-source address 158.37.2.68;
@@ -82,7 +85,7 @@
};
};
-managed-keys {
+trust-anchors {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
```
### What is the current *bug* behavior?
```
Oct 2 12:06:07 tos-res named[6701]: reloading configuration succeeded
Oct 2 12:06:07 tos-res named[6701]: scheduled loading new zones
Oct 2 12:06:07 tos-res named[6701]: any newly configured zones are now loaded
Oct 2 12:06:07 tos-res named[6701]: running
Oct 2 12:06:17 tos-res named[6701]: resolver.c:10193: INSIST(((res->dbuckets[i].list).head == ((void *)0))) failed, back trace
Oct 2 12:06:17 tos-res named[6701]: #0 0x434978 in assertion_failed()+0x4d
Oct 2 12:06:17 tos-res named[6701]: #1 0x5edd88 in isc_assertion_failed()+0xa
Oct 2 12:06:17 tos-res named[6701]: #2 0x550e33 in dns_resolver_detach()+0x501
Oct 2 12:06:17 tos-res named[6701]: #3 0x5896cf in destroy()+0x129
Oct 2 12:06:17 tos-res named[6701]: #4 0x58a427 in adb_shutdown()+0x52
Oct 2 12:06:17 tos-res named[6701]: #5 0x610f77 in run()+0x6b2
Oct 2 12:06:17 tos-res named[6701]: #6 0x72753c20c1d8 in _fini()+0x72753bbc5778
Oct 2 12:06:17 tos-res named[6701]: #7 0x72753bc87af0 in _fini()+0x72753b641090
Oct 2 12:06:17 tos-res named[6701]: exiting (due to assertion failure)
```
### What is the expected *correct* behavior?
BIND should have continued working as normal.
I don't know, it *may* be coincidental, but 10s is "too close for comfort".
Besides, that BIND continues working now after a full restart tends to indicate
that the problem was the in-flight configuration change and not the configuration
change itself.
### Relevant configuration files
`named-checkconf -px` output follows:
```
logging {
channel "normal" {
syslog "local2";
severity dynamic;
};
channel "trash" {
syslog "local3";
severity dynamic;
};
channel "security" {
syslog "local4";
severity dynamic;
};
channel "qerrs" {
syslog "local1";
severity dynamic;
};
channel "queries" {
syslog "local0";
severity dynamic;
};
channel "client_log" {
file "/var/log/client.log" versions 30 size 10485760;
severity dynamic;
print-time yes;
};
channel "rpzlog" {
file "/var/log/named.rpz" versions 50 size 10485760;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "null" {
null ;
};
category "default" {
"normal";
"default_debug";
};
category "general" {
"normal";
"default_debug";
};
category "config" {
"normal";
"default_debug";
};
category "network" {
"normal";
"default_debug";
};
category "notify" {
"normal";
"default_debug";
};
category "xfer-in" {
"normal";
"default_debug";
};
category "xfer-out" {
"normal";
"default_debug";
};
category "dnssec" {
"security";
};
category "security" {
"security";
};
category "rpz" {
"rpzlog";
};
category "database" {
"null";
};
category "lame-servers" {
"null";
};
category "update-security" {
"null";
};
category "update" {
"null";
};
category "query-errors" {
"qerrs";
};
category "queries" {
"queries";
};
category "client" {
"client_log";
};
};
options {
datasize 8589934592;
directory "/etc/namedb";
dnstap-output unix"/var/run/named/dnstap.sock";
hostname "tos-res.uninett.no";
listen-on {
"any";
};
listen-on-v6 {
"any";
};
managed-keys-directory "keys";
querylog no;
server-id "tos-res.uninett.no";
dnssec-validation yes;
dnstap {
client query;
};
edns-udp-size 1232;
max-udp-size 1232;
qname-minimization relaxed;
query-source address 158.37.2.68 port 0;
query-source-v6 address 2001:700:0:804f::ca53 port 0;
recursion yes;
response-policy {
zone "dns-rpz.uninett.no";
zone "zone3.ph.rpz.switch.ch" policy disabled;
zone "zone3.mw.rpz.switch.ch" policy disabled;
zone "zone3.misc.rpz.switch.ch" policy disabled;
} break-dnssec yes;
allow-query {
"localnets";
78.91.0.0/16;
128.39.0.0/16;
129.177.0.0/16;
129.240.0.0/15;
129.242.0.0/16;
144.164.0.0/16;
151.157.0.0/16;
152.94.0.0/16;
156.116.0.0/16;
157.249.0.0/16;
158.36.0.0/14;
161.4.0.0/16;
192.111.33.0/24;
192.133.32.0/24;
192.146.238.0/23;
193.156.0.0/15;
2001:700::/32;
146.172.4.0/23;
148.122.20.52/31;
148.123.37.165/32;
2001:67c:29f4::/48;
44.141.124.0/24;
44.141.132.0/24;
193.35.52.0/22;
};
forward first;
forwarders {
158.38.0.168;
128.39.2.24;
};
};
statistics-channels {
inet 127.0.0.1 port 8053 allow {
127.0.0.1/32;
};
inet 158.37.2.68 port 8053 allow {
158.38.62.0/23;
158.38.10.0/24;
};
};
server 54.209.136.173/32 {
send-cookie no;
};
server 204.153.45.2/32 {
send-cookie no;
};
trust-anchors {
"." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
"." initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
"7.4.nrenum.net" initial-key 257 3 8 "AwEAAdyLRICD7vMGdRG+uwF9176xm5u+E22zJehX7luBrY8LeUsw0aT9
WxBe2aKYSoBbAROVcuQJ/8EbbL+XhX5RKieRZFLDS1hQc+BpLY4Vse5G
2OeWYbH9lWEUM6/XErTsUikYfchXxWg6PkidN/howfNmo7iHDgeG/Xfz
E+i2MLZHCCnNND6v2DE8aP4qYzmU/jEc7n4814z2HR1dzpK/eXZwY3Tv
MjnTh3cqayi8b2B7+tedwV874plFOtMdTwywnMnXf1R3C3HBIZXHu55F
Ptd7cMbikW0lEc7BRRYL50knDMk7jcnsnA7MI1hOu3vI1cNAUWM+CmWX
DXShJKcLF0s=";
};
zone "." {
type hint;
file "root.cache";
};
zone "localhost" {
type master;
file "localhost";
};
zone "127.IN-ADDR.ARPA" {
type master;
file "127";
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "loopback.v6";
};
zone "dns-rpz.uninett.no" {
type slave;
file "sz/dns-rpz.uninett.no";
masters {
158.38.212.119;
};
};
zone "zone3.ph.rpz.switch.ch" {
type slave;
file "sz/zone3.ph.rpz.switch.ch";
masters {
158.38.212.119;
};
};
zone "zone3.mw.rpz.switch.ch" {
type slave;
file "sz/zone3.mw.rpz.switch.ch";
masters {
158.38.212.119;
};
};
zone "zone3.misc.rpz.switch.ch" {
type slave;
file "sz/zone3.misc.rpz.switch.ch";
masters {
158.38.212.119;
};
};
```
### Relevant logs and/or screenshots
See above.
### Possible fixes
Sorry, don't know.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/kea/-/issues/1447use thread_local to optimize access to thread context2021-10-20T11:53:14ZRazvan Becheriuuse thread_local to optimize access to thread contextmoved from
#1333 https://gitlab.isc.org/isc-projects/kea/-/merge_requests/917
and
#1333 https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/130moved from
#1333 https://gitlab.isc.org/isc-projects/kea/-/merge_requests/917
and
#1333 https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/130outstandingWlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1446Control the amount of certain attributes in RADIUS packets per RFCs 2865, 28662024-03-20T11:22:24ZAndrei Pavelandrei@isc.orgControl the amount of certain attributes in RADIUS packets per RFCs 2865, 2866Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1445Forensic logging should cover DECLINE and RELEASE2020-10-22T17:18:24ZTomek MrugalskiForensic logging should cover DECLINE and RELEASEIt was reported (see [support#17179](https://support.isc.org/Ticket/Display.html?id=17179)) that the forensic logging could handle the situation better when:
* client sends DECLINE
* client sends RELEASE
See patch attached in the suppo...It was reported (see [support#17179](https://support.isc.org/Ticket/Display.html?id=17179)) that the forensic logging could handle the situation better when:
* client sends DECLINE
* client sends RELEASE
See patch attached in the support ticket.kea1.9.1Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2195FreeBSD dnstap system test failure2021-02-23T14:20:11ZDiego dos Santos FronzaFreeBSD dnstap system test failurednstap system test on FreeBSD may fail due to an attempt in reading a not yet flushed dnstap file captured by fstrm_capture tool.dnstap system test on FreeBSD may fail due to an attempt in reading a not yet flushed dnstap file captured by fstrm_capture tool.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/kea/-/issues/1444LeaseX-update and leaseX-del cmds must be propaged to ha members2021-10-19T07:34:04Zmirackle-spbLeaseX-update and leaseX-del cmds must be propaged to ha members---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request ...---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request to primary is not enough. I need to send same request to stand-by member.
**Describe the solution you'd like**
Send update and del cmds to all ha members after completion on one node to maintain sync.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2194Occasional rndc crashes in tcp_connect_cb() on OpenBSD2020-12-09T09:53:30ZMichał KępieńOccasional rndc crashes in tcp_connect_cb() on OpenBSDEven with !4089 merged, we still seem to be getting occasional `rndc`
crashes on OpenBSD:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191900
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1181144
- https://gitlab.isc.o...Even with !4089 merged, we still seem to be getting occasional `rndc`
crashes on OpenBSD:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191900
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1181144
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1179956
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1176830
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1176824
While backtrace collection in GitLab CI is broken for OpenBSD[^1], the
core dumps themselves seem to be usable once you load them into GDB with
the right executables.
Here are some bits I personally found important:
```
(gdb) bt
#0 0x000005ee0feb049f in uv_handle_get_data () from /usr/local/lib/libuv.so.2.1
#1 0x000005ee6570b50e in tcp_connect_cb (uvreq=0x5edcf49e378, status=-48) at netmgr/tcp.c:156
#2 0x000005ee6570b408 in isc__nm_async_tcpconnect (ev0=Variable "ev0" is not available.
) at netmgr/tcp.c:136
#3 0x000005ee6570abbe in process_queue (worker=0x5edec985000, queue=0x5edec986080) at netmgr/netmgr.c:618
#4 0x000005ee0feb4548 in uv__async_io () from /usr/local/lib/libuv.so.2.1
#5 0x000005ee0fec59dc in uv__io_poll () from /usr/local/lib/libuv.so.2.1
#6 0x000005ee0feb4be0 in uv_run () from /usr/local/lib/libuv.so.2.1
#7 0x000005ee657077aa in nm_thread (worker0=0x5edec985000) at netmgr/netmgr.c:488
...
(gdb) frame 1
#1 0x000005ee6570b50e in tcp_connect_cb (uvreq=0x5edcf49e378, status=-48) at netmgr/tcp.c:156
156 sock = uv_handle_get_data((uv_handle_t *)uvreq->handle);
(gdb) print uvreq
$3 = (uv_connect_t *) 0x5edcf49e378
(gdb) print uvreq->handle
$4 = (uv_stream_t *) 0x0
```
Output of `thread apply all bt full` [attached][1] anyway.
[^1]: That is because source binary identification in GDB on OpenBSD
works differently than on all other systems and I see no obvious
way to make it work.
[1]: /uploads/0975475e2fc45e65d7c6b0a9d3c0bb8c/thread-apply-all-bt-full.txtDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1442investigate result of GTEST_SHUFFLE2020-11-18T12:42:03ZWlodzimierz Wencelinvestigate result of GTEST_SHUFFLEFix failing tests using seeds generated in the run:
https://jenkins.isc.org/job/kea-dev/job/ut-basic/52
* seed on fedora: 92727
* seed on debian: 24338
* seed on ubuntu: 11764
* seed on centos: 91424
to run tests with those seeds it's...Fix failing tests using seeds generated in the run:
https://jenkins.isc.org/job/kea-dev/job/ut-basic/52
* seed on fedora: 92727
* seed on debian: 24338
* seed on ubuntu: 11764
* seed on centos: 91424
to run tests with those seeds it's needed to have env variables `GTEST_SHUFFLE=1` and `GTEST_SHUFFLE_SEED` with SEED replaced by int.
This exercise is aimed to check if fixing those tests will resolve in fixing kea core code or just tests, if it will be just test code we will not enable GTEST_SHUFFLE in buildfarm.kea1.9.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1441RADIUS hook tweaks for Cisco hardware: optional different formatting of a par...2021-05-04T14:32:10ZTomek MrugalskiRADIUS hook tweaks for Cisco hardware: optional different formatting of a parameterThere's a [support#16875](https://support.isc.org/Ticket/Display.html?id=16875), asking for solution to the RADIUS problem with non-standard formatting for a parameter. In this deployment, a Cisco hardware is used as RADIUS server.
The ...There's a [support#16875](https://support.isc.org/Ticket/Display.html?id=16875), asking for solution to the RADIUS problem with non-standard formatting for a parameter. In this deployment, a Cisco hardware is used as RADIUS server.
The implementation expects the radius attribute conveying the MAC address to use a non-standard 0000.0000.0000, rather than the typical 00:00:00:00:00:00.
I haven't looked at the implementation, but it seems reasonable to provide an optional formatting knob that, when enabled, will use this alternative formatting. The default should remain as it is now.kea1.9.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2193TSAN errors in v9_16 to be investigated.2020-10-02T01:43:18ZMark AndrewsTSAN errors in v9_16 to be investigated.Job [#1192145](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1192145) failed for fc3cab22a44cff8458cf39865836c7e5d883cbed:
```
I:System test result summary:
I: 2 FAIL
I: 94 PASS
I: 3 SKIPPED
I:The following system tests...Job [#1192145](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1192145) failed for fc3cab22a44cff8458cf39865836c7e5d883cbed:
```
I:System test result summary:
I: 2 FAIL
I: 94 PASS
I: 3 SKIPPED
I:The following system tests failed:
I: nsupdate
I: tcp
I:ThreadSanitizer reported issues for the following system tests:
I: tcp
```
Races over access to `sock->rcb.recv` and `sock->rcbarg`. `sock->rcbarg` in this case.
`sock->rcbarg` is set to NULL before calling `isc_nm_stoplistening`. Additionally we
need to wait for isc_nm_stoplistening to be processed when it is sent via the event
queue.
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 processbuffer lib/isc/netmgr/tcpdns.c:185:15
#1 resume_processing lib/isc/netmgr/tcpdns.c:421:12
#2 isc_nmhandle_unref lib/isc/netmgr/netmgr.c:1173:4
#3 isc__nm_uvreq_put lib/isc/netmgr/netmgr.c:1288:3
#4 tcpdnssend_cb lib/isc/netmgr/tcpdns.c:449:2
#5 tcp_send_cb lib/isc/netmgr/tcp.c:892:2
#6 <null> <null>
Previous write of size 8 at 0x000000000001 by thread T2 (mutexes: write M1):
#0 memset <null>
#1 isc__nm_tcpdns_stoplistening lib/isc/netmgr/tcpdns.c:330:15
#2 isc_nm_stoplistening lib/isc/netmgr/netmgr.c:1358:3
#3 ns_interface_shutdown lib/ns/interfacemgr.c:564:3
#4 purge_old_interfaces lib/ns/interfacemgr.c:658:4
#5 ns_interfacemgr_shutdown lib/ns/interfacemgr.c:386:2
#6 shutdown_server bin/named/./server.c:9851:2
#7 dispatch lib/isc/task.c:1152:7
#8 run lib/isc/task.c:1344:2
```November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/kea/-/issues/1440wrap lines in ChangeLog to 732020-10-02T08:53:38ZMichal Nowikowskiwrap lines in ChangeLog to 73This is needed to make email with announcement look ok.This is needed to make email with announcement look ok.kea1.9.1https://gitlab.isc.org/isc-projects/bind9/-/issues/2192TSAN error accessing listener->connections2020-10-02T08:48:36ZMark AndrewsTSAN error accessing listener->connectionsJob [#1191892](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191892) failed for cdd9852447067a0ec4841ff3ffbd326ad03bb5a7:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 conn_reset b...Job [#1191892](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191892) failed for cdd9852447067a0ec4841ff3ffbd326ad03bb5a7:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 conn_reset bin/named/controlconf.c:574
#1 isc_nmhandle_detach netmgr/netmgr.c:1257
#2 isc__nm_uvreq_put netmgr/netmgr.c:1389
#3 tcp_send_cb netmgr/tcp.c:1030
#4 <null> <null>
#5 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2:
#0 conn_reset bin/named/controlconf.c:574
#1 isc_nmhandle_detach netmgr/netmgr.c:1257
#2 control_recvmessage bin/named/controlconf.c:556
#3 recv_data lib/isccc/ccmsg.c:110
#4 isc__nm_tcp_shutdown netmgr/tcp.c:1161
#5 shutdown_walk_cb netmgr/netmgr.c:1511
#6 uv_walk <null>
#7 process_queue netmgr/netmgr.c:656
#8 process_normal_queue netmgr/netmgr.c:582
#9 process_queues netmgr/netmgr.c:590
#10 async_cb netmgr/netmgr.c:548
#11 <null> <null>
#12 <null> <null>
Location is heap block of size 265 at 0x000000000017 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 isc___mem_get lib/isc/mem.c:1044
#4 isc__mem_get lib/isc/mem.c:2432
#5 add_listener bin/named/controlconf.c:1127
#6 named_controls_configure bin/named/controlconf.c:1324
#7 load_configuration bin/named/server.c:9181
#8 run_server bin/named/server.c:9819
#9 dispatch lib/isc/task.c:1152
#10 run lib/isc/task.c:1344
#11 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:232
#3 create_managers bin/named/main.c:909
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:232
#3 create_managers bin/named/main.c:909
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
SUMMARY: ThreadSanitizer: data race bin/named/controlconf.c:574 in conn_reset
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2191Missing locks when accessing keynode.initial and keynode.managed triggered TSAN.2020-10-02T08:49:12ZMark AndrewsMissing locks when accessing keynode.initial and keynode.managed triggered TSAN.Job [#1190729](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1190729) failed for 96d2ec16a29c73050f8ad7a97930093294ba9ac7:
```
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by thread T1 (mutexes: write M1):...Job [#1190729](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1190729) failed for 96d2ec16a29c73050f8ad7a97930093294ba9ac7:
```
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by thread T1 (mutexes: write M1):
#0 dns_keynode_trust lib/dns/keytable.c:836
#1 keyfetch_done lib/dns/zone.c:10187
#2 dispatch lib/isc/task.c:1152
#3 run lib/isc/task.c:1344
#4 <null> <null>
Previous read of size 1 at 0x000000000001 by thread T2 (mutexes: read M2):
#0 keynode_dslist_totext lib/dns/keytable.c:682
#1 dns_keytable_totext lib/dns/keytable.c:732
#2 named_server_dumpsecroots bin/named/server.c:11357
#3 named_control_docommand bin/named/control.c:264
#4 control_command bin/named/controlconf.c:390
#5 dispatch lib/isc/task.c:1152
#6 run lib/isc/task.c:1344
#7 <null> <null>
Location is heap block of size 241 at 0x000000000010 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 mem_allocateunlocked lib/isc/mem.c:1268
#4 isc___mem_allocate lib/isc/mem.c:1288
#5 isc__mem_allocate lib/isc/mem.c:2453
#6 isc___mem_get lib/isc/mem.c:1037
#7 isc__mem_get lib/isc/mem.c:2432
#8 new_keynode lib/dns/keytable.c:346
#9 insert lib/dns/keytable.c:393
#10 dns_keytable_add lib/dns/keytable.c:421
#11 process_key bin/named/server.c:955
#12 load_view_keys bin/named/server.c:983
#13 configure_view_dnsseckeys bin/named/server.c:1140
#14 configure_view bin/named/server.c:5371
#15 load_configuration bin/named/server.c:9110
#16 loadconfig bin/named/server.c:10310
#17 named_server_reconfigcommand bin/named/server.c:10693
#18 named_control_docommand bin/named/control.c:250
#19 control_command bin/named/controlconf.c:390
#20 dispatch lib/isc/task.c:1152
#21 run lib/isc/task.c:1344
#22 <null> <null>
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
SUMMARY: ThreadSanitizer: data race lib/dns/keytable.c:836 in dns_keynode_trust
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1439Sanity checks for Kea 1.9.0 rc12020-10-02T12:03:54ZjenkinsSanity checks for Kea 1.9.0 rc1```We are now at step SANITY CHECKS of Kea 1.9.0 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.0 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.0-rc1
/data/shared/sweng/kea/releases/premium-1.9.0-rc1
/data/shared/sweng/kea/releases/subscription-1.9.0-rc1
SHA256 (kea-1.9.0.tar.gz) = 054e66b9cd987a43d2745abd7c850d4ffb532e611da1c8b13f23ccbb4a71f8e0)
SHA256 (kea-premium-1.9.0.tar.gz) = f4b5e36a5936727e15c1566d6a2f08d3d9c1b5eb8a8a3c0e348f9b280b5dc397)
SHA256 (kea-subscription-1.9.0.tar.gz) = 535a4177d9c227efa7c7b0f3af759fff7947ae6499885fcd9ec72e62656aeb3f)
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.isc.org/job/kea-dev/job/pkg/64/
Release version is 1.9.0-isc0003520200928143245 (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.
```