ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-02-27T23:14:25Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1638RRSIG(SOA) and re-signing.2020-02-27T23:14:25ZMark AndrewsRRSIG(SOA) and re-signing.The RRSIG(SOA) should always use the full sig-validity-interval as its presence is used to signal that incremental signing has fully signed the zone.
Sort RRSIG(SOA) to the be the last RRset returned by dns_db_getsigningtime() when ther...The RRSIG(SOA) should always use the full sig-validity-interval as its presence is used to signal that incremental signing has fully signed the zone.
Sort RRSIG(SOA) to the be the last RRset returned by dns_db_getsigningtime() when there are multiple RRsets with the same timestamp.https://gitlab.isc.org/isc-projects/stork/-/issues/172Use the new subnet data model in REST API2020-02-28T16:55:09ZMarcin SiodelskiUse the new subnet data model in REST APIThis is a followup work to #165. There are two major changes required:
- When an app is added to the database we need to parse its configuration and detect the subnets it belongs to. Those subnets have to be stored in the database.
- The...This is a followup work to #165. There are two major changes required:
- When an app is added to the database we need to parse its configuration and detect the subnets it belongs to. Those subnets have to be stored in the database.
- The REST API has to be modified to return the new subnet and shared network instances.0.5https://gitlab.isc.org/isc-projects/bind9/-/issues/1637unable to create dispatch for reserved port <ip>#53: permission denied2020-09-14T13:52:58ZMathieu Arnoldunable to create dispatch for reserved port <ip>#53: permission denied### Summary
A lot of those lines are logged when named starts.
### BIND version used
```
BIND 9.16.0 (Stable Release) <id:6270e60>
running on FreeBSD amd64 11.3-RELEASE-p5 FreeBSD 11.3-RELEASE-p5 #0: Tue Nov 12 08:59:04 UTC 2019 r...### Summary
A lot of those lines are logged when named starts.
### BIND version used
```
BIND 9.16.0 (Stable Release) <id:6270e60>
running on FreeBSD amd64 11.3-RELEASE-p5 FreeBSD 11.3-RELEASE-p5 #0: Tue Nov 12 08:59:04 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--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-freebsd11.3' 'build_alias=amd64-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -Wl,-rpath,/usr/local/lib -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 8.0.0 (tags/RELEASE_800/final 356365)
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-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
Start named?
### What is the current *bug* behavior?
When named starts, those lines are printed:
```
Feb 24 16:05:03 ns1 named[58048]: unable to create dispatch for reserved port 79.143.243.129#53: permission denied
Feb 24 16:05:03 ns1 named[58048]: unable to create dispatch for reserved port 2a01:678:2:100::53#53: permission denied
```
A lot.
```
# grep 'unable to create dispatch for reserved port' /var/log/named.log|grep 'Feb 24 16:05'|wc
5330 79950 623610
```
### What is the expected *correct* behavior?
Well, maybe a bit less.
### Relevant configuration files
```
acl "friends" {
127.0.0.1/32;
::1/128;
79.143.243.129/32;
key "yop";
key "oups";
key "ouinch";
key "ns1-gw.in";
key "ns1-gw.mat";
217.70.177.40/32;
82.66.245.111/32;
62.212.120.194/32;
82.229.45.53/32;
217.128.128.42/32;
79.143.243.135/32;
79.143.243.150/32;
79.143.241.142/32;
};
acl "nsabso" {
217.174.201.32/28;
79.143.243.129/32;
83.169.77.112/28;
80.245.57.152/32;
185.167.19.240/28;
};
acl "blocs" {
79.143.240.0/20;
2a01:678::/29;
};
controls {
inet 127.0.0.1 port 953 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
inet 79.143.243.129 port 953 allow {
"nsabso";
} keys {
"nsabso";
};
};
logging {
channel "dnssec-log" {
file "/var/log/dnssec.log" versions 4 size 10485760;
severity debug 3;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"default_syslog";
};
category "dnssec" {
"dnssec-log";
};
category "queries" {
"null";
};
};
options {
directory "/usr/local/etc/namedb";
dump-file "/var/dump/named_dump.db";
listen-on {
79.143.243.129/32;
127.0.0.1/32;
};
listen-on-v6 {
2a01:678:2:100::53/128;
2a01:678:2:100::2:53/128;
::1/128;
};
managed-keys-directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
recursing-file "/var/stats/named.recurse";
statistics-file "/var/stats/named.stats";
transfers-in 100;
transfers-out 2000;
transfers-per-ns 10;
allow-recursion {
127.0.0.1/32;
};
dnssec-enable yes;
query-source address 79.143.243.129 port 0;
rate-limit {
exempt-clients {
"blocs";
"friends";
};
responses-per-second 10;
window 30;
};
allow-query {
"any";
};
allow-transfer {
"friends";
};
masterfile-format text;
notify yes;
notify-source 79.143.243.129 port 53;
notify-source-v6 2a01:678:2:100::53 port 53;
transfer-source 79.143.243.129;
transfer-source-v6 2a01:678:2:100::53;
};
key "rndc-key" {
algorithm "hmac-md5";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
key "nsabso" {
algorithm "hmac-md5";
secret "????????????????????????";
};
key "yop" {
algorithm "hmac-sha256";
secret "????????????????????????";
};
key "oups" {
algorithm "hmac-sha256";
secret "????????????????????????";
};
key "ouinch" {
algorithm "hmac-sha256";
secret "????????????????????????";
};
trust-anchors {
"." initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
zone "." {
type hint;
file "named.root";
};
```https://gitlab.isc.org/isc-projects/kea/-/issues/1127sanity checks 1.6.22020-05-15T18:23:27ZWlodzimierz Wencelsanity checks 1.6.2```
repo.isc.org data/shared/sweng/kea/releases/1.6.2-rc2/
SHA256 (1.6.2-rc2/kea-1.6.2.tar.gz) = 2af7336027143c3e98d8d1d44165b2c2cbb0252a92bd88f6dd4d2c6adb69d7b5
SHA256 (subscription-1.6.2-rc2/kea-subscription-1.6.2.tar.gz) = c185080e7c...```
repo.isc.org data/shared/sweng/kea/releases/1.6.2-rc2/
SHA256 (1.6.2-rc2/kea-1.6.2.tar.gz) = 2af7336027143c3e98d8d1d44165b2c2cbb0252a92bd88f6dd4d2c6adb69d7b5
SHA256 (subscription-1.6.2-rc2/kea-subscription-1.6.2.tar.gz) = c185080e7c6724a73bb880c6a99a167c6cea679f2b6ceaf8186666eec4992a26
SHA256 (premium-1.6.2-rc2/kea-premium-1.6.2.tar.gz) = d8e6f7c9b09820bd3571449c7ccad0dd8d01b0572e5362d199b4b213474b95e4
SHA256 (1.6.2-rc2/doc/html) = c80d92caa2259d9df5cb4f3287800e919c9aa1e294d2b86d9739b9cc5dba57fb
SHA256 (1.6.2-rc2/doc/kea-arm.pdf) = d80c381e77664a491a2c41916c3412fd2c1b1e02c60e397e480cbfdbba5ffc0a
SHA256 (1.6.2-rc2/doc/kea-messages.pdf) = f0cbe024f08d97498403f35a6c7e824a1ab3e45189fe0b8c1c06a47d0bf7eeb6
deb/rpm are available on nexus with version: 1.6.2-isc0043420200221140216
list of all packages you can find here: https://jenkins.isc.org/job/kea-1.6/job/pkg/357/
```kea1.6.2https://gitlab.isc.org/isc-projects/bind9/-/issues/1635xml2-config is dead, long live pkg-config2020-03-03T14:25:50ZOndřej Surýxml2-config is dead, long live pkg-configThe Debian unstable builds are failing with:
```
checking for libxml2 library... configure: error: xml2-config returns badness
cd build && tail -v -n \+0 config.log
```
and while in fact it's an error, the `xml2-config` is going to be ...The Debian unstable builds are failing with:
```
checking for libxml2 library... configure: error: xml2-config returns badness
cd build && tail -v -n \+0 config.log
```
and while in fact it's an error, the `xml2-config` is going to be obsoleted soon, and we should try using `pkg-config` to find libxml2 first.March 2020 (9.11.17, 9.16.1, 9.17.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1126Lease pre-allocation design2023-03-27T14:06:19ZTomek MrugalskiLease pre-allocation designIt's been brought to our attention (see [support #15984](https://support.isc.org/Ticket/Display.html?id=15984)) that the well known deficiency of Kea running with pool utilization close to 100% has drastically degraded performance.
We h...It's been brought to our attention (see [support #15984](https://support.isc.org/Ticket/Display.html?id=15984)) that the well known deficiency of Kea running with pool utilization close to 100% has drastically degraded performance.
We have plenty of [performance improvement ideas](https://gitlab.isc.org/isc-projects/kea/-/wikis/performance1.7), but given the situation, we believe the pre-allocation concept will be the most useful to mitigate the poor performance at high pool utilization scenario.kea2.3.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1124Alter order of HR and lease lookup in allocation engine when looking for a fr...2020-07-16T13:28:11ZThomas MarkwalderAlter order of HR and lease lookup in allocation engine when looking for a free leaseCurrently when the allocation engine is looking for lease candidates it does this:
1. pickAddress
2. check address for HR
3. check address for existing lease
This can be expensive, particularly when HRs are in the a DB and leases are ...Currently when the allocation engine is looking for lease candidates it does this:
1. pickAddress
2. check address for HR
3. check address for existing lease
This can be expensive, particularly when HRs are in the a DB and leases are in memfile (arguably the most common use case). Once pools get full, we end up doing lots of HR lookups only to discover there is already a lease. If we decide in the other order, we at least have the ability to not waste cycles looking at HRs when there is already an existing lease.
It has been suggested, that we could tune this logic based on which might be more optimal:
HR Db / Memfile -> check lease then HR
HR local / Memfile -> check lease then HR (one could argue either case)
HR local / Lease DB -> check HR then lease
I'm skeptical that it would make a big difference. It matters almost as the ratio between address HRs to leases.
For the initial implementation, I am going to simply swap the order.
The impetus for this work is the following support ticket:
https://support.isc.org/Ticket/Display.html?id=15984
kea1.7.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/stork/-/issues/171UI tweak: pagination/total entries layout should be unified2020-04-20T09:44:05ZTomek MrugalskiUI tweak: pagination/total entries layout should be unifiedA minor UI usability improvement.
When viewing Kea services, BIND services or Machines, the bar with X of Y pages/show Z per page line is above the content. The subnets and networks views has it below the content. This should be unified...A minor UI usability improvement.
When viewing Kea services, BIND services or Machines, the bar with X of Y pages/show Z per page line is above the content. The subnets and networks views has it below the content. This should be unified.
I think the standard is to keep it at the bottom.0.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1123Eliminate exhausted pools from allocation attempts2020-02-27T16:26:54ZMarcin SiodelskiEliminate exhausted pools from allocation attemptsOur iterative address allocator in the allocation engine iterates over all addresses within a pool and tries if they are available one by one. That is very expensive when we get to the case of the nearly exhausted or completely exhausted...Our iterative address allocator in the allocation engine iterates over all addresses within a pool and tries if they are available one by one. That is very expensive when we get to the case of the nearly exhausted or completely exhausted pool. There are many different ideas how to improve the performance of free lease lookup, but many of them involve significant changes to the code.
I would like to propose a simple solution on our way towards more and more sophisticated allocation strategies.
The core idea is to add a new API call to the lease manager:
```
uint64_t getValidLeasesCount(IOAddress lower_bound, IOAdress upper_bound) const;
```
which would return the number of allocated leases (excluding expired) ones in that address range. This could be initially only implemented for Memfile and later for other backends. The backends for which it is not supported could always return 0.
The `IterativeAllocator` within the allocation engine could make use of this call for each pool it considers for allocation. It should call this function to see how many addresses are allocated in that pool and compare that with the pool size. If they are equal, the allocator gives up on this pool for this particular allocation. If it goes over all pools and all of them are exhausted it returns `zero IP address` to indicate to the calling code that it was unable to find an address. That would cause the allocation engine to drop the discover. There would be a lot less of useless trying.
The downside of this solution is that it adds extra query. This maybe specifically a concern in case when SQL database is in use for leases and the pools utilization is low. In those cases I'd recommend to add the following enhancement....
Extend the Pool with a new member:
```
uint64_t predicted_exhaustion_;
```
which would hold the value of
```
pool_size - getValidLeasesCount(a, b);
```
and would be decreased every time the new allocation takes place. The call to `getValidLeasesCount()` would only be made when this value hits 0. In some cases there may be other things impacting pool utilization, e.g. expired leases processing. In those cases would set this value straight to 0 to force an update.
For the starters I'd implement always checking the pool utilization without such adaptive mechanism, especially if doing it for memfile only.kea1.7.5https://gitlab.isc.org/isc-projects/bind9/-/issues/1631kasp system test failed (bad number of keys)2022-04-28T19:13:15ZMichał Kępieńkasp system test failed (bad number of keys)https://gitlab.isc.org/isc-projects/bind9/-/jobs/700050
```
I:kasp:check number of keys with algorithm 5 for zone legacy-keys.kasp in dir ns3 (56)
I:kasp:error: bad number (2) of key files for zone legacy-keys.kasp (expected 3)
I:kasp:f...https://gitlab.isc.org/isc-projects/bind9/-/jobs/700050
```
I:kasp:check number of keys with algorithm 5 for zone legacy-keys.kasp in dir ns3 (56)
I:kasp:error: bad number (2) of key files for zone legacy-keys.kasp (expected 3)
I:kasp:failed
I:kasp:check key 24906
I:kasp:check key 38941
I:kasp:error: No KEY2 found for zone legacy-keys.kasp
I:kasp:failed
I:kasp:check DNSKEY rrset is signed correctly for zone legacy-keys.kasp (57)
I:kasp:check SOA rrset is signed correctly for zone legacy-keys.kasp (58)
I:kasp:error: SOA RRset not signed with key no
I:kasp:failed
I:kasp:check CDS and CDNSKEY rrset are signed correctly for zone legacy-keys.kasp (59)
I:kasp:check A a.legacy-keys.kasp rrset is signed correctly for zone legacy-keys.kasp (60)
I:kasp:error: A RRset not signed with key no
I:kasp:failed
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/stork/-/issues/170App can have multiple access points2020-03-10T15:54:17ZMatthijs Mekkingmatthijs@isc.orgApp can have multiple access pointsFor example, BIND9 can be accessed with `rndc` to control the daemon, or via the statistics-channel to get metrics.
Change the stork code such that multiple access points are allowed.For example, BIND9 can be accessed with `rndc` to control the daemon, or via the statistics-channel to get metrics.
Change the stork code such that multiple access points are allowed.0.6Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1629contrib/dlz/modules/filesystem no longer builds 9.16.02020-02-25T00:52:36ZMark Andrewscontrib/dlz/modules/filesystem no longer builds 9.16.0clang-format reordered the includes causing isc_result_t to not be typedef'd early enough.clang-format reordered the includes causing isc_result_t to not be typedef'd early enough.https://gitlab.isc.org/isc-projects/bind9/-/issues/1628Release process failed to detect that header file was not installed.2020-03-06T01:12:25ZMark AndrewsRelease process failed to detect that header file was not installed.9.15.8 failed to install isc/netmgr.h
My sanity check script had this post install check and a similar one for a install from a out-of-tree build
to detect .h files that where not installed.
```
for f in `find $i/lib -name \*.h | gre...9.15.8 failed to install isc/netmgr.h
My sanity check script had this post install check and a similar one for a install from a out-of-tree build
to detect .h files that where not installed.
```
for f in `find $i/lib -name \*.h | grep -v win32 | grep -v include/tests/t_api.h | grep -v include/isc/ipv6.h | sed -n 's;.*include/;'"${i}-test-install"'/usr/local/include/;p'`
do
case $i in
bind-9.[89]*)
expr "$f" : '^.*/include/irs/.*\.h$' > /dev/null && continue
;;
esac
test -f $f || echo missing $f
done
```March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/stork/-/issues/169add storing and getting settings in database2020-03-13T17:49:26ZMichal Nowikowskiadd storing and getting settings in databaseref:
- https://gitlab.isc.org/isc-projects/stork/merge_requests/76#note_110969
- https://gitlab.isc.org/isc-projects/stork/-/wikis/Designs/Settings-in-Databaseref:
- https://gitlab.isc.org/isc-projects/stork/merge_requests/76#note_110969
- https://gitlab.isc.org/isc-projects/stork/-/wikis/Designs/Settings-in-Database0.6https://gitlab.isc.org/isc-projects/stork/-/issues/168add stats for collecting and storing lease stats2020-02-25T16:57:58ZMichal Nowikowskiadd stats for collecting and storing lease statsre: https://gitlab.isc.org/isc-projects/stork/merge_requests/76#note_110953re: https://gitlab.isc.org/isc-projects/stork/merge_requests/76#note_1109530.5https://gitlab.isc.org/isc-projects/kea/-/issues/11221.6.2 sanity checks2020-02-21T07:56:10ZWlodzimierz Wencel1.6.2 sanity checks```
@repo.isc.org /data/shared/sweng/kea/releases
SHA256 (1.6.2-rc1/kea-1.6.2.tar.gz) = d55802a117392a0ff42b2507de922598ed08e5ed08fa35cad260c76122360b80
SHA256 (subscription-1.6.2-rc1/kea-subscription-1.6.2.tar.gz) = 62f3ea5ee2af6b5c20a1...```
@repo.isc.org /data/shared/sweng/kea/releases
SHA256 (1.6.2-rc1/kea-1.6.2.tar.gz) = d55802a117392a0ff42b2507de922598ed08e5ed08fa35cad260c76122360b80
SHA256 (subscription-1.6.2-rc1/kea-subscription-1.6.2.tar.gz) = 62f3ea5ee2af6b5c20a11f9a4a57b70b9fa15514a6d5df5aec8f2543e1f32441
SHA256 (premium-1.6.2-rc1/kea-premium-1.6.2.tar.gz) = 046522f4f6800bc39307794a32759df452d9647b91a5963027ffe7c27f599784
SHA256 (1.6.2-rc1/doc/html) = e80fe1577a1e00e9659d5637cc3f0c42a8221f170fa7a77b4c804e48352754d0
SHA256 (1.6.2-rc1/doc/kea-arm.pdf) = f4da5af47eb77422e0938ce5e9d6c22e5d63c50ec4158ee7d02b37e4332f48ec
SHA256 (1.6.2-rc1/doc/kea-messages.pdf) = 3a6eb0d7db320f3bb0940a68b1cd8ad56a88cb175ccaa2c96d5038656140e52c
```kea1.6.2https://gitlab.isc.org/isc-projects/bind9/-/issues/1626Algorithm rollover is stuck on publishing DS2020-03-09T13:43:21ZMatthijs Mekkingmatthijs@isc.orgAlgorithm rollover is stuck on publishing DSThe keymgr logic prevents to introduce the DS record (move it to RUMOURED state) because it thinks that will move DNSSEC into an invalid state.The keymgr logic prevents to introduce the DS record (move it to RUMOURED state) because it thinks that will move DNSSEC into an invalid state.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1625Algorithm rollover takes too long to introduce2020-03-09T13:43:20ZMatthijs Mekkingmatthijs@isc.orgAlgorithm rollover takes too long to introduceAlgorithm rollover takes too long (but luckily not too short) because when introducing new zone signatures the time to wait before the signatures are omnipresent includes the sign delay. This is the delay that ensures all zone signature...Algorithm rollover takes too long (but luckily not too short) because when introducing new zone signatures the time to wait before the signatures are omnipresent includes the sign delay. This is the delay that ensures all zone signatures have been refreshed. Thus publishing the DS record is delayed. Since there is no predecessor key with the same algorithm, all signatures need to be resigned anyway and adding the sign delay is unnecessary.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1624dnssec-policy change does not retire keys2020-03-09T13:43:21ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy change does not retire keysWhen changing a policy for a zone (for example to perform an algorithm rollover), existing keys with no longer matching properties (for example that now have the wrong algorithm) are not being retired, thus are being kept in the zone and...When changing a policy for a zone (for example to perform an algorithm rollover), existing keys with no longer matching properties (for example that now have the wrong algorithm) are not being retired, thus are being kept in the zone and maintain active.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1623Assertion failure in ns_client_endrequest when shutting down2020-02-27T07:55:40ZWitold KrecickiAssertion failure in ns_client_endrequest when shutting downScenario:
1. We are shutting down, interface->clientmgr is gone
2. We receive a packet, it gets through ns__client_request
3. mgr == NULL, return
4. isc_nmhandle_detach calls ns_client_reset_cb
5. ns_client_reset_cb calls ns_client_endr...Scenario:
1. We are shutting down, interface->clientmgr is gone
2. We receive a packet, it gets through ns__client_request
3. mgr == NULL, return
4. isc_nmhandle_detach calls ns_client_reset_cb
5. ns_client_reset_cb calls ns_client_endrequest
6. INSIST(client->state == NS_CLIENTSTATE_WORKING || client->state == NS_CLIENTSTATE_RECURSING) is not met - we haven't started processing this packet so client->state == NS_CLIENTSTATE_READY.
Solution - don't call ns_client_endrequest if client->state == NS_CLIENTSTATE_READYMarch 2020 (9.11.17, 9.16.1, 9.17.0)Witold KrecickiWitold Krecicki