BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-12-22T10:28:30Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/15Modules and hooks2023-12-22T10:28:30ZOndřej SurýModules and hooksAdd support for externally loaded modules to hook into query-response processing.
Requirements
============
* Implement an pluggable interface to add a module that would access and possibly modify the query-response processing
* The mod...Add support for externally loaded modules to hook into query-response processing.
Requirements
============
* Implement an pluggable interface to add a module that would access and possibly modify the query-response processing
* The modules would be using versioned API
* The modules could be dynamically loaded or statically compiled in
* Only C modules would be supported in 1st phase
* More programming languages could be added later (Rust, Go, Lua)
* There would be a multiple entry points as the query-response gets processed by BIND
* Before reading any data from the socket
* After reading DNS message from the socket
* Before entering view
* After entering view
* Before ACL
* After ACL
* (Authoritative) Before reading the zone data
* (Authoritative) After reading the zone data
* (Recursive) Before sending each recursive query
* (Recursive) After receiving each recursive query
* Before sending a reply to a socket
* After sending a reply to a socket
* Before stats are produced (finalized?)
* On module load
* On module unload
* RNDC should probably also include multiple entry points, so module can add new commands, extend/modify existing command, and/or modify the processing of existing commands.
* The module should have access to most context data related to query, parent query, subqueries, answer and internal state
* The module should be able to specify its entry points from within the module
* The module should be able to specify module dependencies and load order for each entry point
* It must be possible to load multiple instances of a single module
Technical Specification
=======================
* Plugin API will be specified, there are number of other projects that utilize loadable dynamic and/or static plugins
* Apache
* Kea
* PHP
* SASL
* The API needs to use opaque pointers and the API should be kept as stable as possible
* ...
Sample Configuration Syntax
===========================
```
acl exempt { 10.53.0.7; };
options {
directory "/etc/bind";
recursion yes;
dnssec-validation auto;
};
hooks {
path "/usr/local/lib:/etc/hooks:";
query rebound.so; // no options; use default settings
query filter-aaaa.so {
filter-on-v4 yes;
filter-on-v6 no;
};
query rpz.so {
response-policy {
zone "policy1"; // note this is defined outside the hooks block
zone "policy2";
} qname-wait-recurse no
nsdname-enable yes
nsip-enable yes;
};
};
query rrl.so {
responses-per-second 10;
all-per-second 50;
slip 3;
exempt-clients {
exempt; // note this is defined outside the hooks block
};
};
};
zone policy1 {
type master;
file "policy1.db";
};
zone policy2 {
type slave;
masters { 10.53.0.1; };
file "policy2.db";
};
```
Notes on Configuration
======================
* Initially, hook modules will probably be limited to query processing, but there could also be hooks, for example, for update, notify, or xfr. This is why "query" is specified for each hook module above. This is probably not strictly necessary - the names of the modules should be sufficient to disambiguate them - but it may be necessary for query modules to be initialized differently from update modules. It should in any case help with readability for the user.
* Just as with `zone`, a `hooks` block can be at the top level of `named.conf` or it can be under `view`. A server with multiple views cannot have a global-level `hooks` block.
* The configuration options are passed to hooks as bracketed_text (same as with `dyndb` and `dnsrps`). The hook module itself will parse the options. This means the `named` parser doesn't have to understand the module's configuration syntax. A pointer to the parser context must be provided to the module at initialization time so it can reference names that are defined elsewhere (such as the `exempt` ACL in the above sample).
* Hook modules will need to share an address space with `named` and be initialized with pointers to the view, zone table, server context, etc.
* Hook modules will specify their own entry/callback points. In other words, it would not be necessary for the user to specify that filter-aaaa taps in at the "pre-response" entry point; it can do that by itself.
* If more than one hook uses the same entry/callback point, the order in which they are listed in `hooks` sets priority. (In the above example, rebound would precede filter-aaaa.) We can add syntax to override default priorities for certain entry points if that turns out to be necessary.
BIND-9.13.6Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4Convert to modern autotools (autoconf + automake + libtool)2024-01-03T14:09:49ZOndřej SurýConvert to modern autotools (autoconf + automake + libtool)The current build system doesn't use automake. It would be much easier to maintain the build system if we use full autotools capabilities.
Also reducing the number of Makefiles scattered in subdirectories into just few would help with ...The current build system doesn't use automake. It would be much easier to maintain the build system if we use full autotools capabilities.
Also reducing the number of Makefiles scattered in subdirectories into just few would help with dependency graph and parallel builds.
Outstanding issues:
- Critical
- [x] #1720 Building documentation is broken with Automake
- [x] #1724 Revise installation locations for certain BIND binaries
- [x] #1769 Ensure all necessary files are included in the tarball produced by "make dist"
- [x] #1774 Get Windows builds working again
- [x] #1777 Update the build instructions for automake
- [x] #1780 Fix system tests failing with Automake
- [x] #1783 AX_CHECK_COMPILE_FLAG -fno-delete-null-pointer-checks does not fail for clang
- Important
- [x] #114 Out of tree system tests
- [x] #1722 Ensure unit test core dumps are collected for Automake builds
- [x] #1725 Ensure correct use of lib/ns/tests/wrap.c
- [x] #1738 Revise the contents of "./configure" summary
- [ ] #1771 Refactor how we load librpz.so
- [x] #1787 BIND (master) does not work with krb5 1.18 (NegoEx)
- [x] #1792 Convert the checks from testsummary.sh into log driver (run.sh)
- [x] #1867 Fix the system tests on Windows
- [ ] #1880 Fix "make distcheck"
- Minor
- [ ] #1773 Consider including all compile flags in "named -V" output
- Cleanups
- [x] #48 Drop $SYSTEMTESTTOP from bin/tests/system/
- [x] #1726 Unit tests: rename TESTS to something more descriptive
- [x] #1727 Drop use of "$FEATURETEST --have-dlopen"
- [ ] #1729 Remove unused helper scripts from bin/tests/system/
- [x] #1730 Clean up no-op AC_SUBST calls
- [ ] #1731 Sort Automake files nicely
- [x] #1770 Review how we use sys/un.h
- [x] #1778 Cleanup the final remnants of platform.h
- [x] #1913 Remove unused leftoversMay 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4650dnssec-validation locks up server with 9.19.222024-03-26T21:39:49ZKlemen Mihevcdnssec-validation locks up server with 9.19.22Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [x] Search the existing issues in GitLab (both open and closed) to see if your report m...Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [x] Search the existing issues in GitLab (both open and closed) to see if your report might be a duplicate. We have a large database here and many issues have already been fixed in the latest versions!
- [x] Make sure this is **not** a support question. If you have specific trouble configuring or debugging your setup, please use the bind-users mailing list: https://lists.isc.org/mailman/listinfo/bind-users
- [x] You have read and understood the "out in the open" support policy: https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ . Even though it was written by the PowerDNS folks, we follow it as well!
Before continuing, **please select the appropriate issue template in the drop-down menu above, under the heading _Description_**.
i tried to use dnssec-validation (auto) with 9.19.22 and it makes server unresponsive. This didnt happen in 9.19.21. What happens is usually in first half an hour server starts to become unresponsive(LITTERALLY STUCK, need to kill -9) and cpu load rockets sky high without a reason (most i saw was 45% before i killed process manualy). This is not some high usage dns server, it serves for home domain and recursion on home network. There is nothing in the logs even with debug severity... Hopefully you can give me guidance how to help you resolve this issuehttps://gitlab.isc.org/isc-projects/bind9/-/issues/4509In bind9.18.16, the rpz file is too large to block.2023-12-29T05:15:58ZBei ChenIn bind9.18.16, the rpz file is too large to block.In bind9.18.16, when there are many domain names in the rpz.zone file, some domain names cannot be bocked and can be resolved normally.[chroot.tar__4_.gz](/uploads/0e48e44a43985b56bce76d31337a7921/chroot.tar__4_.gz)
The configuration fil...In bind9.18.16, when there are many domain names in the rpz.zone file, some domain names cannot be bocked and can be resolved normally.[chroot.tar__4_.gz](/uploads/0e48e44a43985b56bce76d31337a7921/chroot.tar__4_.gz)
The configuration file is attached. Run the command "./sbin/named -u named -c /etc/named.conf -t./chroot/named/" to run bind9.18.16.
For example, there is an intercepted domain name "www.f2pool.com" in my rpz file, which can be resolved normally when I try to access it. This is not normal, it should be able to intercept and return to the NXDOMAIN.
This is my problem,thank you.https://gitlab.isc.org/isc-projects/bind9/-/issues/4447Disallow stale-answer-client-timeout non-zero2024-03-08T08:37:23ZMatthijs Mekkingmatthijs@isc.orgDisallow stale-answer-client-timeout non-zeroOur serve-stale customers don't use `stale-answer-client-timeout` with a non-zero value. Since this is the configuration that is giving us the most issues, perhaps we should deprecate/disallow it and only allow value `0` (or `off`).Our serve-stale customers don't use `stale-answer-client-timeout` with a non-zero value. Since this is the configuration that is giving us the most issues, perhaps we should deprecate/disallow it and only allow value `0` (or `off`).March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4317The primary server does not send notify information2023-09-14T09:10:44Zliangzyeu liangzeThe primary server does not send notify information<!--
My primary bind server needed to synchronize 13 zone files to 3 secondary servers, but 1-2 zone synchronization was missed each time. I found through logs that the primary bind did not send notify information to the secondary server...<!--
My primary bind server needed to synchronize 13 zone files to 3 secondary servers, but 1-2 zone synchronization was missed each time. I found through logs that the primary bind did not send notify information to the secondary server. But one solution I have is to execute rndc reload twice every time you modify the zone file to synchronize it all. What's the problem?
-->
### Summary
My primary bind server needed to synchronize 13 zone files to 3 secondary servers, but 1-2 zone synchronization was missed each time. I found through logs that the primary bind did not send notify information to the secondary server. But one solution I have is to execute rndc reload twice every time you modify the zone file to synchronize it all. What's the problem?
### BIND version used
[root@ops-sandbox-86-10 zone]# named -V
BIND 9.12.2-P1 <id:8914b83>
running on Linux x86_64 3.10.0-1062.52.2.el7.x86_64 #1 SMP Thu Jul 8 09:03:01 UTC 2021
built by make with '--prefix=/usr/local/named' '--sysconfdir=/data/named/named_53' '--enable-threads' '--enable-largefile' '--enable-epoll' '--disable-ipv6' '--with-openssl'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-16)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabledhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4278rndc flush resets stale-refresh-time option to 02023-09-01T08:40:10ZMaksym Odinintsevrndc flush resets stale-refresh-time option to 0### Summary
`rndc flush` command resets `stale-refresh-time` value to 0 (might be rsetes something else what I don't follow)
`rndc reconfig` returns `stale-refresh-time` to the value what was set in config file or default.
Affected ver...### Summary
`rndc flush` command resets `stale-refresh-time` value to 0 (might be rsetes something else what I don't follow)
`rndc reconfig` returns `stale-refresh-time` to the value what was set in config file or default.
Affected versions Bind9.16 and Bind9.18
### BIND version used
```
# named -V
BIND 9.18.18-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 5.19.0-1025-aws #26~22.04.1-Ubuntu SMP Mon Apr 24 01:58:15 UTC 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-hOOOml/bind9-9.18.18=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
```
# rndc serve-stale status
_default: stale cache enabled; stale answers enabled (stale-answer-ttl=30 max-stale-ttl=86400 stale-refresh-time=30)
_bind: stale cache enabled; stale answers enabled (stale-answer-ttl=30 max-stale-ttl=86400 stale-refresh-time=30)
# rndc flush
# rndc serve-stale status
_default: stale cache enabled; stale answers enabled (stale-answer-ttl=30 max-stale-ttl=86400 stale-refresh-time=0)
_bind: stale cache enabled; stale answers enabled (stale-answer-ttl=30 max-stale-ttl=86400 stale-refresh-time=0)
# rndc reconfig
# rndc serve-stale status
_default: stale cache enabled; stale answers enabled (stale-answer-ttl=30 max-stale-ttl=86400 stale-refresh-time=30)
_bind: stale cache enabled; stale answers enabled (stale-answer-ttl=30 max-stale-ttl=86400 stale-refresh-time=30)
```
### What is the current *bug* behavior?
`stale-refresh-time` resets to value = 0 (what disables refresh time window mechanism at all)
### What is the expected *correct* behavior?
`stale-refresh-time` must not be reseted
### Relevant configuration files
```
# named-checkconf -p -x
options {
directory "/var/cache/bind";
listen-on-v6 {
"any";
};
dnssec-validation auto;
stale-answer-enable yes;
stale-answer-client-timeout 1800;
stale-cache-enable yes;
stale-refresh-time 30;
};
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
```September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4250remove support for running python system tests with legacy test runner2023-10-04T13:26:28ZTom Krizekremove support for running python system tests with legacy test runnerCurrently, python system tests must be designed in a way that is compatible with two different modes of operation - the legacy runner and the pytest runner. Their design philosophies are sufficiently different to induce a lot of friction...Currently, python system tests must be designed in a way that is compatible with two different modes of operation - the legacy runner and the pytest runner. Their design philosophies are sufficiently different to induce a lot of friction points and various compatibility issues.
In order for us to be able efficiently write and extend the capabilities of the pytest runner as well as take advantage of all its possibilities, it's not feasible to keep the compatibility layer which enables the python tests to be executed with the legacy runner.
Instead, python tests should be exclusively executed by the pytest runner, providing a predictable environment and behavior.
Legacy runner can still be used to run shell system tests.
Related #3810November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4249compile test binaries/libraries during make2023-09-08T14:05:18ZTom Krizekcompile test binaries/libraries during makeCurrently, test files in `bin/tests/system` which need to be compiled are not part of the typical `make` invocation. Instead, they're compiled when `make check` is invoked.
While this worked well with the legacy test runner, it makes th...Currently, test files in `bin/tests/system` which need to be compiled are not part of the typical `make` invocation. Instead, they're compiled when `make check` is invoked.
While this worked well with the legacy test runner, it makes things needlessly complicated for the pytest runner, and prevents use-cases such as running out-of-tree tests easily.
Compile the required test files as `noinst_` instead of `check_` to ensure they're compiled and available after `make` invocation.
Related #4246, #3810September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4066resolv.conf parsing eats lines if more than 3 nameservers set2023-05-17T22:53:09ZRobert Bridgeresolv.conf parsing eats lines if more than 3 nameservers set<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential!
-->
### Summary
The resolv.conf parsing used in nslookup eats the lines of resolv.conf if there are more than 3 nameservers defined in resolv.conf. This means that if there is an even number of nameservers defined, the first line following the nameservers gets silently eaten and ignored.
### BIND version used
Identified on CentOS 9 stream, confirmed from git on gentoo:
```
BIND 9.19.14-dev (Development Release) <id:562697e>
running on Linux x86_64 6.2.9-gentoo #2 SMP PREEMPT_DYNAMIC Mon May 1 09:27:12 BST 2023
built by make with default
compiled by GCC 13.1.0
compiled with OpenSSL version: OpenSSL 3.0.8 7 Feb 2023
linked to OpenSSL version: OpenSSL 3.0.8 7 Feb 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with liburcu version: 0.14.0
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.11.3
linked to libxml2 version: 21103
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
```
### Steps to reproduce
Create resolv.conf with 4/6/8 nameserver entries, and a search line immediately after the last nameserver entry, e.g.:
```
nameserver 8.8.8.8
nameserver 8.8.8.8
nameserver 8.8.8.8
nameserver 8.8.8.8
search google.com
```
Run nslookup for a name that relies on the search line.
```
nslookup www
```
### What is the current *bug* behavior?
nslookup returns NXDOMAIN (typically)
```
# nslookup www
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find www: NXDOMAIN
```
### What is the expected *correct* behavior?
nslookup should search the domains and find the relevant record
```
$ ./bin/dig/nslookup www
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.16.228
Name: www.google.com
Address: 2a00:1450:4009:820::2004
```
### Relevant configuration files
/etc/resolv.conf posted above
### Relevant logs and/or screenshots
### Possible fixesJune 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4005ICMP error messages causing BIND9 to send more queries than intended2023-05-18T12:29:22ZidealeerICMP error messages causing BIND9 to send more queries than intendedAfter further testing, I found another type of ICMP response that could also
force BIND9 to enter the aggressive query state via UDP
like Knot Resolver via TCP (https://www.knot-resolver.cz/2023-01-26-knot-resolver-5.6.0.html)
The case ...After further testing, I found another type of ICMP response that could also
force BIND9 to enter the aggressive query state via UDP
like Knot Resolver via TCP (https://www.knot-resolver.cz/2023-01-26-knot-resolver-5.6.0.html)
The case is that after receiving an ICMP error message (Type 3, Code 0/2),
BIND9 will try to send 100 queries towards the same remote server, which
bypasses the query limit of about 13.
For type 3, code 3 ICMP error message, BIND9 just returns
an error to the receiving function and stops resolution.
For type 3, code 0 or 2, BIND9 continues to send queries
100 times to the same server, which bypasses the query
limit (no more than around 13 times).
The PoC log from BIND9 shows BIND9 continues to send
100 queries after receiving an ICMP type 3 code 0
message when it resolves my domain, i30.sw.nameserver.fit.
[bind-icmp-type3-code0-poc.log](/uploads/892118329c2b78149ea582ca9a3f1732/bind-icmp-type3-code0-poc.log)
[bind-icmp-type3-code0-reproduction.pdf](/uploads/9356d639c150b216bf332d9e8273b478/bind-icmp-type3-code0-reproduction.pdf)May 2023 (9.16.41, 9.16.41-S1, 9.18.15, 9.18.15-S1, 9.19.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/3682Multiple tests fail2022-11-21T10:35:56ZJean-Christophe ManciotMultiple tests fail### Summary
- Multiple tests fail during the build.
- Some failures (but not all) are linked to the fact that "PKCS#7 support in pyOpenSSL is deprecated. You should use the APIs ". These failures do not appear when using python3-openss...### Summary
- Multiple tests fail during the build.
- Some failures (but not all) are linked to the fact that "PKCS#7 support in pyOpenSSL is deprecated. You should use the APIs ". These failures do not appear when using python3-openssl 21.0.0-1 instead of pyOpenSSL 22.1.0.
- Also, softhsm2-util is available despite some error messages in the log (do you modify PATH variable?) .
### Environment
- Ubuntu 22.10 kinetic
- Python 3.10.8 (apt)
- pytest-7.2.0 (pip3)
- softhsm2 2.6.1-2ubuntu1 (apt)
- openssl 3.0.7-1 (apt)
- pyOpenSSL 22.1.0 (pip3) --> build 1
- python3-openssl 21.0.0-1 (apt) --> build 2
### BIND version used
v9_19_6
### Steps to reproduce
```
git checkout v9_19_6
export CFLAGS+=-Wno-error
export NOCONFIGURE=yes
autoreconf -f -i
./configure \
--build=x86_64-pc-linux-gnu \
--prefix=/usr --sysconfdir=/etc/bind --localstatedir=/ \
--datarootdir=/usr/share --docdir=/usr/share/doc --mandir=/usr/share/man \
--disable-querytrace \
--enable-auto-validation \
--enable-dnstap \
--enable-fixed-rrset \
--enable-full-report \
--enable-geoip \
--enable-largefile \
--enable-linux-caps \
--enable-shared=yes \
--with-cmocka=yes \
--with-gnu-ld=yes \
--with-gssapi=/usr/bin/krb5-config \
--with-jemalloc=detect \
--with-json-c=yes \
--with-libidn2 \
--with-libxml2=yes \
--with-lmdb=auto \
--with-maxminddb=yes \
--with-openssl=/usr/lib/x86_64-linux-gnu \
--with-tuning=large \
--with-zlib=yes
make all
make doc html pdf
pip3 install -I pytest
bin/tests/system/ifconfig.sh up
make check
```
1. with latest pyOpenSSL, leads to:
```
...
PASS: names
FAIL: notify
PASS: nsec3
PASS: nslookup
PASS: padding
PASS: pending
PASS: redirect
PASS: rndc
PASS: rootkeysentinel
PASS: rpz
PASS: rrchecker
PASS: rrl
PASS: rrsetorder
PASS: rsabigexponent
PASS: runtime
PASS: sfcache
PASS: smartsign
PASS: sortlist
PASS: spf
PASS: staticstub
PASS: stub
PASS: synthfromdnssec
PASS: tkey
PASS: tools
PASS: transport-acl
PASS: tsig
PASS: tsiggss
PASS: ttl
PASS: unknown
PASS: verify
PASS: views
FAIL: wildcard
PASS: xferquota
PASS: zonechecks
PASS: nzd2nzf
PASS: fetchlimit
PASS: ixfr
PASS: nsupdate
PASS: resolver
PASS: statistics
PASS: upforwd
PASS: zero
FAIL: dnstap
FAIL: statschannel
PASS: xfer
PASS: reclimit
PASS: kasp
PASS: keymgr2kasp
FAIL: tcp
PASS: pipelined
FAIL: checkds
FAIL: dispatch
FAIL: rpzextra
FAIL: shutdown
FAIL: timeouts
PASS: qmin
FAIL: cookie
PASS: digdelv
PASS: dnssec
PASS: forward
PASS: chain
============================================================================
Testsuite summary for BIND 9.19.6
============================================================================
# TOTAL: 109
# PASS: 96
# SKIP: 2
# XFAIL: 0
# FAIL: 11
# XPASS: 0
# ERROR: 0
```
2. with latest python3-openssl, leads to:
```
PASS: names
FAIL: notify
PASS: nsec3
PASS: nslookup
PASS: padding
PASS: pending
PASS: redirect
PASS: rndc
PASS: rootkeysentinel
PASS: rpz
PASS: rrchecker
PASS: rrl
PASS: rrsetorder
PASS: rsabigexponent
PASS: runtime
PASS: sfcache
PASS: smartsign
PASS: sortlist
PASS: spf
PASS: staticstub
PASS: stub
PASS: synthfromdnssec
PASS: tkey
PASS: tools
PASS: transport-acl
PASS: tsig
PASS: tsiggss
PASS: ttl
PASS: unknown
PASS: verify
PASS: views
PASS: wildcard
PASS: xferquota
PASS: zonechecks
PASS: nzd2nzf
PASS: fetchlimit
PASS: ixfr
PASS: nsupdate
PASS: resolver
PASS: statistics
PASS: upforwd
PASS: zero
PASS: dnstap
PASS: statschannel
PASS: xfer
PASS: reclimit
PASS: kasp
PASS: keymgr2kasp
PASS: tcp
PASS: pipelined
PASS: checkds
PASS: dispatch
PASS: rpzextra
PASS: shutdown
PASS: timeouts
PASS: qmin
FAIL: cookie
PASS: digdelv
PASS: dnssec
PASS: forward
PASS: chain
============================================================================
Testsuite summary for BIND 9.19.6
============================================================================
# TOTAL: 109
# PASS: 105
# SKIP: 2
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
```
### Relevant logs and/or screenshots
bin/tests/system/test-suite.log is attached as:
- [test-suite-with-pyOpenSSL.log](https://drive.google.com/file/d/16d0XdEFCG-hT3PGuMtVr3RfnCJmnCpJm/view?usp=share_link) when pyOpenSSL 22.1.0 (pip3) is used
- [test-suite-with-python3-openssl.log](https://drive.google.com/file/d/1VvTaDnZh9TK0FuxwgUqz0xX3ipUY9vnY/view?usp=share_link) when python3-openssl 21.0.0-1 (apt) is used
The complete build logs are available on demand.https://gitlab.isc.org/isc-projects/bind9/-/issues/3676Deprecate and remove "Operating System Resource Limits"2022-12-07T18:50:32ZOndřej SurýDeprecate and remove "Operating System Resource Limits"From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used inst...From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used instead of ``1073741824`` to specify a limit of one
gigabyte. ``unlimited`` requests unlimited use, or the maximum available
amount. ``default`` uses the limit that was in force when the server was
started. See the description of ``size_spec`` in :ref:`configuration_file_elements`.
The following options set operating system resource limits for the name
server process. Some operating systems do not support some or any of the
limits; on such systems, a warning is issued if an unsupported
limit is used.
``coresize``
This sets the maximum size of a core dump. The default is ``default``.
``datasize``
This sets the maximum amount of data memory the server may use. The default is
``default``. This is a hard limit on server memory usage; if the
server attempts to allocate memory in excess of this limit, the
allocation will fail, which may in turn leave the server unable to
perform DNS service. Therefore, this option is rarely useful as a way
to limit the amount of memory used by the server, but it can be
used to raise an operating system data size limit that is too small
by default. To limit the amount of memory used by the
server, use the ``max-cache-size`` and ``recursive-clients`` options
instead.
``files``
This sets the maximum number of files the server may have open concurrently.
The default is ``unlimited``.
``stacksize``
This sets the maximum amount of stack memory the server may use. The default is
``default``.
```
These are options that are better left to be managed by the environment, and not from within the `named`, just deprecate these options in 9.18 and remove the options from 9.19+.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3395Change default NSEC3 iterations to 0 also for dnssec-signzone2022-07-04T20:56:43ZPetr Špačekpspacek@isc.orgChange default NSEC3 iterations to 0 also for dnssec-signzoneWe have already changed default NSEC3 iterations value for `dnssec-policy` in MR !5513, but we forgot to update `dnssec-signzone` to use the same default.
Currently `dnssec-signzone` in BIND 9.19.1 still defaults to 10 iterations, which...We have already changed default NSEC3 iterations value for `dnssec-policy` in MR !5513, but we forgot to update `dnssec-signzone` to use the same default.
Currently `dnssec-signzone` in BIND 9.19.1 still defaults to 10 iterations, which is not in line with current recommendations.
I propose to treat this as omission in !5513 and fix it even for ~"v9.18" . Sooner the better before lots of people migrate.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/3302Key files are updated every keymgr run2022-05-17T02:51:44ZMatthijs Mekkingmatthijs@isc.orgKey files are updated every keymgr runAll the key related files are touched by BIND on every keymgr run, whether they are modified or not. If the keymgr is waiting for an event, it runs every "refresh key interval", which defaults to an hour.
Fix this by checking for modifi...All the key related files are touched by BIND on every keymgr run, whether they are modified or not. If the keymgr is waiting for an event, it runs every "refresh key interval", which defaults to an hour.
Fix this by checking for modification of keys and only write out keys if they were modified.June 2022 (9.16.30, 9.16.30-S1, 9.18.4, 9.19.2)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3145"dig +nssearch" does not exit until interrupted in BIND 9.18+2022-04-26T13:29:46ZMichał Kępień"dig +nssearch" does not exit until interrupted in BIND 9.18+On my laptop, I am consistently observing the following behavior:
```
$ dig +nssearch isc.org.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 51.75.79.143 in 19 ms.
SOA ns-int.isc.org. hostmaster....On my laptop, I am consistently observing the following behavior:
```
$ dig +nssearch isc.org.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 51.75.79.143 in 19 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 199.6.1.52 in 23 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:500:60:d::52 in 23 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:4f8:1:f::73 in 156 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 149.20.1.73 in 166 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:41d0:701:1100::2c92 in 166 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 199.254.63.254 in 169 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:500:2c::254 in 246 ms.
<...hangs...>
^C$
```
AFAICT, this issue is not specific to my local environment, to the
address family used, etc.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3144"dig { +trace | +nssearch } +tcp" always crashes in BIND 9.18+2022-04-26T13:31:30ZMichał Kępień"dig { +trace | +nssearch } +tcp" always crashes in BIND 9.18+On my laptop, I am consistently observing the following behavior:
```
$ dig +tcp +trace www.isc.org.
; <<>> DiG 9.17.22 <<>> +tcp +trace www.isc.org.
;; global options: +cmd
. 77196 IN NS f.root-servers.net.
. 77196 IN NS g.root-se...On my laptop, I am consistently observing the following behavior:
```
$ dig +tcp +trace www.isc.org.
; <<>> DiG 9.17.22 <<>> +tcp +trace www.isc.org.
;; global options: +cmd
. 77196 IN NS f.root-servers.net.
. 77196 IN NS g.root-servers.net.
. 77196 IN NS k.root-servers.net.
. 77196 IN NS m.root-servers.net.
. 77196 IN NS j.root-servers.net.
. 77196 IN NS c.root-servers.net.
. 77196 IN NS b.root-servers.net.
. 77196 IN NS d.root-servers.net.
. 77196 IN NS h.root-servers.net.
. 77196 IN NS a.root-servers.net.
. 77196 IN NS i.root-servers.net.
. 77196 IN NS e.root-servers.net.
. 77196 IN NS l.root-servers.net.
. 77287 IN RRSIG NS 8 0 518400 20220219050000 20220206040000 9799 . HHcODlZKloXHTGpG2jEDuCtBrOBIhXKf+C08Rlaps84YbLolC8BDw3XO KGXtnojjOAAkVJkjhBxKQTX31l5+Vd4pdG1egoP5W88EuZhe9bYomSCT yVsUBJS68+NvBfYnblOE5QAgIX2v9IgHWg7HzJqMuKLzzVuQhaCGW/XC gnZVyGT5hriM2j7R1n9gfzPjvunv3HduvYg4DKf5Ngio6ZU+ncAiiH0w b+uu4QU1MFZk8UbJ7Cl9oDza+siaQzRLy3eZJoPSY8snpeu8kSRyFfo4 /6GTZxrpmTXNJnHBfaBSL6Emsxah/T/DL56e5oB93JlDwUVMc2LR7d5U zDAgew==
dighost.c:1683: INSIST(query->readhandle == ((void *)0)) failed, back trace
```
AFAICT, this issue is not specific to my local environment, to the
address family used, etc.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3020netmgr/netmgr.c:1737: (...) failed2022-04-26T13:28:04ZNelson A. de Oliveiranetmgr/netmgr.c:1737: (...) failedHi!
I am seeing this for some internal DNS queries:
```
$ host www.unesp.br 200.145.86.1
Using domain server:
Name: 200.145.86.1
Address: 200.145.86.1#53
Aliases:
www.unesp.br has address 200.145.6.98
netmgr/netmgr.c:1737: REQUIRE(((...Hi!
I am seeing this for some internal DNS queries:
```
$ host www.unesp.br 200.145.86.1
Using domain server:
Name: 200.145.86.1
Address: 200.145.86.1#53
Aliases:
www.unesp.br has address 200.145.6.98
netmgr/netmgr.c:1737: REQUIRE((((handle) != ((void *)0) && ((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))) && __extension__ ({ __auto_type __atomic_load_ptr = (&(handle)->references); __typeof__ ((void)0, *__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (5)); __atomic_load_tmp; }) > 0)) failed, back trace
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x3552f)[0x7fae10e0f52f]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc_assertion_failed+0xa)[0x7fae10e0f48a]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nmhandle_attach+0x63)[0x7fae10df9aa3]
host(+0xe3aa)[0x55c5f12963aa]
host(+0xf2c7)[0x55c5f12972c7]
host(+0x1177b)[0x55c5f129977b]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_async_readcb+0xad)[0x7fae10dfce6d]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_readcb+0x97)[0x7fae10dfcf97]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x30cd0)[0x7fae10e0acd0]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_udp_read_cb+0x46)[0x7fae10e0c4c6]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x1ee8d)[0x7fae10956e8d]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x22c75)[0x7fae1095ac75]
/usr/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x114)[0x7fae10947854]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x247da)[0x7fae10dfe7da]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__trampoline_run+0x16)[0x7fae10e36bd6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8eae)[0x7fae10b36eae]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fae10a66a5f]
zsh: IOT instruction (core dumped) host www.unesp.br 200.145.86.1
```
I hope that some of these files are helpful :-)
[core dump](/uploads/325a587af3cbf8c8862b554c57597f93/core-isc-net-0000.55659.neon.1637667477)
[gdb's "thread apply all bt full"](/uploads/56e9ac73d79041b0ed8606e102813b88/gdb.txt)
[tcpdump output](/uploads/60932dfe55240b848a0ef2902bae3289/tcpdump.txt)
This is also https://bugs.debian.org/1000447
If you need anything else, just let me know, please.
Thank you!April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2954BIND 9 Dev PPA2021-11-18T22:48:19ZtriaticBIND 9 Dev PPAThe BIND 9 Dev PPA is missing packages for Ubuntu 21.10 (impish) which has now released.The BIND 9 Dev PPA is missing packages for Ubuntu 21.10 (impish) which has now released.https://gitlab.isc.org/isc-projects/bind9/-/issues/2923Dig crashes with SIGABRT when parsing invalid DoH endpoint location2022-04-26T13:21:41ZfriedlhoDig crashes with SIGABRT when parsing invalid DoH endpoint location### Summary
Dig crashes with SIGABRT when providing an invalid DoH endpoint location.
### BIND version used
DiG 9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu
(Bind9-Dev Branch)
Tested on Ubuntu 20 & Fedora 34.
### Steps to reproduce
Call d...### Summary
Dig crashes with SIGABRT when providing an invalid DoH endpoint location.
### BIND version used
DiG 9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu
(Bind9-Dev Branch)
Tested on Ubuntu 20 & Fedora 34.
### Steps to reproduce
Call dig with a DoH URI and manually specify the DoH Endpoint location without a leading "/":
dig +https=doh/family-filter @doh.cleanbrowsing.org rub.de
The correct command would be:
dig +https=/doh/family-filter @doh.cleanbrowsing.org rub.de
### What is the current *bug* behavior?
Dig crashed with SIGABRT in isc_assertion_failed()
### What is the expected *correct* behavior?
Dig outputs an error message to tell the user that the endpoint location is invalid.
### Relevant logs and/or screenshots
```
dig +https=doh/family-filter @doh.cleanbrowsing.org google.de#
netmgr/http.c:3098: REQUIRE(isc_nm_http_path_isvalid(abs_path)) failed, back trace
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x31d93)[0x7f3798d69d93]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_assertion_failed+0x10)[0x7f3798d69cd0]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_nm_http_makeuri+0x2aa)[0x7f3798da924a]
dig(+0x13ff7)[0x558504aa0ff7]
dig(+0x1721a)[0x558504aa421a]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_task_run+0x162)[0x7f3798d99572]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x19ead)[0x7f3798d51ead]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x204f1)[0x7f3798d584f1]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x20c15)[0x7f3798d58c15]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x213e7)[0x7f3798d593e7]
/lib/x86_64-linux-gnu/libuv.so.1(+0xfea8)[0x7f379885eea8]
/lib/x86_64-linux-gnu/libuv.so.1(uv__io_poll+0x360)[0x7f379886fb80]
/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x11c)[0x7f379885f84c]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x20ca7)[0x7f3798d58ca7]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc__trampoline_run+0x1a)[0x7f3798da08ba]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609)[0x7f3798a7b609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f37989a2293]
Aborted (core dumped)
```
```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `dig +https doh/family-filter @doh.cleanbrowsing.org rub.de'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f2629900700 (LWP 52138))]
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f262c3de859 in __GI_abort () at abort.c:79
#2 0x00007f262c8a2cd5 in isc_assertion_failed () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#3 0x00007f262c8e224a in isc_nm_http_makeuri () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#4 0x0000564d70879ff7 in ?? ()
#5 0x0000564d7087d21a in ?? ()
#6 0x00007f262c8d2572 in isc_task_run () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#7 0x00007f262c88aead in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#8 0x00007f262c8914f1 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#9 0x00007f262c891c15 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#10 0x00007f262c8923e7 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#11 0x00007f262c397ea8 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x00007f262c3a8b80 in uv.io_poll () from /lib/x86_64-linux-gnu/libuv.so.1
#13 0x00007f262c39884c in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#14 0x00007f262c891ca7 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#15 0x00007f262c8d98ba in isc.trampoline_run () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#16 0x00007f262c5b4609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#17 0x00007f262c4db293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldariev