BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-09-24T11:09:37Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2114CID 306652: Null pointer dereferences (REVERSE_INULL)2020-09-24T11:09:37ZMichal NowakCID 306652: Null pointer dereferences (REVERSE_INULL)This was reported today for `v9_11`. Last Coverity run was executed on Monday, so this is very recent defect:
```
1 new defect(s) introduced to bind-v9_11 found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of ...This was reported today for `v9_11`. Last Coverity run was executed on Monday, so this is very recent defect:
```
1 new defect(s) introduced to bind-v9_11 found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 306652: Null pointer dereferences (REVERSE_INULL)
/lib/isc/unix/socket.c: 4969 in isc__socketmgr_destroy()
*** CID 306652: Null pointer dereferences (REVERSE_INULL)
/lib/isc/unix/socket.c: 4969 in isc__socketmgr_destroy()
4963 isc_mem_put(manager->mctx, manager->fdstate,
4964 manager->maxsocks * sizeof(int));
4965
4966 if (manager->stats != NULL)
4967 isc_stats_detach(&manager->stats);
4968
>>> CID 306652: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "manager->fdlock" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
4969 if (manager->fdlock != NULL) {
4970 for (i = 0; i < FDLOCK_COUNT; i++)
4971 DESTROYLOCK(&manager->fdlock[i]);
4972 isc_mem_put(manager->mctx, manager->fdlock,
4973 FDLOCK_COUNT * sizeof(isc_mutex_t));
4974 }
```
https://scan8.coverity.com/reports.htm#v38342/p12581/fileInstanceId=35494273&defectInstanceId=11001649&mergedDefectId=306652October 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/2112Allow task_test subtests to be selected at runtime.2020-10-02T08:49:45ZMark AndrewsAllow task_test subtests to be selected at runtime.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/bind9/-/issues/2111Restore '-d' option to packet.pl2020-09-02T10:28:07ZMark AndrewsRestore '-d' option to packet.pl!4047 broke tsig system test.!4047 broke tsig system test.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2110dnssec-signzone report() missing newline2023-10-31T20:15:55ZScott Nicholasdnssec-signzone report() missing newline<!--
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
A regression in report() function in dnssec-signzone printing newline.
### BIND version used
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
```
[root@foo named]# dnssec-signzone -3 deadc0ffee -E pkcs11 -S -K /var/named/keys -X +90d -x -o example.org example.org.zone
Fetching example.org/RSASHA256/26302 (KSK) from key repository.Fetching example.org/RSASHA256/27193 (ZSK) from key repository.Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 present, 0 revoked
example.org.zone.signed
```
### What is the expected *correct* behavior?
```
[root@foo named]# dnssec-signzone -3 deadc0ffee -E pkcs11 -S -K /var/named/keys -X +90d -x -o example.org example.org.zone
Fetching example.org/RSASHA256/26302 (KSK) from key repository.
Fetching example.org/RSASHA256/27193 (ZSK) from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 present, 0 revoked
example.org.zone.signed
```
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/dnssec/dnssec-signzone.c#L2729
BIND 9.11 has a putc('\n') there.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2109kind of use-after-free condition in SIG(0) signing2022-06-05T23:37:14ZPeter Davieskind of use-after-free condition in SIG(0) signingJinmei writes:
I suspect the following code could in lib/dns/dnssec.c:dns_dnssec_signmessage cause a kind of "use after free" situation:
```
/*
* If this is a response, digest the query.
*/
if (is_response(msg)) {
RETERR(dst_...Jinmei writes:
I suspect the following code could in lib/dns/dnssec.c:dns_dnssec_signmessage cause a kind of "use after free" situation:
```
/*
* If this is a response, digest the query.
*/
if (is_response(msg)) {
RETERR(dst_context_adddata(ctx, &msg->query));
}
```
when it's called while building a response message in ns_client_send.
If my understanding of the code is correct, this msg->query is a shallow copy of region passed to ns__client_request: it's first (shallow) copied in 'msg.saved' in dns_message_parse, and then (also shallow) copied in 'msg.query' in dns_message_reply. But the original "region" was maintained separately in an isc__networker_t instance, and the region is reused for subsequent network events once ns__client_request returns.
That would mean, for example, if the query handling triggers a recursion "msg->query" can be already bogus at the time of building the response.
That would not be catastrophic like usual sense of "use after free" since the memory region is just recycled internally and dns_dnssec_signmessage uses it only for reading the data. But it would at least result in a broken signature. Also, while that seems to be the only use case of msg->query right now, some new usage of it might cause a more dangerous condition in the future. So, I'd suggest you make it more robust in a more fundamental way, e.g., by passing DNS_MESSAGEPARSE_CLONEBUFFER to dns_message_parse from ns__client_request.
A couple of additional notes:
- I actually didn't test the SIG(0) case, but confirmed that msg->query can store bogus data on resuming recursion, so I'm pretty sure that there's a defect here.
- I suspect (but didn't confirm) this problem didn't exist for previous versions of BIND 9 until it introduced "isc__networker"; previously the memory region for the received query data was maintained in ns_client (either in its 'recvbuf' or via its 'tcpmsg'), so it's guaranteed to be valid until that particular ns_client instance completes the request processing. Still, the relationship is so indirect and therefore seems to be error prone, and this obscurity may in fact be a background cause of this regression. That would probably be another argument for considering more robust and fundamental fix rather than just plug this particular issue.
see [RT #17005](https://support.isc.org/Ticket/Display.html?id=17005)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/2108Bind fails to listen on a control socket when the network interface is not ye...2023-09-22T14:00:23ZTomasKorbarBind fails to listen on a control socket when the network interface is not yet configured### Summary
When you configure bind to listen on a specific ip address for control commands then there
is a race between its attempt to bind the address and network manager, which brings the
interface up, resulting in most cases in failu...### Summary
When you configure bind to listen on a specific ip address for control commands then there
is a race between its attempt to bind the address and network manager, which brings the
interface up, resulting in most cases in failure to bind the control socket after boot.
### BIND version used
```
BIND 9.11.20-RedHat-9.11.20-5.el8 (Extended Support Version) <id:f3d1d66>
running on Linux x86_64 4.18.0-234.el8.x86_64 #1 SMP Thu Aug 20 10:25:32 EDT 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/libexec/platform-python' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--enable-openssl-hash' '--with-geoip2' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=no' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 8.3.1 20191121 (Red Hat 8.3.1-5)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.2.0
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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
1. Add the following section to the configuration.
```
controls {
inet 127.0.0.1 allow { localhost; };
inet <ip adress of current host> allow {<ip adress of current host>; };
};
```
2. Enable named service and reboot the machine.
3. Verify that named listens on ```<ip adress of current host>:953```
with for example ```$ sudo netstat -plnt | grep 953```
### What is the current *bug* behavior?
This log:
```
named[919]: /etc/named.conf:62: couldn't add command channel 192.0.2.1#953: address not available
```
And named is not listening on port 953 of the specific address.
### What is the expected *correct* behavior?
Since automatic-interface-scan option defaults to yes, the expected behaviour is that
named listens for assignment of the address to a newly brought up interface and
binds the control socket after that, just like it does with dns sockets.
### Possible fixes
I think this should be implemented inside of the ```do_scan``` function of interfacemgr module.
Thanks for your help.https://gitlab.isc.org/isc-projects/bind9/-/issues/2107Dates in .key files are wrong.2020-08-31T00:52:09ZMark AndrewsDates in .key files are wrong.7915327aaca8 introduced isc_stdtime_tostring() which calls ctime_r() and removes the trailing newline. The ctime_r() call in dst_api.c:printime was replace with a call to isc_stdtime_tostring() but the code to remove the trailing newlin...7915327aaca8 introduced isc_stdtime_tostring() which calls ctime_r() and removes the trailing newline. The ctime_r() call in dst_api.c:printime was replace with a call to isc_stdtime_tostring() but the code to remove the trailing newline remained leading to the year being truncated.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2106generating Serial on zone modification2020-08-30T07:43:59ZMaziargenerating Serial on zone modificationIt would be really good if on any changes on zones file, serial could be change automatically,
please add this one to next release, also I would be happy to help to make this feature.
Thank youIt would be really good if on any changes on zones file, serial could be change automatically,
please add this one to next release, also I would be happy to help to make this feature.
Thank youhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2105Release Checklist for BIND 9.11.23, BIND 9.11.23-S1, BIND 9.16.7, BIND 9.17.52020-09-18T16:43:51ZMichał KępieńRelease Checklist for BIND 9.11.23, BIND 9.11.23-S1, BIND 9.16.7, BIND 9.17.5## Release Schedule
**Code Freeze:** Wednesday, September 2nd, 2020
**Tagging Deadline:** Monday, September 7th, 2020
**Public Release:** Wednesday, September 16th, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA...## Release Schedule
**Code Freeze:** Wednesday, September 2nd, 2020
**Tagging Deadline:** Monday, September 7th, 2020
**Public Release:** Wednesday, September 16th, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(Support)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(Marketing)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(SwEng)*** Update API files for libraries with new version information.
- [x] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(SwEng)*** Update `CHANGES`.
- [x] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(SwEng)*** Update `README.md`.
- [x] ***(SwEng)*** Update `version`.
- [x] ***(SwEng)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that all the above steps were performed correctly.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.)
- [x] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(SwEng)*** Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`).
- [x] ***(SwEng)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: Preferred command line: `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Vicky Riskvicky@isc.orgVicky Riskvicky@isc.org2020-09-16https://gitlab.isc.org/isc-projects/bind9/-/issues/2104Bind 9.16.6 due to assertion failure2020-09-03T07:24:26ZSøren AndersenBind 9.16.6 due to assertion failure
### Summary
Honestly, i've no idea of what happen. - Upgraded my bind servers a few days ago to 9.16.6, and today named coredumped.
### BIND version used
named -V
BIND 9.16.6 (Stable Release) <id:25846cf>
running on Linux x86_64 3.1...
### Summary
Honestly, i've no idea of what happen. - Upgraded my bind servers a few days ago to 9.16.6, and today named coredumped.
### BIND version used
named -V
BIND 9.16.6 (Stable Release) <id:25846cf>
running on Linux x86_64 3.10.0-1127.18.2.el7.x86_64 #1 SMP Sun Jul 26 15:27:06 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.6/sphinx/bin/sphinx-build'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/opt/isc/isc-bind/named.conf
rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
named PID file: /var/opt/isc/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/isc-bind/run/named/named.lock
### Relevant configuration files
```
named-checkconf -px
acl "Customers" {
..lots of acls
};
logging {
channel "query" {
file "/var/opt/isc/isc-bind/log/query.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "security" {
file "/var/opt/isc/isc-bind/log/security.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "client" {
file "/var/opt/isc/isc-bind/log/client.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "dnssec" {
file "/var/opt/isc/isc-bind/log/dnssec.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "rate-limit" {
file "/var/opt/isc/isc-bind/log/rate-limit.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "general" {
file "/var/opt/isc/isc-bind/log/general.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "resolver" {
file "/var/opt/isc/isc-bind/log/resolver.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "network" {
file "/var/opt/isc/isc-bind/log/network.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "dispatch" {
file "/var/opt/isc/isc-bind/log/dispatch.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "default" {
file "/var/opt/isc/isc-bind/log/named.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"default";
};
category "queries" {
"null";
};
category "security" {
"null";
};
category "client" {
"client";
};
category "dnssec" {
"dnssec";
};
category "rate-limit" {
"rate-limit";
};
category "query-errors" {
"null";
};
category "resolver" {
"resolver";
};
category "lame-servers" {
"null";
};
category "rpz" {
"null";
};
category "dispatch" {
"dispatch";
};
category "network" {
"network";
};
};
options {
directory "/var/opt/isc/isc-bind/named/data";
listen-on port 53 {
"any";
};
listen-on-v6 port 53 {
"none";
};
recursive-clients 1000;
tcp-clients 500;
version "Nothing to see here.";
dnssec-validation auto;
max-cache-size 6442450944;
minimal-responses yes;
query-source address xx.yy.xx.yy port 0;
rate-limit {
errors-per-second 100;
ipv4-prefix-length 32;
log-only no;
nxdomains-per-second 100;
responses-per-second 100;
window 5;
};
recursion yes;
response-policy {
zone "rpz1";
zone "rpz2";
zone "rpz3";
zone "rpz4";
zone "rpz5";
} qname-wait-recurse no;
allow-query {
"Customers";
};
};
statistics-channels {
inet 127.0.0.1 port 8080 allow {
127.0.0.1/32;
};
};
zone "rpz1" {
type master;
file "rpz1.db";
allow-query {
"Customers";
};
};
zone "rpz2" {
type master;
file "rpz2.db";
allow-query {
"Customers";
};
};
zone "rpz3" {
type master;
file "rpz3.db";
allow-query {
"Customers";
};
};
zone "rpz4" {
type master;
file "rpz4.db";
allow-query {
"Customers";
};
};
zone "rpz5" {
type master;
file "rpz5.db";
allow-query {
"Customers";
};
};
### Relevant logs and/or screenshots
```
28-Aug-2020 08:15:18.882 general: critical: rbt.c:2355: REQUIRE(newbits <= rbt->maxhashbits) failed, back trace
28-Aug-2020 08:15:18.882 general: critical: #0 0x42bae0 in ??
28-Aug-2020 08:15:18.882 general: critical: #1 0x7f7b974d0d3a in ??
28-Aug-2020 08:15:18.882 general: critical: #2 0x7f7b987a80f0 in ??
28-Aug-2020 08:15:18.882 general: critical: #3 0x7f7b987a96db in ??
28-Aug-2020 08:15:18.882 general: critical: #4 0x7f7b987b6d84 in ??
28-Aug-2020 08:15:18.882 general: critical: #5 0x7f7b9881d564 in ??
28-Aug-2020 08:15:18.882 general: critical: #6 0x7f7b974f7cca in ??
28-Aug-2020 08:15:18.882 general: critical: #7 0x7f7b95c6aea5 in ??
28-Aug-2020 08:15:18.882 general: critical: #8 0x7f7b959938dd in ??
28-Aug-2020 08:15:18.882 general: critical: exiting (due to assertion failure)
```
gdb /opt/isc/isc-bind/root/usr/sbin/named /var/opt/isc/isc-bind/named/data/core.239023
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/isc/isc-bind/root/usr/sbin/named...Reading symbols from /usr/lib/debug/opt/isc/isc-bind/root/usr/sbin/named.debug...done.
done.
BFD: Warning: /var/opt/isc/isc-bind/named/data/core.239023 is truncated: expected core file size >= 6065528832, found: 2296348672.
[New LWP 239086]
[New LWP 239090]
[New LWP 239089]
[New LWP 239088]
[New LWP 239092]
[New LWP 239096]
[New LWP 239093]
[New LWP 239094]
[New LWP 239095]
[New LWP 239097]
[New LWP 239124]
[New LWP 239098]
[New LWP 239099]
[New LWP 239100]
[New LWP 239101]
[New LWP 239103]
[New LWP 239104]
[New LWP 239128]
[New LWP 239106]
[New LWP 239108]
[New LWP 239107]
[New LWP 239105]
[New LWP 239109]
[New LWP 239111]
[New LWP 239114]
[New LWP 239116]
[New LWP 239115]
[New LWP 239110]
[New LWP 239117]
[New LWP 239118]
[New LWP 239119]
[New LWP 239120]
[New LWP 239121]
[New LWP 239122]
[New LWP 239123]
[New LWP 239112]
[New LWP 239113]
[New LWP 239087]
[New LWP 239091]
[New LWP 239129]
[New LWP 239127]
[New LWP 239126]
[New LWP 239125]
[New LWP 239102]
[New LWP 239132]
[New LWP 239060]
[New LWP 239131]
[New LWP 239130]
[New LWP 239062]
[New LWP 239061]
[New LWP 239064]
[New LWP 239066]
[New LWP 239063]
[New LWP 239067]
[New LWP 239069]
[New LWP 239071]
[New LWP 239068]
[New LWP 239070]
[New LWP 239074]
[New LWP 239072]
[New LWP 239079]
[New LWP 239078]
[New LWP 239081]
[New LWP 239073]
[New LWP 239083]
[New LWP 239080]
[New LWP 239082]
[New LWP 239085]
[New LWP 239050]
[New LWP 239084]
[New LWP 239076]
[New LWP 239075]
[New LWP 239023]
[New LWP 239051]
[New LWP 239055]
[New LWP 239056]
[New LWP 239054]
[New LWP 239053]
[New LWP 239052]
[New LWP 239065]
[New LWP 239059]
[New LWP 239024]
[New LWP 239058]
[New LWP 239026]
[New LWP 239025]
[New LWP 239028]
[New LWP 239030]
[New LWP 239057]
[New LWP 239027]
[New LWP 239031]
[New LWP 239033]
[New LWP 239035]
[New LWP 239032]
[New LWP 239038]
[New LWP 239034]
[New LWP 239036]
[New LWP 239043]
[New LWP 239042]
[New LWP 239045]
[New LWP 239047]
[New LWP 239037]
[New LWP 239044]
[New LWP 239046]
[New LWP 239049]
[New LWP 239048]
[New LWP 239040]
[New LWP 239039]
[New LWP 239077]
[New LWP 239029]
[New LWP 239041]
Cannot access memory at address 0x7f7b98f83128
Cannot access memory at address 0x7f7b98f83120
Failed to read a valid object file image from memory.
Core was generated by `/opt/isc/isc-bind/root/usr/sbin/named -u named -4 -S 64768 -U 16'.
Program terminated with signal 6, Aborted.
#0 0x00007f7b958cb387 in ?? ()
(gdb) thread apply all bt full
Thread 110 (LWP 239041):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8a633c10:
Thread 109 (LWP 239029):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b9164fc10:
Thread 108 (LWP 239077):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b76de8b20:
Thread 107 (LWP 239039):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8b8f8c10:
Thread 106 (LWP 239040):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8af75c10:
Thread 105 (LWP 239048):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b864e3c10:
Thread 104 (LWP 239049):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b85ba1c10:
Thread 103 (LWP 239046):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b87767c10:
Thread 102 (LWP 239044):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b88a2cc10:
Thread 101 (LWP 239037):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8cb7cc10:
Thread 100 (LWP 239047):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b86e25c10:
Thread 99 (LWP 239045):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b880eac10:
Thread 98 (LWP 239042):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b89cee6e0:
Thread 97 (LWP 239043):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8936ec10:
Thread 96 (LWP 239036):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8d4bec10:
---Type <return> to continue, or q <return> to quit---
Thread 95 (LWP 239034):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8e783c10:
Thread 94 (LWP 239038):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8c23ac10:
Thread 93 (LWP 239032):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8fa48c10:
Thread 92 (LWP 239035):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8de3e6e0:
Thread 91 (LWP 239033):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8f0c5c10:
Thread 90 (LWP 239031):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b9038ac10:
Thread 89 (LWP 239027):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b928d3c10:
Thread 88 (LWP 239057):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b810cec10:
Thread 87 (LWP 239030):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b90cccc10:
Thread 86 (LWP 239028):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b91f91c10:
Thread 85 (LWP 239025):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b93b57c10:
Thread 84 (LWP 239026):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b93215c10:
Thread 83 (LWP 239058):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8078cc10:
Thread 82 (LWP 239024):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b94499c10:
Thread 81 (LWP 239059):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7fe09c10:
Thread 80 (LWP 239065):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7ce06d20:
---Type <return> to continue, or q <return> to quit---
Thread 79 (LWP 239052):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b83f9ac10:
Thread 78 (LWP 239053):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b83617c10:
Thread 77 (LWP 239054):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b82cd5c10:
Thread 76 (LWP 239056):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b81a10c10:
Thread 75 (LWP 239055):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b82393c10:
Thread 74 (LWP 239051):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b848dcc10:
Thread 73 (LWP 239023):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7ffcc3eb3010:
Thread 72 (LWP 239075):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b77dfcd20:
Thread 71 (LWP 239076):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b775fbd20:
Thread 70 (LWP 239084):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b735f3d20:
Thread 69 (LWP 239050):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b8521ec10:
Thread 68 (LWP 239085):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b72df2d20:
Thread 67 (LWP 239082):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b745f5d20:
Thread 66 (LWP 239080):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b755f7d20:
Thread 65 (LWP 239083):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b73df4d20:
---Type <return> to continue, or q <return> to quit---
Thread 64 (LWP 239073):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b78dfed20:
Thread 63 (LWP 239081):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b74df6d20:
Thread 62 (LWP 239078):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b765f9d20:
Thread 61 (LWP 239079):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b75df8d20:
Thread 60 (LWP 239072):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b795ffd20:
Thread 59 (LWP 239074):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b785fdd20:
Thread 58 (LWP 239070):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7a601d20:
Thread 57 (LWP 239068):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7b603d20:
Thread 56 (LWP 239071):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b79e00170:
Thread 55 (LWP 239069):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7ae02d20:
Thread 54 (LWP 239067):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7be04d20:
Thread 53 (LWP 239063):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7de08d20:
Thread 52 (LWP 239066):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7c605d20:
Thread 51 (LWP 239064):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7d607d20:
Thread 50 (LWP 239061):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7ee0ad20:
Thread 49 (LWP 239062):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7e609d20:
---Type <return> to continue, or q <return> to quit---
Thread 48 (LWP 239130):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5a3e7b80:
Thread 47 (LWP 239131):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b59ae7b80:
Thread 46 (LWP 239060):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b7f60bd20:
Thread 45 (LWP 239132):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b591e7b80:
Thread 44 (LWP 239102):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b69fe7b80:
Thread 43 (LWP 239125):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5d0e7b80:
Thread 42 (LWP 239126):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5c7e7b80:
Thread 41 (LWP 239127):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5bee7b80:
Thread 40 (LWP 239129):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5ace7b80:
Thread 39 (LWP 239091):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6fdecd20:
Thread 38 (LWP 239087):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b71df0d20:
Thread 37 (LWP 239113):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b63ce7b80:
Thread 36 (LWP 239112):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b645e7b80:
Thread 35 (LWP 239123):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5e2e7b80:
Thread 34 (LWP 239122):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5ebe7b80:
---Type <return> to continue, or q <return> to quit---
Thread 33 (LWP 239121):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5f4e7b80:
Thread 32 (LWP 239120):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5fde7b80:
Thread 31 (LWP 239119):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b606e7b80:
Thread 30 (LWP 239118):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b60fe7b80:
Thread 29 (LWP 239117):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b618e7b80:
Thread 28 (LWP 239110):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b657e7b80:
Thread 27 (LWP 239115):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b62ae7b80:
Thread 26 (LWP 239116):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b621e7b80:
Thread 25 (LWP 239114):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b633e7b80:
Thread 24 (LWP 239111):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b64ee7b80:
Thread 23 (LWP 239109):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b660e7b80:
Thread 22 (LWP 239105):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b684e7b80:
Thread 21 (LWP 239107):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b672e7b80:
Thread 20 (LWP 239108):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b669e7b80:
Thread 19 (LWP 239106):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b67be7b80:
Thread 18 (LWP 239128):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5b5e7b80:
---Type <return> to continue, or q <return> to quit---
Thread 17 (LWP 239104):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b68de7b80:
Thread 16 (LWP 239103):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b696e7b80:
Thread 15 (LWP 239101):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6a8e7b80:
Thread 14 (LWP 239100):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6b1e7b80:
Thread 13 (LWP 239099):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6bae7b80:
Thread 12 (LWP 239098):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6c3e7b80:
Thread 11 (LWP 239124):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b5d9e7b80:
Thread 10 (LWP 239097):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6cce7b80:
Thread 9 (LWP 239095):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6dde8d20:
Thread 8 (LWP 239094):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6e5e9d20:
Thread 7 (LWP 239093):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6edead20:
Thread 6 (LWP 239096):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6d5e7c20:
Thread 5 (LWP 239092):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b6f5ebd20:
Thread 4 (LWP 239088):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b715efd20:
Thread 3 (LWP 239089):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b70deed20:
---Type <return> to continue, or q <return> to quit---
Thread 2 (LWP 239090):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b705edd20:
Thread 1 (LWP 239086):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7f7b725f0238:
(gdb)
´´´September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/2103rndc -checkds halts CDS publication2020-09-02T10:03:17ZMatthijs Mekkingmatthijs@isc.orgrndc -checkds halts CDS publicationThe new function `rndc dnssec -checkds` changes the key manager logic such that the DS only becomes RUMOURED when the given `rndc` command is sent to `named`. However, this DS state is also used to determine whether the CDS can be publis...The new function `rndc dnssec -checkds` changes the key manager logic such that the DS only becomes RUMOURED when the given `rndc` command is sent to `named`. However, this DS state is also used to determine whether the CDS can be published in the child zone.
In other words, the CDS now only gets published once the user said the DS was already in the parent.
This bug is only in development code as the `rndc dnssec -checkds` did not make the August release and thus the fix will not require a release note.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2102critical: resolver.c:5125: INSIST(dns_name_issubdomain(&fctx->name, &fctx->do...2021-01-21T09:57:50Zbobopucritical: resolver.c:5125: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed### Summary
critical: resolver.c:5125: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed
This problem does not always appear, sometimes it is good and sometimes bad
### BIND version used
9.16.6
### Steps to reproduce
...### Summary
critical: resolver.c:5125: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed
This problem does not always appear, sometimes it is good and sometimes bad
### BIND version used
9.16.6
### Steps to reproduce
info: client @0x7f36b4445450 [redacted]#20761 (172.231.232.183.in-addr.arpa): view [redacted]: query: 172.231.232.183.in-addr.arpa IN PTR + ([redacted])
query-errors: info: client @0x7f45d40de490 [redacted]#3072 (246.146.194.221.in-addr.arpa): view [redacted]: query failed (SERVFAIL) for 246.146.194.221.in-addr.arpa/IN/PTR at query.c:6217
### What is the current *bug* behavior?
Abnormal reverse dns lookup
### What is the expected *correct* behavior?
This issue will not be triggered in version bind9.16.5
### Relevant configuration files
[redacted]
### Relevant logs and/or screenshots
queries.log:
info: client @0x7f36b4445450 [redcated]#20761 (172.231.232.183.in-addr.arpa): view [redacted]: query: 172.231.232.183.in-addr.arpa IN PTR + ([redacted])
default.log:
lame-servers: info: REFUSED unexpected RCODE resolving 'tracker.iamhansen.xyz/AAAA/IN': 108.162.192.130#53
query-errors: info: client @0x7f45d40de490 [redacted]#3072 (246.146.194.221.in-addr.arpa): view [redacted]: query failed (SERVFAIL) for 246.146.194.221.in-addr.arpa/IN/PTR at query.c:6217
general.log:
critical: resolver.c:5125: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed
### Possible fixesJanuary 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/2100assert in process_fd in libisc2021-10-05T15:29:36ZTomek Mrugalskiassert in process_fd in libiscThere's an issue reported on Ubuntu [1] that ISC DHCP aborts on assert. But bear with me before you yell "get off my lawn then!". The exact backtrace reported is in [1]. There apparently seems to be a race condition that after a while le...There's an issue reported on Ubuntu [1] that ISC DHCP aborts on assert. But bear with me before you yell "get off my lawn then!". The exact backtrace reported is in [1]. There apparently seems to be a race condition that after a while leads to an assert in sock->pending_send called in process_fd in libisc. This was reported to ISC as [2] and [3]. @tmark looked at the issue and found out that one way to solve the problem is to build libisc with threads disabled. However, Ubuntu folks decided to go another route. They developed a patch for this problem [5] and that fix has been confirmed to solving their specific problem.
I'm opening this ticket to make sure the BIND team is aware of this problem and its potential solution. To be clear, if you decide it's not worth fixing, we can live without that fine.
The original report and patch is for bind 9.11.16, but I just checked that the code where assert blows up seems to be the same in 9.11.22.
References:
- [1] Ubuntu report (backtrace, patch and discussion): https://bugs.launchpad.net/dhcp/+bug/1872118
- [2] DHCP report #1 for Ubuntu: https://gitlab.isc.org/isc-projects/dhcp/-/issues/121
- [3] DHCP report #2 for Ubuntu: https://gitlab.isc.org/isc-projects/dhcp/-/issues/128
- [4] DHCP report from Yocto users: https://gitlab.isc.org/isc-projects/dhcp/-/issues/110
- [5] patch: https://bugs.launchpad.net/dhcp/+bug/1872118/comments/46BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2097manual page tools need updating.2020-08-31T13:10:05ZMark Andrewsmanual page tools need updating.The current ones in the CI are not escaping leading periods when they should.
The ones I have installed locally do.
```
diff --git a/doc/man/dnssec-importkey.1in b/doc/man/dnssec-importkey.1in
index 619e5edadea..174c25c2a3a 100644
--- ...The current ones in the CI are not escaping leading periods when they should.
The ones I have installed locally do.
```
diff --git a/doc/man/dnssec-importkey.1in b/doc/man/dnssec-importkey.1in
index 619e5edadea..174c25c2a3a 100644
--- a/doc/man/dnssec-importkey.1in
+++ b/doc/man/dnssec-importkey.1in
@@ -39,7 +39,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
.sp
\fBdnssec\-importkey\fP reads a public DNSKEY record and generates a pair
of .key/.private files. The DNSKEY record may be read from an existing
-.key file, in which case a corresponding .private file is
+\&.key file, in which case a corresponding .private file is
generated, or it may be read from any other file or from the standard
input, in which case both .key and .private files are generated.
.sp
```September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2095Shifting large rcode in dns/message.c results in undefined behaviour2020-08-31T13:00:24ZOndřej SurýShifting large rcode in dns/message.c results in undefined behaviourFound by a combination of UBSAN and AFL++...
```
message.c:2274:33: runtime error: left shift of 2048 by 20 places cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior message.c:2274:33 in
```
It'...Found by a combination of UBSAN and AFL++...
```
message.c:2274:33: runtime error: left shift of 2048 by 20 places cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior message.c:2274:33 in
```
It's mostly harmless, but should be fixed nevertheless.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/2093tsan files are not being captured by unit tests2021-02-03T07:25:37ZMark Andrewstsan files are not being captured by unit testsFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2092runall.sh/testsummary.sh needs update2021-10-05T15:27:10ZOndřej Surýrunall.sh/testsummary.sh needs updateThe `runall.sh` and `testsummary.sh` scripts needs a refresh to sync up with the automake - it's only used on Windows, so perhaps we might want to replace the shell scripts with something better suited to be run on Windows?The `runall.sh` and `testsummary.sh` scripts needs a refresh to sync up with the automake - it's only used on Windows, so perhaps we might want to replace the shell scripts with something better suited to be run on Windows?BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/20919.16.6 insist failure2021-01-21T09:54:38ZBrian Conry9.16.6 insist failureReceived by security-officer:
Hi,
I just upgraded the four nodes in our anycast resolver cluster to
9.16.6. However, shortly after starting, one of them decided to
exit, and in the log I find:
```
Aug 21 14:00:26 res named[20987]: re...Received by security-officer:
Hi,
I just upgraded the four nodes in our anycast resolver cluster to
9.16.6. However, shortly after starting, one of them decided to
exit, and in the log I find:
```
Aug 21 14:00:26 res named[20987]: resolver.c:5125: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
Aug 21 14:00:26 res named[20987]: #0 0x41f368 in ??
Aug 21 14:00:26 res named[20987]: #1 0x7a49a5e168dd in ??
Aug 21 14:00:26 res named[20987]: #2 0x7a49a72fa0c7 in ??
Aug 21 14:00:26 res named[20987]: #3 0x7a49a72fbdd1 in ??
Aug 21 14:00:26 res named[20987]: #4 0x7a49a7300818 in ??
Aug 21 14:00:26 res named[20987]: #5 0x7a49a73048a8 in ??
Aug 21 14:00:26 res named[20987]: #6 0x7a49a7305395 in ??
Aug 21 14:00:26 res named[20987]: #7 0x7a49a7306831 in ??
Aug 21 14:00:26 res named[20987]: #8 0x7a49a5e3a317 in ??
Aug 21 14:00:26 res named[20987]: #9 0x7a49a340c1d8 in ??
Aug 21 14:00:26 res named[20987]: #10 0x7a49a2e87af0 in ??
Aug 21 14:00:26 res named[20987]: exiting (due to assertion failure)
```
this instance was started some minutes earlier:
Aug 21 13:48:31 res named[20987]: starting BIND 9.16.6 (Stable Release) <id:25846cf>
I wonder if this is related to an incomplete fix (?) of
CVE-2020-8621; this name server is doing forwarding via
```
options {
forwarders {
[redacted];
[redacted];
};
forward first;
};
```
It ran with "qname-minimization relaxed;" at the time (explicitly
configured), I have for now changed it to "off".January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/2090v9_11 dig tsan error2020-09-24T11:06:59ZMark Andrewsv9_11 dig tsan error```
==================
WARNING: ThreadSanitizer: data race (pid=3642)
Read of size 1 at 0x7f20e95d1cd4 by main thread:
#0 isc__app_ctxrun /builds/isc-projects/bind9/lib/isc/unix/app.c:746:34 (libisc.so.1107+0x55d7c)
#1 isc__app...```
==================
WARNING: ThreadSanitizer: data race (pid=3642)
Read of size 1 at 0x7f20e95d1cd4 by main thread:
#0 isc__app_ctxrun /builds/isc-projects/bind9/lib/isc/unix/app.c:746:34 (libisc.so.1107+0x55d7c)
#1 isc__app_run /builds/isc-projects/bind9/lib/isc/unix/app.c:756:10 (libisc.so.1107+0x55f2a)
#2 isc_app_run /builds/isc-projects/bind9/lib/isc/unix/./../app_api.c:207:12 (libisc.so.1107+0x574a1)
#3 dig_startup /builds/isc-projects/bind9/bin/dig/dig.c:2294:2 (dig+0x4bed45)
#4 main /builds/isc-projects/bind9/bin/dig/dig.c:2326:2 (dig+0x4bee41)
Previous write of size 1 at 0x7f20e95d1cd4 by thread T1 (mutexes: write M1074):
#0 isc__app_block /builds/isc-projects/bind9/lib/isc/unix/app.c:936:23 (libisc.so.1107+0x56522)
#1 isc_app_block /builds/isc-projects/bind9/lib/isc/unix/./../app_api.c:260:2 (libisc.so.1107+0x57717)
#2 get_address /builds/isc-projects/bind9/bin/dig/dighost.c:4437:3 (dig+0x4ca090)
#3 send_tcp_connect /builds/isc-projects/bind9/bin/dig/dighost.c:3011:11 (dig+0x4ca371)
#4 do_lookup /builds/isc-projects/bind9/bin/dig/dighost.c:4493:4 (dig+0x4c935f)
#5 start_lookup /builds/isc-projects/bind9/bin/dig/dighost.c:2043:4 (dig+0x4c75b0)
#6 onrun_callback /builds/isc-projects/bind9/bin/dig/dighost.c:4508:2 (dig+0x4cb054)
#7 dispatch /builds/isc-projects/bind9/lib/isc/task.c:1157:7 (libisc.so.1107+0x50785)
#8 run /builds/isc-projects/bind9/lib/isc/task.c:1331:2 (libisc.so.1107+0x4d6d9)
Location is global 'isc_g_appctx' of size 200 at 0x7f20e95d1c80 (libisc.so.1107+0x000000093cd4)
Mutex M1074 (0x000000f39b98) created at:
#0 pthread_mutex_init <null> (dig+0x430cbd)
#1 isc__mutex_init /builds/isc-projects/bind9/lib/isc/pthreads/mutex.c:287:8 (libisc.so.1107+0x72317)
#2 setup_libs /builds/isc-projects/bind9/bin/dig/dighost.c:1664:11 (dig+0x4c6c2b)
#3 dig_setup /builds/isc-projects/bind9/bin/dig/dig.c:2267:2 (dig+0x4bc6c5)
#4 main /builds/isc-projects/bind9/bin/dig/dig.c:2324:2 (dig+0x4bee2e)
Thread T1 'isc-worker0000' (tid=3657, running) created by main thread at:
#0 pthread_create <null> (dig+0x42f73b)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:60:8 (libisc.so.1107+0x72488)
#2 isc__taskmgr_create /builds/isc-projects/bind9/lib/isc/task.c:1468:7 (libisc.so.1107+0x4d5e5)
#3 isc_taskmgr_create /builds/isc-projects/bind9/lib/isc/task.c:2109:11 (libisc.so.1107+0x4f537)
#4 setup_libs /builds/isc-projects/bind9/bin/dig/dighost.c:1634:11 (dig+0x4c6aa6)
#5 dig_setup /builds/isc-projects/bind9/bin/dig/dig.c:2267:2 (dig+0x4bc6c5)
#6 main /builds/isc-projects/bind9/bin/dig/dig.c:2324:2 (dig+0x4bee2e)
SUMMARY: ThreadSanitizer: data race /builds/isc-projects/bind9/lib/isc/unix/app.c:746:34 in isc__app_ctxrun
==================
```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/bind9/-/issues/2089isc 'Software Collection' Fedora repo integration -- auto push/build of new r...2020-08-26T12:15:48Zpgndisc 'Software Collection' Fedora repo integration -- auto push/build of new releases? or manual intervention?Are the Fedora 'Software Collection' isc-bind* pkgs
https://copr.fedorainfracloud.org/coprs/isc/bind/packages/
intended to be automatically pushed to & rebuilt on upstream's version bumps? Or do they require manual invervention?
This...Are the Fedora 'Software Collection' isc-bind* pkgs
https://copr.fedorainfracloud.org/coprs/isc/bind/packages/
intended to be automatically pushed to & rebuilt on upstream's version bumps? Or do they require manual invervention?
This morning's 9.16.6 maintenance release notice, resolving 5 CVEs, is not shown queued/building
https://copr.fedorainfracloud.org/coprs/isc/bind/builds/
and is not obviously included in the CI/CD pipeline.
Would like to understand the timing/scheduling of new releases to the software collection repos,
and, if needed, request the _manual_ build trigger.