BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-11-05T08:27:39Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2942Replace the CHANGES file with a more practical alternative2021-11-05T08:27:39ZMichał KępieńReplace the CHANGES file with a more practical alternativeI am creating this issue so that we can discuss whether we can come up
with a usable alternative for maintaining the `CHANGES` file in the BIND
9 source repository.
This would really be a topic for an All Hands meeting, but it was raise...I am creating this issue so that we can discuss whether we can come up
with a usable alternative for maintaining the `CHANGES` file in the BIND
9 source repository.
This would really be a topic for an All Hands meeting, but it was raised
often enough recently that it arguably should not wait until the next
All Hands actually happens. Releasing BIND 9.18.0 sounds like a nice
milestone at which we could change things.
Let's start with the pros:
- `CHANGES` is a quick way for people not necessarily proficient with
Git (support folks, users, etc.) to get a quick summary of what
changed in a given BIND 9 release.[^1]
- `CHANGES` is trivial to search for keywords.
- Each `CHANGES` entry is a unique[^2] identifier of a given set of
changes *across various BIND 9 branches*.
Then, there are the cons:
- These days, `CHANGES` entries are pretty much duplicates of commit
log messages (which have become more verbose in the past months).
However, they cannot be as long or as exhaustive as the latter,
which necessitates edits/rewrites, which in certain cases causes a
significant amount of time to be spent on making them legible and/or
correct and/or precise (enough), both when merge requests are
discussed and when monthly releases are prepared. As `CHANGES` has
a more limited target audience than release notes, it does not
necessarily feel like time well spent.
- There are no strict rules governing what gets into `CHANGES`, in
what form, and under what circumstances. We try to adhere to a rule
of thumb which says that "anything that might be of interest to
users and/or important to developers should be listed", but that
turns out to be a very fuzzy line in practice.
- Since the `CHANGES` file is under version control, all entries need
to be cleaned up and prepared *before* any BIND 9 release is
prepared. If a `CHANGES` tweak/fix/addition turns out to be
necessary after a release is prepared, a respin is in order just to
fix a text file.
- `CHANGES` is generally a superset of release notes, which are
supposed to list all important user-facing changes. However, the
form and/or detail level of a given `CHANGES` entry often differs
from its release notes counterpart. This means more duplicate work
for every release.
Replacing `CHANGES` with some other solution acceptable by other ISC
teams would allow SWENG to save time on discussing repeated/derivative
texts, allowing us to spend that time on preparing accurate, verbose
commit messages which are not limited to a few lines in size. It would
also help avoid burning engineering time on silly stuff like retesting
an entire release because of tweaks which do not affect the code itself
or preparing & backporting missing `CHANGES` entries which were
forgotten about (or consciously omitted) for random MRs.
[^1]: There is a a catch, though: adding a `CHANGES` entry for any given
set of changes is not mandatory and therefore arbitrary in
practice. Sometimes we list trivial stuff, sometimes we gloss
over modifications which turn out to have critical consequences
down the line, sometimes we spend time on arguing whether
something needs to be listed or not.
[^2]: Sometimes we assign different texts to the same entry. Example:
entry 5712 in `main` vs. `v9_16`.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2941Implement alternative to all-at-once rehashing for real-time hash tables2022-03-15T20:59:39ZOndřej SurýImplement alternative to all-at-once rehashing for real-time hash tablesThe all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the ...The all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the linear rehashing seems too complex for our purpose) for hot-path hash tables (RBT mostly).November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2940Double free on shutdown after binding a TLS socket fails2021-10-13T15:09:20ZMichał KępieńDouble free on shutdown after binding a TLS socket failsWith no root privileges and the following `named.conf`:
```
options {
listen-on tls ephemeral { 127.0.0.1; };
};
```
I can see this message logged during startup:
```
07-Oct-2021 08:08:46.020 creating TLS socket: permission denied
``...With no root privileges and the following `named.conf`:
```
options {
listen-on tls ephemeral { 127.0.0.1; };
};
```
I can see this message logged during startup:
```
07-Oct-2021 08:08:46.020 creating TLS socket: permission denied
```
and then this one during shutdown:
```
corrupted size vs. prev_size while consolidating
Aborted (core dumped)
```
(The message logged by libc may vary across hosts.)
The bug lies [here][1]:
```c
501 static isc_result_t
502 ns_interface_listentls(ns_interface_t *ifp, isc_tlsctx_t *sslctx) {
503 isc_result_t result;
504
505 result = isc_nm_listentlsdns(
506 ifp->mgr->nm, &ifp->addr, ns__client_request, ifp,
507 ns__client_tcpconn, ifp, sizeof(ns_client_t), ifp->mgr->backlog,
508 &ifp->mgr->sctx->tcpquota, sslctx, &ifp->tcplistensocket);
509
510 if (result != ISC_R_SUCCESS) {
511 isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR,
512 "creating TLS socket: %s",
513 isc_result_totext(result));
514 >>> isc_tlsctx_free(&sslctx);
515 return (result);
516 }
```
The `isc_tlsctx_free()` call on line 514 cleans up the `isc_tlsctx_t`
passed to `ns_interface_listentls()`, but look how the latter is called:
```c
627 if (elt->sslctx != NULL) {
628 result = ns_interface_listentls(ifp, elt->sslctx);
629 if (result != ISC_R_SUCCESS) {
630 goto cleanup_interface;
631 }
632 *ifpret = ifp;
633 return (result);
634 }
```
Specifically, note that `elt->sslctx` is passed by value, so even if
`ns_interface_listentls()` releases the SSL context, `elt->sslctx`
remains non-NULL. This makes `ns_listenelt_destroy()` [call][2]
`isc_tlsctx_free()` again for an already destroyed SSL context.
This bug has been around for at least the past 8 months, so there is no
rush to fix it in October.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/3b9d9f5afb8e9786757843a041b2c0b3392a4ec9/lib/ns/interfacemgr.c#L514
[2]: https://gitlab.isc.org/isc-projects/bind9/-/blob/3b9d9f5afb8e9786757843a041b2c0b3392a4ec9/lib/ns/listenlist.c#L127November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2939TLS protocol Statement Grammar may be incorrect2021-10-07T04:58:15ZkalfeherTLS protocol Statement Grammar may be incorrect<!--
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
The documentation for the tls `protocols` statement indicates placing the protocol between curly braces, however this results in the following error with both `named-checkconf` and when attempting an `rndc reconfig`:
`protocols { TLSv1.3; };`
```
/etc/opt/isc/scls/isc-bind/named.conf: 10:expected string near '{'
```
When quotes are used instead of brackets, there is no error.
`protocols "TLSv1.3";`
### BIND version used
```
BIND 9.17.18 (Development Release) <id:019a476>
running on Linux x86_64 4.18.0-305.19.1.el8_4.x86_64 #1 SMP Wed Sep 15 15:39:39 UTC 2021
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/scls/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/scls/isc-bind' '--sharedstatedir=/var/opt/isc/scls/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-libxml2'
'--without-lmdb' '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 -L/opt/isc/isc-bind/root/usr/lib64'
'CPPFLAGS= -I/opt/isc/isc-bind/root/usr/include' '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.17.18/sphinx/bin/sphinx-build'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
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 libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
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/scls/isc-bind/named.conf
rndc configuration: /etc/opt/isc/scls/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/scls/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/scls/isc-bind/run/named/session.key
named PID file: /var/opt/isc/scls/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/scls/isc-bind/run/named/named.lock
```
### Steps to reproduce
Using the statement grammar for the `protocols` option found here:
https://bind9.readthedocs.io/en/latest/reference.html?highlight=DoH#tls-statement-grammar
for example the following protocols line in the tls statement will fail:
`protocols { TLSv1.3; };`
When quotes are used, no error is encountered:
`protocols "TLSv1.3";`
### What is the current *bug* behavior?
When `rndc reconfig` is run:
```
rndc: 'reconfig' failed: unexpected token
```
In bind logs the following entry is included:
`config: error: /etc/opt/isc/scls/isc-bind/named.conf:10: expected string near '{'`
Line 10 is where I have protocols configured.
### What is the expected *correct* behavior?
no errors and rndc reconfig succeeds.
### Relevant configuration files
Full TLS statement below:
```
tls resolver01 {
cert-file "/etc/certificates/isc_bind/resolver01-cert.pem";
key-file "/etc/certificates/isc_bind/resolver01.pem";
hostname "resolver01.lab.home";
protocols "TLSv1.3"; // This works as expected
// protocols { TLSv1.3; }; // This fails.
};
```
### Possible fixes
Quoting appears to work fine, so updating the documentation may be an option. However it feels more idiomatic to support brackets.https://gitlab.isc.org/isc-projects/bind9/-/issues/2938CID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)2023-01-09T11:11:24ZMark AndrewsCID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)lib/dns/rpz.c:
```
2246
CID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)
25. check_return: Calling isc_timer_reset without checking return value (as is done elsewhere 9 out of 10 times).
2247 isc_timer_...lib/dns/rpz.c:
```
2246
CID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)
25. check_return: Calling isc_timer_reset without checking return value (as is done elsewhere 9 out of 10 times).
2247 isc_timer_reset(rpz->updatetimer, isc_timertype_inactive, NULL,
2248 NULL, true);
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2937DIG defaults to A only rather than A+AAAA search2021-10-06T18:24:29ZOwen DeLongDIG defaults to A only rather than A+AAAA search### Summary
when using dig in the dig <host> form, only A records are searched. AAAA records are ignored.
### BIND version used
DiG 9.10.6
Also DiG 9.16.11-RedHat-9.16.11-5.fc34
### Steps to reproduce
dig split-pao1-64.e-r.fsi.io
o...### Summary
when using dig in the dig <host> form, only A records are searched. AAAA records are ignored.
### BIND version used
DiG 9.10.6
Also DiG 9.16.11-RedHat-9.16.11-5.fc34
### Steps to reproduce
dig split-pao1-64.e-r.fsi.io
or
dig split-pao1-6.e-r.fsi.io
### What is the current *bug* behavior?
Returns A record only in the first case.
Worse, returns NXDOMAIN in the second case.
### What is the expected *correct* behavior?
In the first case, should see A and AAAA records.
In the second case, should see AAAA record and not NXDOMAIN.
### Relevant configuration files
None... DIG is not configurable or at least does not require any configuration for this exercise.
### Relevant logs and/or screenshots
```
kiev:owen (129) ~ % dig split-pao1-64.e-r.fsi.io 2021/10/06 11:14:43
; <<>> DiG 9.10.6 <<>> split-pao1-64.e-r.fsi.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50746
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;split-pao1-64.e-r.fsi.io. IN A
;; ANSWER SECTION:
split-pao1-64.e-r.fsi.io. 2702 IN A 104.244.13.23
;; Query time: 79 msec
;; SERVER: 104.244.14.16#53(104.244.14.16)
;; WHEN: Wed Oct 06 11:14:55 PDT 2021
;; MSG SIZE rcvd: 69
0.001u 0.003s 0:00.08 0.0% 0+0k 0+0io 0pf+0w
; <<>> DiG 9.10.6 <<>> split-pao1-6.e-r.fsi.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21958
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;split-pao1-6.e-r.fsi.io. IN A
;; AUTHORITY SECTION:
fsi.io. 2657 IN SOA fsi.io. hostmaster.fsi.io. 2021100601 7200 3600 604800 3600
;; Query time: 76 msec
;; SERVER: 104.244.14.16#53(104.244.14.16)
;; WHEN: Wed Oct 06 11:14:43 PDT 2021
;; MSG SIZE rcvd: 99
0.001u 0.003s 0:00.08 0.0% 0+0k 0+0io 0pf+0w
```
### Possible fixes
In this day and age, I would expect any default search for name resolution to include both protocols. The fact that dig has not changed this default even now is surprising.https://gitlab.isc.org/isc-projects/bind9/-/issues/2936dispatch_test failed2023-11-02T17:02:19ZOndřej Surýdispatch_test failedhttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2023742https://gitlab.isc.org/isc-projects/bind9/-/jobs/2023742Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2935CID 339035 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)2021-10-14T14:17:09ZMark AndrewsCID 339035 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)signeedsfree doesn't correctly track whether sig.signature needs to be freed.
lib/dns/dnssec.c:
```
1054failure:
11. Condition dynbuf != NULL, taking false branch.
1055 if (dynbuf != NULL) {
1056 isc_buffer_f...signeedsfree doesn't correctly track whether sig.signature needs to be freed.
lib/dns/dnssec.c:
```
1054failure:
11. Condition dynbuf != NULL, taking false branch.
1055 if (dynbuf != NULL) {
1056 isc_buffer_free(&dynbuf);
1057 }
12. Condition signeedsfree, taking true branch.
1058 if (signeedsfree) {
CID 339035 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)
13. var_deref_model: Passing null pointer sig.signature to isc__mem_put, which dereferences it. [show details]
1059 isc_mem_put(mctx, sig.signature, sig.siglen);
1060 }
1061 if (ctx != NULL) {
1062 dst_context_destroy(&ctx);
1063 }
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2934CID 339111: Memory - corruptions (USE_AFTER_FREE)2021-10-11T13:05:43ZMark AndrewsCID 339111: Memory - corruptions (USE_AFTER_FREE)```
*** CID 339111: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/dispatch.c: 1533 in dns_dispatch_cancel()
1527 } else if (resp->response != NULL) {
1528 resp->response(ISC_R_CANCELED, NULL, resp->arg);
1529 }
1530...```
*** CID 339111: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/dispatch.c: 1533 in dns_dispatch_cancel()
1527 } else if (resp->response != NULL) {
1528 resp->response(ISC_R_CANCELED, NULL, resp->arg);
1529 }
1530 }
1531
1532 done:
CID 339111: Memory - corruptions (USE_AFTER_FREE)
Calling "dns_dispatch_done" frees pointer "*respp" which has already been freed.
1533 dns_dispatch_done(respp);
1534 }
1535
1536 void
1537 dns_dispatch_done(dns_dispentry_t **respp) {
1538 dns_dispatchmgr_t *mgr = NULL;
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2933Bump the LLVM/clang version to 13.02021-10-27T11:13:14ZOndřej SurýBump the LLVM/clang version to 13.0The LLVM/clang 13.0 has been released and it fixes some `clang-format` issues that I've been seeing with `clang-format-12`. This needs to be done post-release.The LLVM/clang 13.0 has been released and it fixes some `clang-format` issues that I've been seeing with `clang-format-12`. This needs to be done post-release.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2932TSAN reports indicating reference counting issues with dispatch@netmgr2021-11-02T15:39:31ZMichał KępieńTSAN reports indicating reference counting issues with dispatch@netmgrIn the following GitLab CI job, previously unseen TSAN reports have been
generated during the `fetchlimit` system test:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2020086
If I am reading these reports correctly, it seems that a f...In the following GitLab CI job, previously unseen TSAN reports have been
generated during the `fetchlimit` system test:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2020086
If I am reading these reports correctly, it seems that a fetch context
is simultaneously being destroyed and started, which does not look quite
right. It needs a look from @each and/or @ondrej, though, as I may be
misinterpreting these reports.
<details>
<summary>Click here to expand/fold TSAN reports</summary>
### Report 1 (for `fctx->altfinds`)
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 sort_finds lib/dns/resolver.c:3178
#1 fctx_getaddresses lib/dns/resolver.c:3633
#2 fctx_try lib/dns/resolver.c:3912
#3 fctx_start lib/dns/resolver.c:4471
#4 task_run lib/isc/task.c:827
#5 isc_task_run lib/isc/task.c:907
#6 isc__nm_async_task netmgr/netmgr.c:827
#7 process_netievent netmgr/netmgr.c:906
#8 process_queue netmgr/netmgr.c:998
#9 process_all_queues netmgr/netmgr.c:746
#10 async_cb netmgr/netmgr.c:775
#11 <null> <null>
#12 isc__trampoline_run lib/isc/trampoline.c:185
#13 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2 (mutexes: write M1):
#0 fctx_decreference lib/dns/resolver.c:6881
#1 dns_resolver_destroyfetch lib/dns/resolver.c:10604
#2 fetch_callback lib/ns/query.c:6253
#3 task_run lib/isc/task.c:827
#4 isc_task_run lib/isc/task.c:907
#5 isc__nm_async_task netmgr/netmgr.c:827
#6 process_netievent netmgr/netmgr.c:906
#7 process_queue netmgr/netmgr.c:998
#8 process_all_queues netmgr/netmgr.c:746
#9 async_cb netmgr/netmgr.c:775
#10 <null> <null>
#11 isc__trampoline_run lib/isc/trampoline.c:185
#12 <null> <null>
Location is heap block of size 3728 at 0x000000000017 allocated by thread T2:
#0 malloc <null>
#1 mallocx lib/isc/jemalloc_shim.h:30
#2 mem_get lib/isc/mem.c:341
#3 isc__mem_get lib/isc/mem.c:754
#4 fctx_create lib/dns/resolver.c:4574
#5 dns_resolver_createfetch lib/dns/resolver.c:10463
#6 ns_query_recurse lib/ns/query.c:6455
#7 query_delegation_recurse lib/ns/query.c:8924
#8 query_delegation lib/ns/query.c:8870
#9 query_gotanswer lib/ns/query.c:7607
#10 query_lookup lib/ns/query.c:5989
#11 ns__query_start lib/ns/query.c:5631
#12 query_setup lib/ns/query.c:5344
#13 ns_query_start lib/ns/query.c:12183
#14 ns__client_request lib/ns/client.c:2153
#15 isc__nm_async_readcb netmgr/netmgr.c:2748
#16 isc__nm_readcb netmgr/netmgr.c:2721
#17 udp_recv_cb netmgr/udp.c:418
#18 <null> <null>
#19 isc__trampoline_run lib/isc/trampoline.c:185
#20 <null> <null>
Mutex M1 (0x000000000035) created at:
#0 pthread_mutex_init <null>
#1 isc__mutex_init lib/isc/mutex.c:288
#2 dns_resolver_create lib/dns/resolver.c:9915
#3 dns_view_createresolver lib/dns/view.c:819
#4 configure_view bin/named/server.c:4714
#5 load_configuration bin/named/server.c:9199
#6 loadconfig bin/named/server.c:10380
#7 named_server_reconfigcommand bin/named/server.c:10777
#8 named_control_docommand bin/named/control.c:248
#9 control_command bin/named/controlconf.c:392
#10 task_run lib/isc/task.c:827
#11 isc_task_run lib/isc/task.c:907
#12 isc__nm_async_task netmgr/netmgr.c:827
#13 process_netievent netmgr/netmgr.c:906
#14 process_queue netmgr/netmgr.c:998
#15 process_all_queues netmgr/netmgr.c:746
#16 async_cb netmgr/netmgr.c:775
#17 <null> <null>
#18 isc__trampoline_run lib/isc/trampoline.c:185
#19 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79
#2 isc__netmgr_create netmgr/netmgr.c:321
#3 isc_managers_create lib/isc/managers.c:39
#4 create_managers bin/named/main.c:927
#5 setup bin/named/main.c:1200
#6 main bin/named/main.c:1472
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79
#2 isc__netmgr_create netmgr/netmgr.c:321
#3 isc_managers_create lib/isc/managers.c:39
#4 create_managers bin/named/main.c:927
#5 setup bin/named/main.c:1200
#6 main bin/named/main.c:1472
SUMMARY: ThreadSanitizer: data race lib/dns/resolver.c:3178 in sort_finds
```
### Report 2 (for `fctx->finds`)
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 findname lib/dns/resolver.c:3257
#1 fctx_getaddresses lib/dns/resolver.c:3522
#2 fctx_try lib/dns/resolver.c:3912
#3 fctx_start lib/dns/resolver.c:4471
#4 task_run lib/isc/task.c:827
#5 isc_task_run lib/isc/task.c:907
#6 isc__nm_async_task netmgr/netmgr.c:827
#7 process_netievent netmgr/netmgr.c:906
#8 process_queue netmgr/netmgr.c:998
#9 process_all_queues netmgr/netmgr.c:746
#10 async_cb netmgr/netmgr.c:775
#11 <null> <null>
#12 isc__trampoline_run lib/isc/trampoline.c:185
#13 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2 (mutexes: write M1):
#0 fctx_decreference lib/dns/resolver.c:6880
#1 dns_resolver_destroyfetch lib/dns/resolver.c:10604
#2 fetch_callback lib/ns/query.c:6253
#3 task_run lib/isc/task.c:827
#4 isc_task_run lib/isc/task.c:907
#5 isc__nm_async_task netmgr/netmgr.c:827
#6 process_netievent netmgr/netmgr.c:906
#7 process_queue netmgr/netmgr.c:998
#8 process_all_queues netmgr/netmgr.c:746
#9 async_cb netmgr/netmgr.c:775
#10 <null> <null>
#11 isc__trampoline_run lib/isc/trampoline.c:185
#12 <null> <null>
Location is heap block of size 3728 at 0x000000000017 allocated by thread T2:
#0 malloc <null>
#1 mallocx lib/isc/jemalloc_shim.h:30
#2 mem_get lib/isc/mem.c:341
#3 isc__mem_get lib/isc/mem.c:754
#4 fctx_create lib/dns/resolver.c:4574
#5 dns_resolver_createfetch lib/dns/resolver.c:10463
#6 ns_query_recurse lib/ns/query.c:6455
#7 query_delegation_recurse lib/ns/query.c:8924
#8 query_delegation lib/ns/query.c:8870
#9 query_gotanswer lib/ns/query.c:7607
#10 query_lookup lib/ns/query.c:5989
#11 ns__query_start lib/ns/query.c:5631
#12 query_setup lib/ns/query.c:5344
#13 ns_query_start lib/ns/query.c:12183
#14 ns__client_request lib/ns/client.c:2153
#15 isc__nm_async_readcb netmgr/netmgr.c:2748
#16 isc__nm_readcb netmgr/netmgr.c:2721
#17 udp_recv_cb netmgr/udp.c:418
#18 <null> <null>
#19 isc__trampoline_run lib/isc/trampoline.c:185
#20 <null> <null>
Mutex M1 (0x000000000035) created at:
#0 pthread_mutex_init <null>
#1 isc__mutex_init lib/isc/mutex.c:288
#2 dns_resolver_create lib/dns/resolver.c:9915
#3 dns_view_createresolver lib/dns/view.c:819
#4 configure_view bin/named/server.c:4714
#5 load_configuration bin/named/server.c:9199
#6 loadconfig bin/named/server.c:10380
#7 named_server_reconfigcommand bin/named/server.c:10777
#8 named_control_docommand bin/named/control.c:248
#9 control_command bin/named/controlconf.c:392
#10 task_run lib/isc/task.c:827
#11 isc_task_run lib/isc/task.c:907
#12 isc__nm_async_task netmgr/netmgr.c:827
#13 process_netievent netmgr/netmgr.c:906
#14 process_queue netmgr/netmgr.c:998
#15 process_all_queues netmgr/netmgr.c:746
#16 async_cb netmgr/netmgr.c:775
#17 <null> <null>
#18 isc__trampoline_run lib/isc/trampoline.c:185
#19 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79
#2 isc__netmgr_create netmgr/netmgr.c:321
#3 isc_managers_create lib/isc/managers.c:39
#4 create_managers bin/named/main.c:927
#5 setup bin/named/main.c:1200
#6 main bin/named/main.c:1472
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79
#2 isc__netmgr_create netmgr/netmgr.c:321
#3 isc_managers_create lib/isc/managers.c:39
#4 create_managers bin/named/main.c:927
#5 setup bin/named/main.c:1200
#6 main bin/named/main.c:1472
SUMMARY: ThreadSanitizer: data race lib/dns/resolver.c:3257 in findname
```
</details>November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2931Dynamically added CDS is deleted on signing2022-08-15T15:26:03ZJP MensDynamically added CDS is deleted on signing### Summary
When a CDS record is dynamically added to a zone, BIND deletes it when it next signs the zone. The reason for my wanting to add a CDS "manually" is in order to test [CDS Delete](https://datatracker.ietf.org/doc/html/rfc8078#...### Summary
When a CDS record is dynamically added to a zone, BIND deletes it when it next signs the zone. The reason for my wanting to add a CDS "manually" is in order to test [CDS Delete](https://datatracker.ietf.org/doc/html/rfc8078#section-4).
### BIND version used
```
BIND 9.17.18 (Development Release) <id:1af9d8d>
running on Darwin x86_64 19.6.0 Darwin Kernel Version 19.6.0: Thu Sep 16 20:58:47 PDT 2021; root:xnu-6153.141.40.1~1/RELEASE_X86_64
built by make with '--prefix=/usr/local/bind9git' '--with-libxml2' '--with-json-c' '--with-openssl=/usr/local/Cellar/openssl@1.1/1.1.1i/' 'LDFLAGS=-L/usr/local/Cellar/openssl@1.1/1.1.1i/lib/' 'CPPFLAGS=-I/usr/local/Cellar/openssl@1.1/1.1.1i/include/' 'PYTHON=/usr/local/bin/python3.9'
compiled by CLANG Apple LLVM 12.0.0 (clang-1200.0.32.29)
compiled with OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libnghttp2 version: 1.42.0
linked to libnghttp2 version: 1.42.0
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
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
threads support is enabled
default paths:
named configuration: /usr/local/bind9git/etc/named.conf
rndc configuration: /usr/local/bind9git/etc/rndc.conf
DNSSEC root key: /usr/local/bind9git/etc/bind.keys
nsupdate session key: /usr/local/bind9git/var/run/named/session.key
named PID file: /usr/local/bind9git/var/run/named/named.pid
named lock file: /usr/local/bind9git/var/run/named/named.lock
```
### Steps to reproduce
1. Use `dnssec-settime` to set CDS publication time
```
$ dnssec-settime -P sync now Ktcp.aa.+013+41706.
```
2. Sign the zone
```
$ rndc sign tcp.aa
```
```
05-Oct-2021 10:12:50.430 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:12:50.431 CDS for key tcp.aa/ECDSAP256SHA256/41706 is now published
05-Oct-2021 10:12:50.431 CDNSKEY for key tcp.aa/ECDSAP256SHA256/41706 is now published
```
3. Remove the BIND-generated CDS and sign the zone
```
$ dnssec-settime -D sync now Ktcp.aa.+013+41706.
$ rndc sign tcp.aa
```
```
05-Oct-2021 10:15:49.902 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:15:49.903 CDS (SHA-256) for key tcp.aa/ECDSAP256SHA256/41706 is now deleted
05-Oct-2021 10:15:49.903 CDNSKEY for key tcp.aa/ECDSAP256SHA256/41706 is now deleted
```
4. Manually add a Delete CDS and initiate signing
```
$ nsupdate -k jp.tsig <<E
> server ::1
> zone tcp.aa.
> ttl 61
> add tcp.aa. CDS 0 0 0 00
> send
E
$ rndc sign tcp.aa
```
5. Observe console
```
05-Oct-2021 10:17:03.549 received control channel command 'sign tcp.aa'
05-Oct-2021 10:17:03.549 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:17:03.550 CDS (DELETE) for zone tcp.aa is now deleted
```
If I remove the SyncDelete setting with `dnssec-settime -D sync none Ktcp.aa.+013+41706.` and try to update the zone dynamically with the Delete CDS, the update failes with a `REFUSED`, and the console logs:
```
05-Oct-2021 15:37:12.604 client @0x10cb1e168 ::1#59312/key jp: updating zone 'tcp.aa/IN': adding an RR at 'tcp.aa' CDS 0 0 0 00
05-Oct-2021 15:37:12.604 client @0x10cb1e168 ::1#59312/key jp: updating zone 'tcp.aa/IN': update rejected: bad CDS RRset
```
### What is the current *bug* behavior?
The manually added `CDS` record is removed from the zone.
### What is the expected *correct* behavior?
I would expect the CDS to happily continue to exist in the zone and be signed.
### Relevant configuration files
```
zone "tcp.aa" in {
type primary;
file "master/tcp.aa/tcp.aa";
key-directory "/var/named/master/tcp.aa";
auto-dnssec maintain;
update-policy {
grant "jp" zonesub ANY;
};
};
```
### Relevant logs and/or screenshots
```
05-Oct-2021 10:11:05.511 zone tcp.aa/IN: loaded serial 1
05-Oct-2021 10:11:05.511 zone tcp.aa/IN: sending notifies (serial 1)
05-Oct-2021 10:11:05.511 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:11:05.511 all zones loaded
05-Oct-2021 10:11:05.511 running
05-Oct-2021 10:11:05.511 zone tcp.aa/IN: next key event: 05-Oct-2021 11:11:05.511
05-Oct-2021 10:11:05.540 managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
05-Oct-2021 10:11:05.556 resolver priming query complete
05-Oct-2021 10:12:16.966 received control channel command 'sign tcp.aa'
05-Oct-2021 10:12:16.966 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:12:16.967 Fetching tcp.aa/ECDSAP256SHA256/41706 (ZSK) from key repository.
05-Oct-2021 10:12:16.967 DNSKEY tcp.aa/ECDSAP256SHA256/41706 (ZSK) is now published
05-Oct-2021 10:12:16.967 DNSKEY tcp.aa/ECDSAP256SHA256/41706 (ZSK) is now active
05-Oct-2021 10:12:16.968 zone tcp.aa/IN: next key event: 05-Oct-2021 11:12:16.966
05-Oct-2021 10:12:16.968 zone tcp.aa/IN: sending notifies (serial 2)
05-Oct-2021 10:12:21.969 zone tcp.aa/IN: sending notifies (serial 3)
05-Oct-2021 10:12:50.430 received control channel command 'sign tcp.aa'
05-Oct-2021 10:12:50.430 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:12:50.431 CDS for key tcp.aa/ECDSAP256SHA256/41706 is now published
05-Oct-2021 10:12:50.431 CDNSKEY for key tcp.aa/ECDSAP256SHA256/41706 is now published
05-Oct-2021 10:12:50.432 zone tcp.aa/IN: next key event: 05-Oct-2021 11:12:50.430
05-Oct-2021 10:12:50.432 zone tcp.aa/IN: sending notifies (serial 4)
05-Oct-2021 10:13:09.058 client @0x11307c168 ::1#60208 (tcp.aa): query: tcp.aa IN CDS +E(0)K (::1)
05-Oct-2021 10:14:18.870 received control channel command 'reconfig'
05-Oct-2021 10:14:18.870 loading configuration from '/usr/local/etc/named-cds.conf'
05-Oct-2021 10:14:18.870 unable to open '/usr/local/bind9git/etc/bind.keys'; using built-in keys instead
05-Oct-2021 10:14:18.870 max open files (10240) is smaller than max sockets (21000)
05-Oct-2021 10:14:18.870 using default UDP/IPv4 port range: [49152, 65535]
05-Oct-2021 10:14:18.870 using default UDP/IPv6 port range: [49152, 65535]
05-Oct-2021 10:14:18.871 sizing zone task pool based on 1 zones
05-Oct-2021 10:14:18.872 using built-in root key for view _default
05-Oct-2021 10:14:18.873 not using config file logging statement for logging due to -g option
05-Oct-2021 10:14:18.873 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:14:18.873 reloading configuration succeeded
05-Oct-2021 10:14:18.874 zone tcp.aa/IN: next key event: 05-Oct-2021 11:14:18.873
05-Oct-2021 10:14:18.874 scheduled loading new zones
05-Oct-2021 10:14:18.874 any newly configured zones are now loaded
05-Oct-2021 10:14:18.874 running
05-Oct-2021 10:14:18.888 managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
05-Oct-2021 10:15:05.413 client @0x113257168 ::1#60312/key jp: updating zone 'tcp.aa/IN': update failed: update RR is outside zone (NOTZONE)
05-Oct-2021 10:15:14.306 client @0x11326f168 ::1#60312/key jp: updating zone 'tcp.aa/IN': adding an RR at 'a.tcp.aa' A 1.1.1.1
05-Oct-2021 10:15:14.308 zone tcp.aa/IN: sending notifies (serial 5)
05-Oct-2021 10:15:23.646 client @0x112a53168 ::1#49444 (tcp.aa): query: tcp.aa IN CDS +E(0)K (::1)
05-Oct-2021 10:15:27.533 client @0x113295168 ::1#49446 (a.tcp.aa): query: a.tcp.aa IN A +E(0)K (::1)
05-Oct-2021 10:15:49.902 received control channel command 'sign tcp.aa'
05-Oct-2021 10:15:49.902 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:15:49.903 CDS (SHA-256) for key tcp.aa/ECDSAP256SHA256/41706 is now deleted
05-Oct-2021 10:15:49.903 CDNSKEY for key tcp.aa/ECDSAP256SHA256/41706 is now deleted
05-Oct-2021 10:15:49.904 zone tcp.aa/IN: next key event: 05-Oct-2021 11:15:49.902
05-Oct-2021 10:15:49.904 zone tcp.aa/IN: sending notifies (serial 6)
05-Oct-2021 10:15:56.252 client @0x1132bc168 ::1#49448 (tcp.aa): query: tcp.aa IN CDS +E(0)K (::1)
05-Oct-2021 10:16:46.347 client @0x113257168 ::1#53009/key jp: updating zone 'tcp.aa/IN': adding an RR at 'tcp.aa' CDS 0 0 0 00
05-Oct-2021 10:16:46.349 zone tcp.aa/IN: sending notifies (serial 7)
05-Oct-2021 10:16:57.813 client @0x113257168 ::1#60572 (tcp.aa): query: tcp.aa IN CDS +E(0)K (::1)
05-Oct-2021 10:17:03.549 received control channel command 'sign tcp.aa'
05-Oct-2021 10:17:03.549 zone tcp.aa/IN: reconfiguring zone keys
05-Oct-2021 10:17:03.550 CDS (DELETE) for zone tcp.aa is now deleted
05-Oct-2021 10:17:03.551 zone tcp.aa/IN: next key event: 05-Oct-2021 11:17:03.549
05-Oct-2021 10:17:03.551 zone tcp.aa/IN: sending notifies (serial 8)
```
### Related
These issues are possibly related:
- [Allow for arbitrary CDS/CDNSKEY records to be published](https://gitlab.isc.org/isc-projects/bind9/-/issues/2710)
- [Simplify adding CDS and CDNSKEY deletion records to a inline zone](https://gitlab.isc.org/isc-projects/bind9/-/issues/1634)May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2930Remove support for the "map" zone file format2021-10-04T10:57:58ZMichał KępieńRemove support for the "map" zone file formatThe `masterfile-format map;` options has already been [deprecated][1] in
9.16/9.17. This issue is for dropping the "map" zone file format
altogether in 9.19+. See #2882 for the rationale.
[1]: #2882The `masterfile-format map;` options has already been [deprecated][1] in
9.16/9.17. This issue is for dropping the "map" zone file format
altogether in 9.19+. See #2882 for the rationale.
[1]: #2882BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2929Replace more "master" and "slave" keywords2021-10-27T11:25:17ZPeter DaviesReplace more "master" and "slave" keywordsThe following error message from the ```rndc freeze``` command:
```rndc: 'freeze' failed: not master```
It may be preferable to use the term ```primary```.
There are other instances in code and in the rndc man page.The following error message from the ```rndc freeze``` command:
```rndc: 'freeze' failed: not master```
It may be preferable to use the term ```primary```.
There are other instances in code and in the rndc man page.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2928Coverity issues in the merged dispatch branch2023-01-11T13:58:16ZOndřej SurýCoverity issues in the merged dispatch branch```
** CID 339073: Error handling issues (CHECKED_RETURN)
/lib/dns/resolver.c: 4379 in fctx_doshutdown()
________________________________________________________________________________________________________
*** CID 339073: Error ...```
** CID 339073: Error handling issues (CHECKED_RETURN)
/lib/dns/resolver.c: 4379 in fctx_doshutdown()
________________________________________________________________________________________________________
*** CID 339073: Error handling issues (CHECKED_RETURN)
/lib/dns/resolver.c: 4379 in fctx_doshutdown()
4373 */
4374 fctx_increference(fctx);
4375 fctx_cancelqueries(fctx, false, false);
4376 fctx_cleanup(fctx);
4377
4378 LOCK(&res->buckets[bucketnum].lock);
CID 339073: Error handling issues (CHECKED_RETURN)
Calling "fctx_decreference" without checking return value (as is done elsewhere 6 out of 7 times).
4379 fctx_decreference(fctx);
4380
4381 FCTX_ATTR_SET(fctx, FCTX_ATTR_SHUTTINGDOWN);
4382
4383 INSIST(fctx->state == fetchstate_active ||
4384 fctx->state == fetchstate_done);
```
```
** CID 339072: Error handling issues (CHECKED_RETURN)
/lib/dns/rpz.c: 2247 in rpz_detach()
________________________________________________________________________________________________________
*** CID 339072: Error handling issues (CHECKED_RETURN)
/lib/dns/rpz.c: 2247 in rpz_detach()
2241 false);
2242 }
2243 dns_db_detach(&rpz->updb);
2244 }
2245 }
2246
CID 339072: Error handling issues (CHECKED_RETURN)
Calling "isc_timer_reset" without checking return value (as is done elsewhere 9 out of 10 times).
2247 isc_timer_reset(rpz->updatetimer, isc_timertype_inactive, NULL,
2248 NULL, true);
2249 isc_timer_detach(&rpz->updatetimer);
2250
2251 isc_ht_destroy(&rpz->nodes);
2252
```
```
** CID 339071: (USE_AFTER_FREE)
/lib/dns/resolver.c: 2846 in resquery_connected()
/lib/dns/resolver.c: 2846 in resquery_connected()
/lib/dns/resolver.c: 2846 in resquery_connected()
/lib/dns/resolver.c: 2846 in resquery_connected()
________________________________________________________________________________________________________
*** CID 339071: (USE_AFTER_FREE)
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
```
```
** CID 339070: Memory - corruptions (USE_AFTER_FREE)
________________________________________________________________________________________________________
*** CID 339070: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/request.c: 920 in request_cancel()
914
915 request->flags |= DNS_REQUEST_F_CANCELED;
916 request->flags &= ~DNS_REQUEST_F_CONNECTING;
917
918 if (request->dispentry != NULL) {
919 dns_dispatch_cancel(request->dispentry);
CID 339070: Memory - corruptions (USE_AFTER_FREE)
Calling "dns_dispatch_removeresponse" frees pointer "request->dispentry" which has already been freed.
920 dns_dispatch_removeresponse(&request->dispentry);
921 }
922
923 dns_dispatch_detach(&request->dispatch);
924 }
925 }
```
```
** CID 339069: (USE_AFTER_FREE)
/lib/dns/resolver.c: 1776 in resquery_senddone()
/lib/dns/resolver.c: 1776 in resquery_senddone()
________________________________________________________________________________________________________
*** CID 339069: (USE_AFTER_FREE)
/lib/dns/resolver.c: 1776 in resquery_senddone()
1770 fctx_cancelquery(query, NULL, false, false);
1771 fctx_done(fctx, eresult, __LINE__);
1772 break;
1773 }
1774
1775 detach:
CID 339069: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
1776 resquery_detach(&query);
1777 }
1778
1779 static inline isc_result_t
1780 fctx_addopt(dns_message_t *message, unsigned int version, uint16_t udpsize,
1781 dns_ednsopt_t *ednsopts, size_t count) {
/lib/dns/resolver.c: 1776 in resquery_senddone()
1770 fctx_cancelquery(query, NULL, false, false);
1771 fctx_done(fctx, eresult, __LINE__);
1772 break;
1773 }
1774
1775 detach:
CID 339069: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
1776 resquery_detach(&query);
1777 }
1778
1779 static inline isc_result_t
1780 fctx_addopt(dns_message_t *message, unsigned int version, uint16_t udpsize,
1781 dns_ednsopt_t *ednsopts, size_t count) {
```
```
** CID 339068: Memory - corruptions (USE_AFTER_FREE)
________________________________________________________________________________________________________
*** CID 339068: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/resolver.c: 1397 in fctx_cancelquery()
1391 /*
1392 * Check for any outstanding dispatch responses and if they
1393 * exist, cancel them.
1394 */
1395 if (query->dispentry != NULL) {
1396 dns_dispatch_cancel(query->dispentry);
CID 339068: Memory - corruptions (USE_AFTER_FREE)
Calling "dns_dispatch_removeresponse" frees pointer "query->dispentry" which has already been freed.
1397 dns_dispatch_removeresponse(&query->dispentry);
1398 }
1399
1400 if (ISC_LINK_LINKED(query, link)) {
1401 ISC_LIST_UNLINK(fctx->queries, query, link);
1402 }
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2927lame servers with IPv6 unreachable make dispatch@netmgr stuck on shutdown2022-01-26T11:33:41ZOndřej Surýlame servers with IPv6 unreachable make dispatch@netmgr stuck on shutdownSo, I narrowed it down to a single query:
```
dig -p 5300 IN A mail.lab.comcor.ru. @10.10.10.20
```
which goes like this:
```
04-Oct-2021 09:25:59.507 resolver priming query complete
04-Oct-2021 09:26:16.119 network unreachable resolvi...So, I narrowed it down to a single query:
```
dig -p 5300 IN A mail.lab.comcor.ru. @10.10.10.20
```
which goes like this:
```
04-Oct-2021 09:25:59.507 resolver priming query complete
04-Oct-2021 09:26:16.119 network unreachable resolving '_.ru/A/IN': 2001:500:2f::f#53
04-Oct-2021 09:26:16.119 network unreachable resolving '_.ru/A/IN': 2001:500:12::d0d#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:15:0:193:232:142:17#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:18:0:194:190:124:17#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:17:0:193:232:128:6#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:16:0:194:85:252:62#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:14:0:193:232:156:17#53
04-Oct-2021 09:26:16.143 network unreachable resolving '_.lab.comcor.ru/A/IN': 2a02:290:0:2::5#53
04-Oct-2021 09:26:16.143 network unreachable resolving '_.lab.comcor.ru/A/IN': 2a02:290:0:1::4#53
04-Oct-2021 09:26:16.203 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:17:0:193:232:128:6#53
04-Oct-2021 09:26:16.207 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:18:0:194:190:124:17#53
04-Oct-2021 09:26:16.207 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:16:0:194:85:252:62#53
04-Oct-2021 09:26:16.251 lame server resolving 'mail.lab.comcor.ru' (in 'lab.COMCOR.ru'?): 212.45.0.3#53
04-Oct-2021 09:26:16.335 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2a02:290:0:2::5#53
04-Oct-2021 09:26:16.443 lame server resolving 'ns.lab.comcor.ru' (in 'lab.COMCOR.ru'?): 212.45.0.3#53
```
You also need to have broken IPv6 :-), it doesn't happen when I run `named -4`.
#### Edited ####
This is caused by the new dispatch code:
1. Start `named -p 5300 -g -c /dev/null`
2. Start `dnsperf -s 127.0.0.1 -p 5300 -D -d queryfile-example-10million-201202`
3. Press Ctrl-C
4. `named` doesn't stop:
```
$ eu-stack -p $(pidof named)
PID 275694 - process
TID 275694:
#0 0x00007f4b7bac9c61 clock_nanosleep@@GLIBC_2.17
#1 0x00007f4b7bacf443 __nanosleep
#2 0x00007f4b7bafa125 usleep
#3 0x00007f4b7c476f19 isc__taskmgr_destroy
#4 0x00007f4b7c45b994 isc_managers_destroy
#5 0x0000564d877b86cf destroy_managers
#6 0x0000564d877b86da cleanup
#7 0x0000564d877ba041 main
#8 0x00007f4b7ba2ad0a __libc_start_main
#9 0x0000564d877ae9ca _start
TID 275708:
#0 0x00007f4b7bb02116 epoll_wait
#1 0x00007f4b7be18b3f uv__io_poll
#2 0x00007f4b7be07714 uv_run
#3 0x00007f4b7c43c33e nm_thread
#4 0x00007f4b7c47ce50 isc__trampoline_run
#5 0x00007f4b7bbd1ea7 start_thread
#6 0x00007f4b7bb01def __clone
TID 275709:
#0 0x00007f4b7bbd8ad8 pthread_cond_timedwait@@GLIBC_2.3.2
#1 0x00007f4b7c44f081 isc_condition_waituntil
#2 0x00007f4b7c479dab run
#3 0x00007f4b7c47ce50 isc__trampoline_run
#4 0x00007f4b7bbd1ea7 start_thread
#5 0x00007f4b7bb01def __clone
TID 275710:
#0 0x00007f4b7bb02116 epoll_wait
#1 0x00007f4b7c46f6f2 netthread
#2 0x00007f4b7c47ce50 isc__trampoline_run
#3 0x00007f4b7bbd1ea7 start_thread
#4 0x00007f4b7bb01def __clone
```
+1 we are obviously missing a system test for this kind of scenario.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2926use netmgr for route sockets and remove isc_socket2022-01-21T13:44:36ZEvan Huntuse netmgr for route sockets and remove isc_socketThe last remaining use of `isc_socket` and `isc_socketmgr` in BIND is for the netlink/route sockets that are used to scan for interface changes.
The libuv documentation indicates that any socket that honors the datagram contract can be ...The last remaining use of `isc_socket` and `isc_socketmgr` in BIND is for the netlink/route sockets that are used to scan for interface changes.
The libuv documentation indicates that any socket that honors the datagram contract can be passed to `uv_udp_open()`, so we should be able to make the netmgr do this instead.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2925Defining "default" "http" clause should not be allowed in the configuration2021-10-05T10:12:27ZArtem BoldarievDefining "default" "http" clause should not be allowed in the configurationDefining 'default' 'http' configuration should not be allowed in configuration files, as `default` is reserved for internal use in `listen-on` statements. For example, the following configuration file should be rejected:
```
tls local-t...Defining 'default' 'http' configuration should not be allowed in configuration files, as `default` is reserved for internal use in `listen-on` statements. For example, the following configuration file should be rejected:
```
tls local-tls {
key-file "key.pem";
cert-file "cert.pem";
};
http default {
endpoints { "/dns-query"; };
listener-clients 100;
streams-per-connection 100;
};
options {
listen-on { 10.53.0.1; };
http-port 80;
https-port 443;
http-listener-clients 100;
http-streams-per-connection 100;
listen-on port 443 tls local-tls http default { 10.53.0.1; };
listen-on port 8080 tls none http default { 10.53.0.1; };
};
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2924heap-use-after-free caused by checking for duplicate "http" configurations2021-10-04T10:15:31ZArtem Boldarievheap-use-after-free caused by checking for duplicate "http" configurationsChecking for duplicate `http` clauses in configuration files leads to heap use after free.
```
=================================================================
==1833==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300002b...Checking for duplicate `http` clauses in configuration files leads to heap use after free.
```
=================================================================
==1833==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300002b420 at pc 0x7fbcc0f4c4f2 bp 0x7ffdd9e9a170 sp 0x7ffdd9e99920
READ of size 1 at 0x60300002b420 thread T0
#0 0x7fbcc0f4c4f1 (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb64f1)
#1 0x7fbcc0b2dacd in isc_symtab_define /builds/isc-projects/bind9/lib/isc/symtab.c:221
#2 0x7fbcbe556dfc in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2046
#3 0x7fbcbe556dfc in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#4 0x7fbcbe556dfc in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#5 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#6 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
#7 0x55798af697c9 in _start (/builds/isc-projects/bind9/bin/check/.libs/named-checkconf+0xa7c9)
0x60300002b420 is located 0 bytes inside of 18-byte region [0x60300002b420,0x60300002b432)
freed by thread T0 here:
#0 0x7fbcc0f7efb0 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
#1 0x7fbcc0ac2ca6 in sdallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:39
#2 0x7fbcc0ac2ca6 in mem_put /builds/isc-projects/bind9/lib/isc/mem.c:361
#3 0x7fbcc0ac2ca6 in isc__mem_free /builds/isc-projects/bind9/lib/isc/mem.c:977
#4 0x7fbcbe556e22 in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2066
#5 0x7fbcbe556e22 in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#6 0x7fbcbe556e22 in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#7 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#8 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7fbcc0f7f330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7fbcc0ac1020 in mallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:29
#2 0x7fbcc0ac1020 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:341
#3 0x7fbcc0ac1020 in isc__mem_allocate /builds/isc-projects/bind9/lib/isc/mem.c:886
#4 0x7fbcc0ac429b in isc__mem_strdup /builds/isc-projects/bind9/lib/isc/mem.c:996
#5 0x7fbcbe556d8b in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2039
#6 0x7fbcbe556d8b in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#7 0x7fbcbe556d8b in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#8 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#9 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb64f1)
Shadow bytes around the buggy address:
0x0c067fffd630: 00 00 00 fa fa fa 00 00 02 fa fa fa 00 00 00 fa
0x0c067fffd640: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00
0x0c067fffd650: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa
0x0c067fffd660: 00 00 02 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c067fffd670: fa fa 00 00 00 00 fa fa 00 00 02 fa fa fa 00 00
=>0x0c067fffd680: 00 fa fa fa[fd]fd fd fa fa fa 00 00 02 fa fa fa
0x0c067fffd690: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==1833==ABORTING
```
The problem was found by accident while working on a similar code in !5444October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://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