BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-12-21T05:23:52Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2433investigate and improve lock contention around mctx2021-12-21T05:23:52ZPetr Špačekpspacek@isc.orginvestigate and improve lock contention around mctx### Summary
It _seems_ that locks around shared memory contexts (mctx) are contended for in various scenarios. This leads to worse performance.
### BIND version used
a23c5d2921e43aaea06d12b1b0f8de2fa6d07759
### Steps to reproduce
- ...### Summary
It _seems_ that locks around shared memory contexts (mctx) are contended for in various scenarios. This leads to worse performance.
### BIND version used
a23c5d2921e43aaea06d12b1b0f8de2fa6d07759
### Steps to reproduce
- Compile named using these options:
`OPTIMIZE="-Og" CFLAGS="g3 -ggdb -Wno-deprecated-declarations -fno-omit-frame-pointer -fno-optimize-sibling-calls -fPIC -rdynamic" LDFLAGS="-fPIE"`
- Run [mutrace](https://github.com/bconry/mutrace) and named with more threads:
`mutrace --hash-size=594327 -d named -n 32 -g -c /dev/null`
Note: Systems with binutils 2.34+ require mutrace patch https://github.com/bconry/mutrace/pull/4
- Send some cache hit traffic to named. E.g. run:
`yes '. NS' | dnsperf -c 100 -l 10`
- SIGINT named when dnsperf finishes.
- While reading output of mutrace ignore misleading line `mutrace.c:750 unlock_hash()` in stack tracebacks if it is present ([depends on mutrace version](https://github.com/bconry/mutrace/issues/5)).
### What is the current *bug* behavior?
Lock contention, leading to bad performance.
### Relevant logs and/or screenshots
[mutrace.log](/uploads/71b0d927b5950a422392d1556c496cee/mutrace.log)
Most contended mutex is:
```
Mutex #60844 (0x0x7f442da070d0) first referenced by:
mutrace.c:750 unlock_hash()
mutex.c:288 isc__mutex_init()
netmgr.c:249 isc_nm_start()
main.c:934 create_managers()
main.c:1248 setup()
main.c:1555 main()
??:0 __libc_start_main()
```
In source code netmgr.c:249 it is lock created on line:
```
249 isc_mempool_create(mgr->mctx, sizeof(isc__netievent_storage_t),
250 &mgr->evpool);
```
I.e. it is locking around `mgr->mctx`.
This is simplest way to show lock contention with tools. During high-QPS benchmarking using `kxdpgun` the lock contention around `mgr->mctx` was indeed creating measurable performance problem. On 16 core system this shared mctx leads to performance drop 3x when compared with situation where each thread has its own mctx.
### Possible fixes
Generally having a separate `mctx` per thread might be a good idea, but it needs careful design so objects which get passed between threads can be de/reallocated correctly.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2435No logging, at any level, related to ADB overmem cleaning2023-11-02T17:00:03ZBrian ConryNo logging, at any level, related to ADB overmem cleaningAs introduced in #2405, there is no logging associated with any of the decisions or actions relating to ADB overmem cleaning.
This makes it impossible to be certain about any of the decisions made, or even *if* decisions were made, with...As introduced in #2405, there is no logging associated with any of the decisions or actions relating to ADB overmem cleaning.
This makes it impossible to be certain about any of the decisions made, or even *if* decisions were made, without using a debugger.
When ADB overmem cleaning operates on a subset of the entries for servers authoritative for a zone it takes actions that will undermine all of the work done maintaining SRTT values and can cause the server to behave in non-intuitive ways.
Among other possible effects that are not yet properly characterized.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2436ADB stats don't provide any information useful to assess the utility that it ...2023-11-02T17:00:03ZBrian ConryADB stats don't provide any information useful to assess the utility that it is able to provideAs mentioned on #2405, the stats related to the ADB are inadequate for an operator to identify when there are issues.
The current ADB stats are limited to:
* `dns_adbstats_entriescnt` - "Addresses in hash table"
* `dns_adbstats_namescnt...As mentioned on #2405, the stats related to the ADB are inadequate for an operator to identify when there are issues.
The current ADB stats are limited to:
* `dns_adbstats_entriescnt` - "Addresses in hash table"
* `dns_adbstats_namescnt` - "Names in hash table"
* `dns_adbstats_nentries` - "Address hash table size"
* `dns_adbstats_nnames` - "Name hash table size"
It is also possible, using the stats channel, to see the stats for the memory contexts used by the ADBs, though there is not an explicit strong association between those memory contexts and the ADB (as identified by view).
It was perhaps expected that these would be sufficient to characterize what is going on in the hash table, but I have recently inspected a customer core file in which the ADB seems to have been in a state of near-constant overmem cleaning with about 73% of the address entries being marked as `ENTRY_IS_DEAD`.
It doesn't matter whether or not those "dead" entries are counted in those stats, the reported values are necessarily providing an incomplete picture of the state of the ADB.
At minimum there should be stats for the number of "live" entries separate from the number of "dead" entries. It may also be informative for an operator to see how many entries are associated with other flags, such as `NOEDNS`.
I have not yet done a thorough analysis to identify any other "missing" stats that may be useful to operators in understanding how their system is performing and utilizing resources.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2437[ISC-support #17264] ADB overmem cleaning strategy is too arbitrary2022-12-02T12:09:19ZBrian Conry[ISC-support #17264] ADB overmem cleaning strategy is too arbitraryI've labeled this as a "Feature" because the current behavior has been in use "forever" and thus can be considered to be a "baseline" behavior.
The current overmem cleaning behavior, as I understand it, is that when a new entry is added...I've labeled this as a "Feature" because the current behavior has been in use "forever" and thus can be considered to be a "baseline" behavior.
The current overmem cleaning behavior, as I understand it, is that when a new entry is added up to two other entries in the same hash bucket are flagged with `ENTRY_IS_DEAD`. This makes a semi-arbitrary choice based primarily on the convenience of not needing to acquire any additional locks.
This method, though, can cause significant impairment for a resolver.
For example, consider a zone is served by two servers - one with low latency and EDNS support and the other with high latency and broken EDNS support.
It is most likely that these two entries will fall into different hash buckets, and theoretically each of those hash buckets have the same chance of triggering the overmem cleaning by having a new entry added to them.
This means that there's a 50% chance that ADB will "forget" about the preferred server. Then, until the ADB for the other address either expires or is likewise purged, BIND will exclusively use only the high-latency server with broken EDNS support.
One of the first tasks on this issue will be attempting to identify a full set of desirable characteristics for the overmem cleaning behavior.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2438[ISC-support #17264] add configuration option to set ADB size independent of ...2023-11-02T17:00:03ZBrian Conry[ISC-support #17264] add configuration option to set ADB size independent of cache sizeCurrently the maximum ADB size is set as a fraction (1/8) of the configured/effective `max-cache-size`.
It has been observed with at least one customer that this size is sometimes insufficient.
This may be related to the rise of CDNs w...Currently the maximum ADB size is set as a fraction (1/8) of the configured/effective `max-cache-size`.
It has been observed with at least one customer that this size is sometimes insufficient.
This may be related to the rise of CDNs with long CNAME chains spread across multiple domains with each domain typically hosted by a large group of geographically-diverse authoritative servers.
While there are other features necessary before an operator can tune this based on data rather than intuition, it may also be useful in our own explorations of ADB behavior in adverse conditions.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2439[ISC-support #17264] revisit hard-coded limit to ADB sizes with shared caches2023-11-02T17:00:03ZBrian Conry[ISC-support #17264] revisit hard-coded limit to ADB sizes with shared cachesCurrently when using a shared cache the ADB size is limited by a `#define` constant. This is documented as being done to allow an operator to specify a huge shared cache size without automatically allowing a similarly-huge ADB for each ...Currently when using a shared cache the ADB size is limited by a `#define` constant. This is documented as being done to allow an operator to specify a huge shared cache size without automatically allowing a similarly-huge ADB for each view attached to that cache.
There are some assumptions here that I believe may be incorrect.
The first incorrect assumption (and verifiable at that) is that BIND will continue to behave well when an ADB is overmem. Analysis on recent customer core files has determined that an overmem ADB may start to "thrash" impacting resolver performance (as noted by the customer's system monitoring).
A second assumption is that there will be enough differences between the query/recursion patterns for each view that no one view will have to worry about possibly needing to have ADB entries for every upstream nameserver. This is clearly false in the degenerate case of a single view using an attached cache, but even with multiple actual views this makes assumptions about how the operator is dividing up the query traffic that are unlikely to always be true.
If #2438 is completed then it may be sufficient to exempt an explicitly configured ADB size from this check. Other possible solutions include allowing this `#define` to be overridden at build-time or using a different scaling formula for shared caches than is used for exclusive caches.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2440rndc flush with shared caches does not affect all ADBs2021-08-26T16:13:32ZBrian Conryrndc flush with shared caches does not affect all ADBsWhen flushing a cache using `rndc flush` the view flushes both the cache and the ADB (among other things).
When using a shared cache the cache may be flushed by specifying any of the view names attached to it. When this is done only th...When flushing a cache using `rndc flush` the view flushes both the cache and the ADB (among other things).
When using a shared cache the cache may be flushed by specifying any of the view names attached to it. When this is done only the ADB for that view is also flushed. All other ADBs using data derived from the cache are not flushed.
This may lead to a situation where the resolver is using prior ADB data for recursion that does not match the data currently in the cache.
The operator may work around this by issuing a flush command without a view name, but this may be undesirable if they have other views that aren't attached to that same cache.
Ideally flushing a shared cache should imply the flushing of the ADBs of all views using that cache.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2441system testing does not verify expected ADB behavior when doing overmem cleaning2022-12-02T12:09:23ZBrian Conrysystem testing does not verify expected ADB behavior when doing overmem cleaningAs introduced on #2405, BIND currently does not behave well in at least some circumstances when the ADB is overmem and performing overmem cleaning.
Presumably we added the overmem cleaning logic with the intent that BIND should continue...As introduced on #2405, BIND currently does not behave well in at least some circumstances when the ADB is overmem and performing overmem cleaning.
Presumably we added the overmem cleaning logic with the intent that BIND should continue to run and operate relatively normally when the ADB goes overmem, and that such behavior would be better than other alternatives (e.g. flushing the entire ADB as soon as the overmem condition is detected).
We have not documented our expectations for BIND's operational performance when this behavior is triggered, nor do we have any system tests that attempt to verify that BIND is continuing to behave as we expect.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2442TSAN error: lib/dns/rbtdb.c2021-03-18T12:00:07ZMark AndrewsTSAN error: lib/dns/rbtdb.cJob [#1434050](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1434050) failed for e6064e7cd9dc4848cdcc63f051bda46e935c733d:
```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1 (mutexes: read M1, r...Job [#1434050](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1434050) failed for e6064e7cd9dc4848cdcc63f051bda46e935c733d:
```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1 (mutexes: read M1, read M2):
#0 check_stale_header lib/dns/rbtdb.c:4573
#1 cache_find lib/dns/rbtdb.c:5061
#2 dns_db_findext lib/dns/db.c:536
#3 query_lookup lib/ns/query.c:5805
#4 query_gotanswer lib/ns/query.c:7556
#5 query_resume lib/ns/query.c:6614
#6 fetch_callback lib/ns/query.c:6161
#7 dispatch lib/isc/task.c:1152
#8 run lib/isc/task.c:1344
#9 <null> <null>
Previous write of size 4 at 0x000000000001 by thread T2 (mutexes: read M1, read M2):
#0 check_stale_header lib/dns/rbtdb.c:4573
#1 cache_find lib/dns/rbtdb.c:5061
#2 dns_db_findext lib/dns/db.c:536
#3 query_lookup lib/ns/query.c:5805
#4 query_gotanswer lib/ns/query.c:7556
#5 query_resume lib/ns/query.c:6614
#6 fetch_callback lib/ns/query.c:6161
#7 dispatch lib/isc/task.c:1152
#8 run lib/isc/task.c:1344
#9 <null> <null>
Location is heap block of size 209 at 0x000000000011 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 mem_allocateunlocked lib/isc/mem.c:1268
#4 isc___mem_allocate lib/isc/mem.c:1288
#5 isc__mem_allocate lib/isc/mem.c:2453
#6 isc___mem_get lib/isc/mem.c:1037
#7 isc__mem_get lib/isc/mem.c:2432
#8 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:270
#9 addrdataset lib/dns/rbtdb.c:6813
#10 dns_db_addrdataset lib/dns/db.c:719
#11 addoptout lib/dns/ncache.c:281
#12 dns_ncache_add lib/dns/ncache.c:101
#13 ncache_adderesult lib/dns/resolver.c:6795
#14 ncache_message lib/dns/resolver.c:6972
#15 rctx_ncache lib/dns/resolver.c:9350
#16 resquery_response lib/dns/resolver.c:8063
#17 dispatch lib/isc/task.c:1152
#18 run lib/isc/task.c:1344
#19 <null> <null>
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
SUMMARY: ThreadSanitizer: data race lib/dns/rbtdb.c:4573 in check_stale_header
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2443CID 316608: Memory - corruptions (OVERRUN)2021-03-03T09:57:01ZMichal NowakCID 316608: Memory - corruptions (OVERRUN)Coverity Scan identified this as of a "High" impact.
Recently committed as 49c40827f6b88b4c12751086aab529298587e265 by @dfronza:
```
*** CID 316608: Memory - corruptions (OVERRUN)
/lib/dns/resolver.c: 5017 in fctx_create()
5011 ...Coverity Scan identified this as of a "High" impact.
Recently committed as 49c40827f6b88b4c12751086aab529298587e265 by @dfronza:
```
*** CID 316608: Memory - corruptions (OVERRUN)
/lib/dns/resolver.c: 5017 in fctx_create()
5011 * Make fctx->info point to a copy of a formatted string
5012 * "name/type".
5013 */
5014 dns_name_format(name, buf, sizeof(buf));
5015 dns_rdatatype_format(type, typebuf, sizeof(typebuf));
5016 p = strlcat(buf, "/", sizeof(buf));
>>> CID 316608: Memory - corruptions (OVERRUN)
>>> Calling "strlcat" with "buf + p" and "1036UL" is suspicious because "buf" points into a buffer of 1036 bytes and the function call may access "(char *)(buf + p) + 1035UL". [Note: The source code implementation of the function has been overridden by a builtin model.]
5017 strlcat(buf + p, typebuf, sizeof(buf));
5018 fctx->info = isc_mem_strdup(mctx, buf);
5019
5020 FCTXTRACE("create");
5021 dns_name_init(&fctx->name, NULL);
5022 dns_name_dup(name, mctx, &fctx->name);
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2444CID 316609: Resource leak in bin/tests/test_client.c2021-01-29T14:54:44ZMichal NowakCID 316609: Resource leak in bin/tests/test_client.cRecently committed as e493e04c0fe94b24182832c89342869c55181748 by @ondrej:
```
*** CID 316609: (RESOURCE_LEAK)
/bin/tests/test_client.c: 258 in parse_options()
252 for (struct addrinfo *rp = result; rp != NULL; rp = rp->ai_next)...Recently committed as e493e04c0fe94b24182832c89342869c55181748 by @ondrej:
```
*** CID 316609: (RESOURCE_LEAK)
/bin/tests/test_client.c: 258 in parse_options()
252 for (struct addrinfo *rp = result; rp != NULL; rp = rp->ai_next)
253 {
254 RUNTIME_CHECK(isc_sockaddr_fromsockaddr(
255 &sockaddr_remote, rp->ai_addr) ==
256 ISC_R_SUCCESS);
257 }
>>> CID 316609: (RESOURCE_LEAK)
>>> Variable "result" going out of scope leaks the storage it points to.
258 }
259
260 isc_sockaddr_format(&sockaddr_local, buf, sizeof(buf));
261
262 printf("Will connect from %s://%s", protocols[protocol], buf);
263
/bin/tests/test_client.c: 240 in parse_options()
234 for (struct addrinfo *rp = result; rp != NULL; rp = rp->ai_next)
235 {
236 RUNTIME_CHECK(isc_sockaddr_fromsockaddr(&sockaddr_local,
237 rp->ai_addr) ==
238 ISC_R_SUCCESS);
239 }
>>> CID 316609: (RESOURCE_LEAK)
>>> Variable "result" going out of scope leaks the storage it points to.
240 }
241
242 {
243 struct addrinfo hints = {
244 .ai_family = family,
245 .ai_socktype = (protocol == UDP) ? SOCK_DGRAM
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2446query.c:5430:16: runtime error: load of value 190, which is not a valid value...2022-09-09T06:48:38ZMichal Nowakquery.c:5430:16: runtime error: load of value 190, which is not a valid value for type '_Bool'This was originally reported in https://gitlab.isc.org/isc-private/bind-qa/-/issues/38#note_189030.
When AddressSanitizer constraint from libns unit tests are [dropped](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4622), `...This was originally reported in https://gitlab.isc.org/isc-private/bind-qa/-/issues/38#note_189030.
When AddressSanitizer constraint from libns unit tests are [dropped](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4622), `query_test` produces runtime error:
```
[==========] Running 4 test(s).
[ RUN ] ns__query_sfcache_test
[ OK ] ns__query_sfcache_test
[ RUN ] ns__query_start_test
[ OK ] ns__query_start_test
[ RUN ] ns__query_hookasync_test
[ OK ] ns__query_hookasync_test
[ RUN ] ns__query_hookasync_e2e_test
query.c:5430:16: runtime error: load of value 190, which is not a valid value for type '_Bool'
[ OK ] ns__query_hookasync_e2e_test
[==========] 4 test(s) run.
[ PASSED ] 4 test(s).
PASS query_test (exit status: 0)
```
This is what @michal suggests at https://gitlab.isc.org/isc-private/bind-qa/-/issues/38#note_189274:
> This error is a nice catch by ASAN because 190 is `0xbe` in hex. The error is triggered because the `checknames` field of `struct dns_view` is not initialized by `dns_view_create()`.
> This is a workaround for `lib/ns/tests/query_test.c`:
> ```diff
> diff --git a/lib/ns/tests/query_test.c b/lib/ns/tests/query_test.c
> index 972a2c2cb4..6da01c9291 100644
> --- a/lib/ns/tests/query_test.c
> +++ b/lib/ns/tests/query_test.c
> @@ -1412,6 +1412,7 @@ run_hookasync_e2e_test(const ns__query_hookasync_e2e_test_params_t *test) {
> qctx->client->sendcb = send_noop;
>
> /* Load a zone. it should have ns.foo/A */
> + qctx->client->view->checknames = true;
> result = ns_test_serve_zone("foo", "testdata/query/foo.db",
> qctx->client->view);
> INSIST(result == ISC_R_SUCCESS);
> ```
> However, I would also consider an alternative approach: adding `view->checknames = false;` to `dns_view_create()`. I have not tested that, though. Note that the default `0xbe` value means that a check for `view->checknames` (which is supposed to be a boolean) would evaluate to `true` rather than `false`.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2447rbt_serialize_test.c: runtime error: member access within misaligned address2023-05-05T12:11:48ZMichal Nowakrbt_serialize_test.c: runtime error: member access within misaligned addressOn Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) with ASAN, ~~but not Debian 10 with gcc 8.3.0 we have in the CI~~, I get following runtime errors in `serialize_test` unit test:
```
[==========] Running 3 test(s).
[ RUN ...On Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) with ASAN, ~~but not Debian 10 with gcc 8.3.0 we have in the CI~~, I get following runtime errors in `serialize_test` unit test:
```
[==========] Running 3 test(s).
[ RUN ] serialize_test
[ OK ] serialize_test
[ RUN ] deserialize_corrupt_test
rbt_serialize_test.c:185:27: runtime error: member access within misaligned address 0x7fa040bc62a3 for type 'struct data_holder_t', which requires 8 byte alignment
0x7fa040bc62a3: note: pointer points here
00 0a 00 00 00 00 00 00 00 b0 12 00 00 00 00 00 00 74 65 73 74 2e 6e 65 74 2e 00 00 00 00 00 00
^
rbt_serialize_test.c:185:45: runtime error: member access within misaligned address 0x7fa040bc62a3 for type 'struct data_holder_t', which requires 8 byte alignment
0x7fa040bc62a3: note: pointer points here
00 0a 00 00 00 00 00 00 00 b0 12 00 00 00 00 00 00 74 65 73 74 2e 6e 65 74 2e 00 00 00 00 00 00
^
[ OK ] deserialize_corrupt_test
[ RUN ] serialize_align_test
[ OK ] serialize_align_test
[==========] 3 test(s) run.
[ PASSED ] 3 test(s).
PASS rbt_serialize_test (exit status: 0)
```May 2023 (9.16.41, 9.16.41-S1, 9.18.15, 9.18.15-S1, 9.19.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2448Sphinx-generated documentation built in GitLab CI is sometimes defective2022-08-05T11:42:43ZMichał KępieńSphinx-generated documentation built in GitLab CI is sometimes defective@pspacek noticed that the latest PDF version of the BIND 9 ARM is
missing the entire "BIND 9 Configuration Reference" chapter:
https://ftp.isc.org/isc/bind9/9.17.9/doc/arm/Bv9ARM.pdf
The same problem seems to be affecting the PDF for 9...@pspacek noticed that the latest PDF version of the BIND 9 ARM is
missing the entire "BIND 9 Configuration Reference" chapter:
https://ftp.isc.org/isc/bind9/9.17.9/doc/arm/Bv9ARM.pdf
The same problem seems to be affecting the PDF for 9.17.8:
https://ftp.isc.org/isc/bind9/9.17.8/doc/arm/Bv9ARM.pdf
but not for 9.17.7:
https://ftp.isc.org/isc/bind9/9.17.7/doc/arm/Bv9ARM.pdf
None of the 9.16.x PDFs seem to be broken this way.
I could not reproduce this problem locally and also confirmed there were
no changes in the `doc/` directory between 9.17.7 and 9.17.8 that could
have caused this. Upon further investigation, I discovered that the
problem is caused by using parallel `make` jobs (`-j`) when running
`make doc` in GitLab CI - this causes multiple `sphinx-build` instances
to run simultaneously in the same working directory, which means they
can stomp on each other's data. Unfortunately, problems like this only
triggered Sphinx warnings, not errors, so the relevant GitLab CI jobs
have been silently passing.
~~This conclusion means that *all* forms of our documentation might have
been malformed in one way or another ever since we migrated to Sphinx,
i.e. since May 2020 (see !1761, !3536). Looking at GitLab CI job traces
from the past 2 months, it can be estimated that the problem has a
roughly 15% chance of getting triggered for any Sphinx documentation
build job.~~ (See correction [below][1].)
[1]: #note_190871February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2449AddressSanitizer: odr-violation: global 'dns_lctx' at log.c:69:332021-09-16T13:29:11ZMichal NowakAddressSanitizer: odr-violation: global 'dns_lctx' at log.c:69:33On Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) with ASAN, but not Debian 10 with gcc 8.3.0 we have in the CI, I get following error when running the `dyndb` system test:
```
29-Jan-2021 11:25:04.597 loading DynDB instan...On Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) with ASAN, but not Debian 10 with gcc 8.3.0 we have in the CI, I get following error when running the `dyndb` system test:
```
29-Jan-2021 11:25:04.597 loading DynDB instance 'sample' driver '../driver/lib/sample.so'
=================================================================
==2511090==ERROR: AddressSanitizer: odr-violation (0x7f9e15d78d00):
[1] size=8 'dns_lctx' log.c:69:33
[2] size=8 'dns_lctx' log.c:69:33
These globals were registered at these points:
[1]:
#0 0x7f9e324a7328 (/lib64/libasan.so.6+0x37328)
#1 0x7f9e14913fb2 in _sub_I_00099_1 (../driver/lib/sample.so+0xaa8fb2)
#2 0x7f9e32e6f8dd in call_init.part.0 (/lib64/ld-linux-x86-64.so.2+0x108dd)
[2]:
#0 0x7f9e324a7328 (/lib64/libasan.so.6+0x37328)
#1 0x737dad in _sub_I_00099_1 (/home/newman/isc/ws/bind9/bin/named/named+0x737dad)
#2 0xe634bc in __libc_csu_init (/home/newman/isc/ws/bind9/bin/named/named+0xe634bc)
==2511090==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'dns_lctx' at log.c:69:33
Thread T13 created by T0 here:
#0 0x7f9e324c5f46 in __interceptor_pthread_create (/lib64/libasan.so.6+0x55f46)
#1 0xe5ecfa in isc_thread_create /home/newman/isc/ws/bind9/lib/isc/pthreads/thread.c:73
#2 0xe08c5a in isc_taskmgr_create /home/newman/isc/ws/bind9/lib/isc/task.c:1434
#3 0x45a841 in create_managers main.c:924
#4 0x45a841 in setup main.c:1265
#5 0x45a841 in main main.c:1568
#6 0x7f9e312541e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
==2511090==ABORTING
```
This problem does not manifest on `main`.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2450Follow-up from "Draft: Resolve "XoT xfrin""2022-05-23T09:10:40ZOndřej SurýFollow-up from "Draft: Resolve "XoT xfrin""The following discussion from !4571 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4571#note_189777):
> Rebased, squashed, pushed some suggestions, including CHAN...The following discussion from !4571 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4571#note_189777):
> Rebased, squashed, pushed some suggestions, including CHANGES, release note, documentation (which may not be very good, I'm not sure I have the TLS terminology correct), added setter/getter functions for a few things that were left out, and a few other bits and bobs.
>
> I think `dns_transport` should be `isc_transport` so that it can be used with the netmgr and as a parameter to `isc_tlsctx_createserver()`. I almost made that change already but decided to leave it for now so that it would be easier to review the changes I've already made (moving a file makes it harder to read diffs).
>
> We urgently MUST create key and cert files so that we can test with something other than "ephemeral" in the system tests. I suspect non-ephemeral configurations may not work for DoT currently, and I'm certain they don't work for XoT.
>
> I'm about to reveal some possibly-embarrassing ignorance about TLS: does it make _sense_ to reference `tls` statements in `primaries`? `isc_tlsctx_createclient()` doesn't take any parameters, so I'm not sure what `tls <anything-but-ephemeral>` would even do. (I already confirmed it's basically a no-op by configuring it with "tls whatever", a configuration that uses /dev/null for both key and cert files, and it worked fine.)
>
> So, is configuring client-side TLS parameters a thing we want to be able to do but haven't implemented yet? Or is it a thing nobody ever does, and we should revise the syntax so as not to imply it's possible?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2451netmgr/tlsdns.c: warning: ‘uv_try_write’ reading 16 bytes from a region of si...2021-04-07T14:38:08ZMichal Nowaknetmgr/tlsdns.c: warning: ‘uv_try_write’ reading 16 bytes from a region of size 8On Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
In function ‘tls_cycle_output’,
inlined from ‘tls_cycle’ at netmgr/tlsdns.c:1425:11:
netmgr/tlsdns.c:1351:23: warning: ‘uv_tr...On Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
In function ‘tls_cycle_output’,
inlined from ‘tls_cycle’ at netmgr/tlsdns.c:1425:11:
netmgr/tlsdns.c:1351:23: warning: ‘uv_try_write’ reading 16 bytes from a region of size 8 [-Wstringop-overread]
1351 | err = uv_try_write(&sock->uv_handle.stream, &sock->tls.senddata,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1352 | 1);
| ~~
netmgr/tlsdns.c: In function ‘tls_cycle’:
netmgr/tlsdns.c:1351:23: note: referencing argument 2 of type ‘const uv_buf_t *’
In file included from netmgr/tlsdns.c:14:
/usr/include/uv.h:520:15: note: in a call to function ‘uv_try_write’
520 | UV_EXTERN int uv_try_write(uv_stream_t* handle,
| ^~~~~~~~~~~~
In function ‘tls_cycle_output’,
inlined from ‘tls_cycle’ at netmgr/tlsdns.c:1425:11:
netmgr/tlsdns.c:1377:23: warning: ‘uv_write’ reading 16 bytes from a region of size 8 [-Wstringop-overread]
1377 | err = uv_write(&req->uv_req.write, &sock->uv_handle.stream,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1378 | &sock->tls.senddata, 1, tls_write_cb);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
netmgr/tlsdns.c: In function ‘tls_cycle’:
netmgr/tlsdns.c:1377:23: note: referencing argument 3 of type ‘const uv_buf_t *’
In file included from netmgr/tlsdns.c:14:
/usr/include/uv.h:509:15: note: in a call to function ‘uv_write’
509 | UV_EXTERN int uv_write(uv_write_t* req,
| ^~~~~~~~
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2452iterated_hash.c: warning: argument 1 of type ‘unsigned char[20]’ with mismatc...2021-05-28T10:00:42ZMichal Nowakiterated_hash.c: warning: argument 1 of type ‘unsigned char[20]’ with mismatched boundOn Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include...On Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include -I./include -I/home/newman/isc/ws/bind9/lib/dns/include -I../../lib/dns/include -D_REENTRANT -DOPENSSL -DPK11_LIB_LOCATION=\"undefined\" -D_GNU_SOURCE -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -fsanitize=address,undefined -DISC_MEM_USE_INTERNAL_MALLOC=0 -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -c iterated_hash.c
iterated_hash.c:21:33: warning: argument 1 of type ‘unsigned char[20]’ with mismatched bound [-Warray-parameter=]
21 | isc_iterated_hash(unsigned char out[ISC_SHA1_DIGESTLENGTH],
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from iterated_hash.c:18:
./include/isc/iterated_hash.h:33:37: note: previously declared as ‘unsigned char[155]’
33 | int isc_iterated_hash(unsigned char out[NSEC3_MAX_HASH_LENGTH],
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2453sha2.c: warning: argument with mismatched bound2021-12-02T13:57:47ZMichal Nowaksha2.c: warning: argument with mismatched boundOn Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include...On Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include -I./include -I/home/newman/isc/ws/bind9/lib/dns/include -I../../lib/dns/include -D_REENTRANT -DOPENSSL -DPK11_LIB_LOCATION=\"undefined\" -D_GNU_SOURCE -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -fsanitize=address,undefined -DISC_MEM_USE_INTERNAL_MALLOC=0 -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -c sha2.c
sha2.c:888:26: warning: argument 1 of type ‘uint8_t[]’ {aka ‘unsigned char[]’} with mismatched bound [-Warray-parameter=]
888 | isc_sha224_final(uint8_t digest[], isc_sha224_t *context) {
| ~~~~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:132:24: note: previously declared as ‘uint8_t[28]’ {aka ‘unsigned char[28]’}
132 | void isc_sha224_final (uint8_t[ISC_SHA224_DIGESTLENGTH], isc_sha224_t *);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sha2.c:1151:26: warning: argument 1 of type ‘uint8_t[]’ {aka ‘unsigned char[]’} with mismatched bound [-Warray-parameter=]
1151 | isc_sha256_final(uint8_t digest[], isc_sha256_t *context) {
| ~~~~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:139:24: note: previously declared as ‘uint8_t[32]’ {aka ‘unsigned char[32]’}
139 | void isc_sha256_final (uint8_t[ISC_SHA256_DIGESTLENGTH], isc_sha256_t *);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sha2.c:1514:31: warning: argument 1 of type ‘uint8_t[]’ {aka ‘unsigned char[]’} with mismatched bound [-Warray-parameter=]
1514 | void isc_sha512_final(uint8_t digest[], isc_sha512_t *context) {
| ~~~~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:153:24: note: previously declared as ‘uint8_t[64]’ {aka ‘unsigned char[64]’}
153 | void isc_sha512_final (uint8_t[ISC_SHA512_DIGESTLENGTH], isc_sha512_t *);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sha2.c:1567:26: warning: argument 1 of type ‘uint8_t[]’ {aka ‘unsigned char[]’} with mismatched bound [-Warray-parameter=]
1567 | isc_sha384_final(uint8_t digest[], isc_sha384_t *context) {
| ~~~~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:146:24: note: previously declared as ‘uint8_t[48]’ {aka ‘unsigned char[48]’}
146 | void isc_sha384_final (uint8_t[ISC_SHA384_DIGESTLENGTH], isc_sha384_t *);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sha2.c:1604:44: warning: argument 2 of type ‘char[]’ with mismatched bound [-Warray-parameter=]
1604 | isc_sha224_end(isc_sha224_t *context, char buffer[]) {
| ~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:133:39: note: previously declared as ‘char[57]’
133 | char *isc_sha224_end (isc_sha224_t *, char[ISC_SHA224_DIGESTSTRINGLENGTH]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sha2.c:1645:44: warning: argument 2 of type ‘char[]’ with mismatched bound [-Warray-parameter=]
1645 | isc_sha256_end(isc_sha256_t *context, char buffer[]) {
| ~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:140:39: note: previously declared as ‘char[65]’
140 | char *isc_sha256_end (isc_sha256_t *, char[ISC_SHA256_DIGESTSTRINGLENGTH]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sha2.c:1686:44: warning: argument 2 of type ‘char[]’ with mismatched bound [-Warray-parameter=]
1686 | isc_sha512_end(isc_sha512_t *context, char buffer[]) {
| ~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:154:39: note: previously declared as ‘char[129]’
154 | char *isc_sha512_end (isc_sha512_t *, char[ISC_SHA512_DIGESTSTRINGLENGTH]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sha2.c:1727:44: warning: argument 2 of type ‘char[]’ with mismatched bound [-Warray-parameter=]
1727 | isc_sha384_end(isc_sha384_t *context, char buffer[]) {
| ~~~~~^~~~~~~~
In file included from sha2.c:58:
./include/isc/sha2.h:147:39: note: previously declared as ‘char[97]’
147 | char *isc_sha384_end (isc_sha384_t *, char[ISC_SHA384_DIGESTSTRINGLENGTH]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2454print.c: warning: null destination pointer2021-12-23T10:48:02ZMichal Nowakprint.c: warning: null destination pointerOn Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I. -I./include -I./include -I/home/newman/isc/ws/b...On Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I. -I./include -I./include -I/home/newman/isc/ws/bind9/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -D_REENTRANT -D_GNU_SOURCE -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -fsanitize=address,undefined -DISC_MEM_USE_INTERNAL_MALLOC=0 -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -c print.c
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I. -I./include -I./include -I/home/newman/isc/ws/bind9/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -D_REENTRANT -D_GNU_SOURCE -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -fsanitize=address,undefined -DISC_MEM_USE_INTERNAL_MALLOC=0 -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks \
-DVERSION=\"9.11.27\" \
-DLIBINTERFACE=161 \
-DLIBREVISION=4 \
-DLIBAGE=0 \
-c ./version.c
print.c: In function ‘lwres__print_sprintf’:
print.c:32:9: warning: null destination pointer [-Wformat-overflow=]
32 | vsprintf(str, format, ap);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2455tcpdns_test.c: runtime error: load of misaligned address for type 'uint64_t'2021-03-19T16:22:26ZMichal Nowaktcpdns_test.c: runtime error: load of misaligned address for type 'uint64_t'On Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) and Buster GCC 8.3.0 with ASAN, I get following runtime errors:
```
[==========] Running 8 test(s).
[ RUN ] tcpdns_recv_one
tcpdns_test.c:481:8: runtime error: load of...On Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) and Buster GCC 8.3.0 with ASAN, I get following runtime errors:
```
[==========] Running 8 test(s).
[ RUN ] tcpdns_recv_one
tcpdns_test.c:481:8: runtime error: load of misaligned address 0x621000b4f10a for type 'uint64_t', which requires 8 byte alignment
0x621000b4f10a: note: pointer points here
00 00 00 08 e0 d9 8c c0 55 ec da b3 be be be be be be be be be be be be be be be be be be be be
^
[ OK ] tcpdns_recv_one
[ RUN ] tcpdns_recv_two
tcpdns_test.c:331:8: runtime error: load of misaligned address 0x6210012df50a for type 'uint64_t', which requires 8 byte alignment
0x6210012df50a: note: pointer points here
00 00 00 08 9d 1e 22 f3 c3 e2 6f 27 be be be be be be be be be be be be be be be be be be be be
^
[ OK ] tcpdns_recv_two
[ RUN ] tcpdns_noop
[ OK ] tcpdns_noop
[ RUN ] tcpdns_noresponse
[ OK ] tcpdns_noresponse
[ RUN ] tcpdns_recv_send
[ OK ] tcpdns_recv_send
[ RUN ] tcpdns_recv_half_send
[ OK ] tcpdns_recv_half_send
[ RUN ] tcpdns_half_recv_send
[ OK ] tcpdns_half_recv_send
[ RUN ] tcpdns_half_recv_half_send
[ OK ] tcpdns_half_recv_half_send
[==========] 8 test(s) run.
[ PASSED ] 8 test(s).
PASS tcpdns_test (exit status: 0)
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2456ThreadSanitizer: data race in __interceptor_fclose2021-03-04T14:07:41ZMichal NowakThreadSanitizer: data race in __interceptor_fcloseCustom experimental snapshot of gcc version 11.0.0 20210124 on Fedora 33 (as well as GCC 10.2.1 the default Fedora 33 compiler) identified following data race in `__interceptor_fclose` when the `rndc` system test was run:
```
WARNING: Th...Custom experimental snapshot of gcc version 11.0.0 20210124 on Fedora 33 (as well as GCC 10.2.1 the default Fedora 33 compiler) identified following data race in `__interceptor_fclose` when the `rndc` system test was run:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M1, write M2):
#0 fclose <null>
#1 _nss_files_getprotobyname_r <null>
#2 dns_rdata_fromtext lib/dns/rdata.c:965
#3 load_text lib/dns/master.c:1862
#4 dns_master_loadfile lib/dns/master.c:2703
#5 zone_startload lib/dns/zone.c:2716
#6 zone_load lib/dns/zone.c:2281
#7 zone_asyncload lib/dns/zone.c:2342
#8 dispatch lib/isc/task.c:1152
#9 run lib/isc/task.c:1344
#10 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2:
#0 epoll_ctl <null>
#1 uv__platform_invalidate_fd <null>
#2 uv_run <null>
#3 <null> <null>
Location is file descriptor 143 created by thread T2 at:
#0 accept4 <null>
#1 uv__accept <null>
#2 <null> <null>
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73
#2 isc_nm_start lib/isc/netmgr/netmgr.c:290
#3 create_managers bin/named/main.c:934
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
SUMMARY: ThreadSanitizer: data race in __interceptor_fclose
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2457ThreadSanitizer: data race in closedir2021-11-09T12:19:28ZMichal NowakThreadSanitizer: data race in closedirCustom experimental snapshot of gcc version 11.0.0 20210124 on Fedora 33 (as well as GCC 10.2.1 the default Fedora 33 compiler) identified following data race in `closedir` when `integrity`, `idna`, and few other system test were run:
``...Custom experimental snapshot of gcc version 11.0.0 20210124 on Fedora 33 (as well as GCC 10.2.1 the default Fedora 33 compiler) identified following data race in `closedir` when `integrity`, `idna`, and few other system test were run:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 closedir <null>
#1 isc_dir_close lib/isc/unix/dir.c:134
#2 dns_dnssec_findmatchingkeys lib/dns/dnssec.c:1526
#3 statefile_exist lib/dns/zone.c:5858
#4 dns_zone_secure_to_insecure lib/dns/zone.c:5905
#5 dns_zone_use_kasp lib/dns/zone.c:5917
#6 add_sigs lib/dns/zone.c:6901
#7 dns__zone_updatesigs lib/dns/zone.c:8225
#8 zone_nsec3chain lib/dns/zone.c:8921
#9 zone_maintenance lib/dns/zone.c:11211
#10 zone_timer lib/dns/zone.c:14674
#11 dispatch lib/isc/task.c:1152
#12 run lib/isc/task.c:1344
#13 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2:
#0 epoll_ctl <null>
#1 uv__platform_invalidate_fd <null>
#2 uv_run <null>
#3 <null> <null>
Location is file descriptor 143 created by thread T2 at:
#0 accept4 <null>
#1 uv__accept <null>
#2 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73
#2 isc_nm_start lib/isc/netmgr/netmgr.c:290
#3 create_managers bin/named/main.c:934
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
SUMMARY: ThreadSanitizer: data race in closedir
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2458Run ASAN and TSAN with latest stable GCC2021-10-27T13:13:53ZMichal NowakRun ASAN and TSAN with latest stable GCChttps://gitlab.isc.org/isc-projects/bind9/-/issues/2447 and https://gitlab.isc.org/isc-projects/bind9/-/issues/2449 were identified by Fedora's GCC 10.2.1 but not by GCC 8.3.0 from Debian Buster in out CI images when run with ASAN.
Ditt...https://gitlab.isc.org/isc-projects/bind9/-/issues/2447 and https://gitlab.isc.org/isc-projects/bind9/-/issues/2449 were identified by Fedora's GCC 10.2.1 but not by GCC 8.3.0 from Debian Buster in out CI images when run with ASAN.
Ditto for https://gitlab.isc.org/isc-projects/bind9/-/issues/2457 and https://gitlab.isc.org/isc-projects/bind9/-/issues/2456 when run with TSAN.
Given that `clang:asan` CI job uses the latest stable Clang, we should do the same with `gcc:asan` for GCC. Ditto for `gcc:tsan`.
The most straightforward way to do that is to use Fedora, Tumbleweed, or sid image.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2459double free or corruption (fasttop) in TLSDNS2021-04-03T21:27:20ZOndřej Surýdouble free or corruption (fasttop) in TLSDNSWhen `workers` is bumped from `1` to `3`, the unit test crashes with:
```
[==========] Running 8 test(s).
[ RUN ] tlsdns_recv_one
[ OK ] tlsdns_recv_one
[ RUN ] tlsdns_recv_two
[ OK ] tlsdns_recv_two
[ RUN ] t...When `workers` is bumped from `1` to `3`, the unit test crashes with:
```
[==========] Running 8 test(s).
[ RUN ] tlsdns_recv_one
[ OK ] tlsdns_recv_one
[ RUN ] tlsdns_recv_two
[ OK ] tlsdns_recv_two
[ RUN ] tlsdns_noop
[ OK ] tlsdns_noop
[ RUN ] tlsdns_noresponse
[ OK ] tlsdns_noresponse
[ RUN ] tlsdns_recv_send
*** Error in `/builds/isc-projects/bind9/lib/isc/tests/.libs/lt-tlsdns_test': double free or corruption (fasttop): 0x0000000001219fe0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7f4fa50b07f5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8038a)[0x7f4fa50b938a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f4fa50bd58c]
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0(CRYPTO_free+0x1d)[0x7f4fa43c00cd]
/lib/x86_64-linux-gnu/libssl.so.1.0.0(+0x2c7fd)[0x7f4fa47ce7fd]
/lib/x86_64-linux-gnu/libssl.so.1.0.0(+0x317de)[0x7f4fa47d37de]
/lib/x86_64-linux-gnu/libssl.so.1.0.0(+0x31f52)[0x7f4fa47d3f52]
/lib/x86_64-linux-gnu/libssl.so.1.0.0(+0x233de)[0x7f4fa47c53de]
/lib/x86_64-linux-gnu/libssl.so.1.0.0(+0x160c6)[0x7f4fa47b80c6]
/lib/x86_64-linux-gnu/libssl.so.1.0.0(+0x1ae0f)[0x7f4fa47bce0f]
/lib/x86_64-linux-gnu/libssl.so.1.0.0(+0x2a634)[0x7f4fa47cc634]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.9.so(+0x27e45)[0x7f4fa5647e45]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.9.so(+0x285f8)[0x7f4fa56485f8]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x12aff)[0x7f4fa4c20aff]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x1324c)[0x7f4fa4c2124c]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x18055)[0x7f4fa4c26055]
/usr/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x12c)[0x7f4fa4c17efc]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.9.so(+0x1e227)[0x7f4fa563e227]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f4fa540a6ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4fa51404dd]
======= Memory map: ========
00400000-00405000 r-xp 00000000 09:02 30680569 /builds/isc-projects/bind9/lib/isc/tests/.libs/lt-tlsdns_test
00604000-00605000 r--p 00004000 09:02 30680569 /builds/isc-projects/bind9/lib/isc/tests/.libs/lt-tlsdns_test
00605000-00606000 rw-p 00005000 09:02 30680569 /builds/isc-projects/bind9/lib/isc/tests/.libs/lt-tlsdns_test
011f9000-02440000 rw-p 00000000 00:00 0 [heap]
7f4f74000000-7f4f7414c000 rw-p 00000000 00:00 0
7f4f7414c000-7f4f78000000 ---p 00000000 00:00 0
7f4f78000000-7f4f7819f000 rw-p 00000000 00:00 0
7f4f7819f000-7f4f7c000000 ---p 00000000 00:00 0
7f4f7c000000-7f4f7c183000 rw-p 00000000 00:00 0
7f4f7c183000-7f4f80000000 ---p 00000000 00:00 0
7f4f80000000-7f4f801e7000 rw-p 00000000 00:00 0
7f4f801e7000-7f4f84000000 ---p 00000000 00:00 0
7f4f84000000-7f4f84193000 rw-p 00000000 00:00 0
7f4f84193000-7f4f88000000 ---p 00000000 00:00 0
7f4f88000000-7f4f881ab000 rw-p 00000000 00:00 0
7f4f881ab000-7f4f8c000000 ---p 00000000 00:00 0
7f4f8c000000-7f4f8c239000 rw-p 00000000 00:00 0
7f4f8c239000-7f4f90000000 ---p 00000000 00:00 0
7f4f90000000-7f4f901fa000 rw-p 00000000 00:00 0
7f4f901fa000-7f4f94000000 ---p 00000000 00:00 0
7f4f94000000-7f4f941e8000 rw-p 00000000 00:00 0
7f4f941e8000-7f4f98000000 ---p 00000000 00:00 0
7f4f9826d000-7f4f9826e000 ---p 00000000 00:00 0
7f4f9826e000-7f4f98a6e000 rw-p 00000000 00:00 0
7f4f98a6e000-7f4f98a6f000 ---p 00000000 00:00 0
7f4f98a6f000-7f4f9926f000 rw-p 00000000 00:00 0
7f4f9926f000-7f4f99270000 ---p 00000000 00:00 0
7f4f99270000-7f4f99a70000 rw-p 00000000 00:00 0
7f4f99a70000-7f4f99a71000 ---p 00000000 00:00 0
7f4f99a71000-7f4f9a271000 rw-p 00000000 00:00 0
7f4f9a271000-7f4f9a272000 ---p 00000000 00:00 0
7f4f9a272000-7f4f9aa72000 rw-p 00000000 00:00 0
7f4f9aa72000-7f4f9aa73000 ---p 00000000 00:00 0
7f4f9aa73000-7f4f9b273000 rw-p 00000000 00:00 0
7f4f9b3b4000-7f4f9b3f5000 rw-p 00000000 00:00 0
7f4f9b3f5000-7f4f9b3f6000 ---p 00000000 00:00 0
7f4f9b3f6000-7f4f9bbf6000 rw-p 00000000 00:00 0
7f4f9bfb9000-7f4f9bfba000 ---p 00000000 00:00 0
7f4f9bfba000-7f4f9c7ba000 rw-p 00000000 00:00 0
7f4f9c7ba000-7f4f9c7bb000 ---p 00000000 00:00 0
7f4f9c7bb000-7f4f9cfbb000 rw-p 00000000 00:00 0
7f4f9cfbb000-7f4f9cfbc000 ---p 00000000 00:00 0
7f4f9cfbc000-7f4f9d7e6000 rw-p 00000000 00:00 0
7f4f9d7e6000-7f4f9d7e7000 ---p 00000000 00:00 0
7f4f9d7e7000-7f4f9dfe7000 rw-p 00000000 00:00 0
7f4f9dfe7000-7f4f9dfe8000 ---p 00000000 00:00 0
7f4f9dfe8000-7f4f9e7e8000 rw-p 00000000 00:00 0
7f4f9e7e8000-7f4f9e7e9000 ---p 00000000 00:00 0
7f4f9e7e9000-7f4f9efe9000 rw-p 00000000 00:00 0
7f4f9efe9000-7f4f9efea000 ---p 00000000 00:00 0
7f4f9efea000-7f4f9f7ea000 rw-p 00000000 00:00 0
7f4f9f7ea000-7f4f9f7eb000 ---p 00000000 00:00 0
7f4f9f7eb000-7f4fa012c000 rw-p 00000000 00:00 0
7f4fa012c000-7f4fa012d000 ---p 00000000 00:00 0
7f4fa012d000-7f4fa0a6e000 rw-p 00000000 00:00 0
7f4fa0a6e000-7f4fa0a6f000 ---p 00000000 00:00 0
7f4fa0a6f000-7f4fa126f000 rw-p 00000000 00:00 0
7f4fa126f000-7f4fa1285000 r-xp 00000000 09:02 27936013 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4fa1285000-7f4fa1484000 ---p 00016000 09:02 27936013 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4fa1484000-7f4fa1485000 rw-p 00015000 09:02 27936013 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4fa1485000-7f4fa15f7000 r-xp 00000000 09:02 27936896 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4fa15f7000-7f4fa17f7000 ---p 00172000 09:02 27936896 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4fa17f7000-7f4fa1801000 r--p 00172000 09:02 27936896 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4fa1801000-7f4fa1803000 rw-p 0017c000 09:02 27936896 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4fa1803000-7f4fa1807000 rw-p 00000000 00:00 0
7f4fa1807000-7f4fa30bd000 r-xp 00000000 09:02 13116296 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f4fa30bd000-7f4fa32bc000 ---p 018b6000 09:02 13116296 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f4fa32bc000-7f4fa32bd000 r--p 018b5000 09:02 13116296 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f4fa32bd000-7f4fa32be000 rw-p 018b6000 09:02 13116296 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f4fa32be000-7f4fa33c6000 r-xp 00000000 09:02 27936025 /lib/x86_64-linux-gnu/libm-2.23.so
7f4fa33c6000-7f4fa35c5000 ---p 00108000 09:02 27936025 /lib/x86_64-linux-gnu/libm-2.23.so
7f4fa35c5000-7f4fa35c6000 r--p 00107000 09:02 27936025 /lib/x86_64-linux-gnu/libm-2.23.so
7f4fa35c6000-7f4fa35c7000 rw-p 00108000 09:02 27936025 /lib/x86_64-linux-gnu/libm-2.23.so
7f4fa35c7000-7f4fa35e8000 r-xp 00000000 09:02 27936024 /lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f4fa35e8000-7f4fa37e7000 ---p 00021000 09:02 27936024 /lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f4fa37e7000-7f4fa37e8000 r--p 00020000 09:02 27936024 /lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f4fa37e8000-7f4fa37e9000 rw-p 00021000 09:02 27936024 /lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f4fa37e9000-7f4fa3968000 r-xp 00000000 09:02 13116329 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f4fa3968000-7f4fa3b68000 ---p 0017f000 09:02 13116329 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f4fa3b68000-7f4fa3b78000 r--p 0017f000 09:02 13116329 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f4fa3b78000-7f4fa3b79000 rw-p 0018f000 09:02 13116329 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f4fa3b79000-7f4fa3b7d000 rw-p 00000000 00:00 0
7f4fa3b7d000-7f4fa3d2e000 r-xp 00000000 09:02 13116468 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3
7f4fa3d2e000-7f4fa3f2d000 ---p 001b1000 09:02 13116468 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3
7f4fa3f2d000-7f4fa3f35000 r--p 001b0000 09:02 13116468 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3
7f4fa3f35000-7f4fa3f37000 rw-p 001b8000 09:02 13116468 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3
7f4fa3f37000-7f4fa3f38000 rw-p 00000000 00:00 0
7f4fa3f38000-7f4fa3f42000 r-xp 00000000 09:02 13109967 /lib/x86_64-linux-gnu/libjson-c.so.2.0.0
7f4fa3f42000-7f4fa4141000 ---p 0000a000 09:02 13109967 /lib/x86_64-linux-gnu/libjson-c.so.2.0.0
7f4fa4141000-7f4fa4142000 r--p 00009000 09:02 13109967 /lib/x86_64-linux-gnu/libjson-c.so.2.0.0
7f4fa4142000-7f4fa4143000 rw-p 0000a000 09:02 13109967 /lib/x86_64-linux-gnu/libjson-c.so.2.0.0
7f4fa4143000-7f4fa415c000 r-xp 00000000 09:02 27936091 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4fa415c000-7f4fa435b000 ---p 00019000 09:02 27936091 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4fa435b000-7f4fa435c000 r--p 00018000 09:02 27936091 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4fa435c000-7f4fa435d000 rw-p 00019000 09:02 27936091 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4fa435d000-7f4fa4578000 r-xp 00000000 09:02 13108585 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4fa4578000-7f4fa4777000 ---p 0021b000 09:02 13108585 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4fa4777000-7f4fa4793000 r--p 0021a000 09:02 13108585 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4fa4793000-7f4fa479f000 rw-p 00236000 09:02 13108585 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4fa479f000-7f4fa47a2000 rw-p 00000000 00:00 0
7f4fa47a2000-7f4fa4800000 r-xp 00000000 09:02 13108588 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4fa4800000-7f4fa4a00000 ---p 0005e000 09:02 13108588 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4fa4a00000-7f4fa4a04000 r--p 0005e000 09:02 13108588 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4fa4a04000-7f4fa4a0a000 rw-p 00062000 09:02 13108588 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4fa4a0a000-7f4fa4a0d000 r-xp 00000000 09:02 27936005 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4fa4a0d000-7f4fa4c0c000 ---p 00003000 09:02 27936005 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4fa4c0c000-7f4fa4c0d000 r--p 00002000 09:02 27936005 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4fa4c0d000-7f4fa4c0e000 rw-p 00003000 09:02 27936005 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4fa4c0e000-7f4fa4c30000 r-xp 00000000 09:02 13116457 /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
7f4fa4c30000-7f4fa4e2f000 ---p 00022000 09:02 13116457 /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
7f4fa4e2f000-7f4fa4e30000 r--p 00021000 09:02 13116457 /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
7f4fa4e30000-7f4fa4e31000 rw-p 00022000 09:02 13116457 /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
7f4fa4e31000-7f4fa4e38000 r-xp 00000000 09:02 27936067 /lib/x86_64-linux-gnu/librt-2.23.so
7f4fa4e38000-7f4fa5037000 ---p 00007000 09:02 27936067 /lib/x86_64-linux-gnu/librt-2.23.so
7f4fa5037000-7f4fa5038000 r--p 00006000 09:02 27936067 /lib/x86_64-linux-gnu/librt-2.23.so
7f4fa5038000-7f4fa5039000 rw-p 00007000 09:02 27936067 /lib/x86_64-linux-gnu/librt-2.23.so
7f4fa5039000-7f4fa51f9000 r-xp 00000000 09:02 27935993 /lib/x86_64-linux-gnu/libc-2.23.so
7f4fa51f9000-7f4fa53f9000 ---p 001c0000 09:02 27935993 /lib/x86_64-linux-gnu/libc-2.23.so
7f4fa53f9000-7f4fa53fd000 r--p 001c0000 09:02 27935993 /lib/x86_64-linux-gnu/libc-2.23.so
7f4fa53fd000-7f4fa53ff000 rw-p 001c4000 09:02 27935993 /lib/x86_64-linux-gnu/libc-2.23.so
7f4fa53ff000-7f4fa5403000 rw-p 00000000 00:00 0
7f4fa5403000-7f4fa541b000 r-xp 00000000 09:02 27936061 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4fa541b000-7f4fa561a000 ---p 00018000 09:02 27936061 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4fa561a000-7f4fa561b000 r--p 00017000 09:02 27936061 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4fa561b000-7f4fa561c000 rw-p 00018000 09:02 27936061 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4fa561c000-7f4fa5620000 rw-p 00000000 00:00 0
7f4fa5620000-7f4fa56ad000 r-xp 00000000 09:02 30808868 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.9.so
7f4fa56ad000-7f4fa58ac000 ---p 0008d000 09:02 30808868 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.9.so
7f4fa58ac000-7f4fa58ad000 r--p 0008c000 09:02 30808868 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.9.so
7f4fa58ad000-7f4fa58af000 rw-p 0008d000 09:02 30808868 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.9.so
7f4fa58af000-7f4fa58b0000 rw-p 00000000 00:00 0
7f4fa58b0000-7f4fa58b8000 r-xp 00000000 09:02 13116242 /usr/lib/x86_64-linux-gnu/libcmocka.so.0.3.1
7f4fa58b8000-7f4fa5ab7000 ---p 00008000 09:02 13116242 /usr/lib/x86_64-linux-gnu/libcmocka.so.0.3.1
7f4fa5ab7000-7f4fa5ab8000 r--p 00007000 09:02 13116242 /usr/lib/x86_64-linux-gnu/libcmocka.so.0.3.1
7f4fa5ab8000-7f4fa5ab9000 rw-p 00008000 09:02 13116242 /usr/lib/x86_64-linux-gnu/libcmocka.so.0.3.1
7f4fa5ab9000-7f4fa5adf000 r-xp 00000000 09:02 27935973 /lib/x86_64-linux-gnu/ld-2.23.so
7f4fa5b08000-7f4fa5cd8000 rw-p 00000000 00:00 0
7f4fa5cdd000-7f4fa5cde000 rw-p 00000000 00:00 0
7f4fa5cde000-7f4fa5cdf000 r--p 00025000 09:02 27935973 /lib/x86_64-linux-gnu/ld-2.23.so
7f4fa5cdf000-7f4fa5ce0000 rw-p 00026000 09:02 27935973 /lib/x86_64-linux-gnu/ld-2.23.so
7f4fa5ce0000-7f4fa5ce1000 rw-p 00000000 00:00 0
7ffed79f6000-7ffed7a19000 rw-p 00000000 00:00 0 [stack]
7ffed7a24000-7ffed7a27000 r--p 00000000 00:00 0 [vvar]
7ffed7a27000-7ffed7a29000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
I:tlsdns_test:Core dump found: ./core.6729
D:tlsdns_test:backtrace from ./core.6729 start
[New LWP 6984]
[New LWP 6748]
[New LWP 6729]
[New LWP 6990]
[New LWP 6991]
[New LWP 6749]
[New LWP 6751]
[New LWP 6986]
[New LWP 6752]
[New LWP 6983]
[New LWP 6987]
[New LWP 6989]
[New LWP 6750]
[New LWP 6753]
[New LWP 6988]
[New LWP 6985]
[New LWP 6754]
[New LWP 6755]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/lib/isc/tests/.libs/lt-tlsdns_test'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4fa506e438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f4f9cfba700 (LWP 6984))]
Thread 18 (Thread 0x7f4f9d7bb700 (LWP 6755)):
#0 0x00007f4fa5140ad3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1 0x00007f4fa56568ee in netthread (uap=0x7f4fa5b08010) at unix/socket.c:3406
thread = 0x7f4fa5b08010
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9d7bb700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9d7bb700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979921274624, -5107297150600268856, 0, 140732516092383, 139979921275328, 17, 5152125370238710728, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#3 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 17 (Thread 0x7f4f9dfe6700 (LWP 6754)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1 0x00007f4fa5689fa0 in run (uap=0x7f4fa5cc7010) at timer.c:648
manager = 0x7f4fa5cc7010
now = {seconds = 1611929442, nanoseconds = 101211418}
result = <optimized out>
#2 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9dfe6700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9dfe6700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979929839360, -5107297150600268856, 0, 140732516093359, 139979929840064, 0, 5152126432706245576, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#3 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 16 (Thread 0x7f4f9bbf5700 (LWP 6985)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f4fa4c27b8a in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f4fa4c25f51 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#4 0x00007f4fa563e227 in nm_thread (worker0=0x121dd60) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x121dd60
mgr = 0x7f4fa5c8a138
#5 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9bbf5700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9bbf5700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979892152064, -5107297150600268856, 0, 140732516093359, 8388608, 26541696, 5152130289050006472, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#6 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 15 (Thread 0x7f4f9a270700 (LWP 6988)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f4fa4c27b8a in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f4fa4c25f51 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#4 0x00007f4fa563e227 in nm_thread (worker0=0x1826820) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x1826820
mgr = 0x7f4fa5c8a260
#5 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9a270700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9a270700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979865392896, -5107297150600268856, 0, 140732516093359, 139979865393600, 18922944, 5152126773082403784, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#6 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 14 (Thread 0x7f4f9e7e7700 (LWP 6753)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1 0x00007f4fa56838fe in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1057
task = 0x7f4fa5cc40f8
#2 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
threadid = <optimized out>
#3 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9e7e7700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9e7e7700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979938232064, -5107297150600268856, 0, 140732516093311, 139979938232768, 139980060770320, 5152118736661722056, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 13 (Thread 0x7f4f9ffea700 (LWP 6750)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f4fa4c27b8a in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f4fa4c25f51 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#4 0x00007f4fa563e227 in nm_thread (worker0=0x1246800) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x1246800
mgr = 0x7f4fa5c8a010
#5 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9ffea700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9ffea700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979963410176, -5107297150600268856, 0, 140732516093279, 139979963410880, 18922944, 5152122028217283528, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#6 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 12 (Thread 0x7f4f99a6f700 (LWP 6989)):
#0 0x00007f4fa510538d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1 0x00007f4fa5136e54 in usleep (useconds=useconds@entry=1000) at ../sysdeps/posix/usleep.c:32
ts = {tv_sec = 0, tv_nsec = 1000000}
#2 0x00000000004029b2 in tlsdns_connect_thread (arg=0x7f4fa5c8a260) at tlsdns_test.c:491
connect_nm = 0x7f4fa5c8a260
tlsdns_connect_addr = {type = {sa = {sa_family = 10, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 10, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, "\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {0, 0, 0, 16777216}}}, sin6_scope_id = 0}, ss = {ss_family = 10, __ss_padding = '\000' <repeats 21 times>, "\001", '\000' <repeats 95 times>, __ss_align = 0}, sunix = {sun_family = 10, sun_path = '\000' <repeats 21 times>, "\001", '\000' <repeats 85 times>}}, length = 28, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
result = <optimized out>
#3 0x00007f4fa540a6ba in start_thread (arg=0x7f4f99a6f700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f99a6f700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979857000192, -5107297150600268856, 0, 140732516093343, 139979857000896, 140732516093768, 5152134469126927304, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 11 (Thread 0x7f4f9aa71700 (LWP 6987)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f4fa4c27b8a in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f4fa4c25f51 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#4 0x00007f4fa563e227 in nm_thread (worker0=0x18263a0) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x18263a0
mgr = 0x7f4fa5c8a260
#5 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9aa71700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9aa71700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979873785600, -5107297150600268856, 0, 140732516093359, 139979873786304, 18922944, 5152127873130902472, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#6 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 10 (Thread 0x7f4f9c7b9700 (LWP 6983)):
#0 0x00007f4fa4426183 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#1 0x00007f4fa442593c in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#2 0x00007f4f8406a380 in ?? ()
No symbol table info available.
#3 0x00007f4f9c7b3fb0 in ?? ()
No symbol table info available.
#4 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 9 (Thread 0x7f4f9efe8700 (LWP 6752)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1 0x00007f4fa56838fe in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1057
task = 0x7f4fa5cc40f8
#2 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
threadid = <optimized out>
#3 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9efe8700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9efe8700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979946624768, -5107297150600268856, 0, 140732516093311, 139979946625472, 139980060770320, 5152119836710220744, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 8 (Thread 0x7f4f9b272700 (LWP 6986)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f4fa4c27b8a in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f4fa4c25f51 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#4 0x00007f4fa563e227 in nm_thread (worker0=0x1825f20) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x1825f20
mgr = 0x7f4fa5c8a260
#5 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9b272700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9b272700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979882178304, -5107297150600268856, 0, 140732516093359, 8388608, 27730928, 5152128981769335752, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#6 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 7 (Thread 0x7f4f9f7e9700 (LWP 6751)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1 0x00007f4fa56838fe in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1057
task = 0x7f4fa5cc40f8
#2 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
threadid = <optimized out>
#3 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9f7e9700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9f7e9700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979955017472, -5107297150600268856, 0, 140732516093311, 139979955018176, 139980060770320, 5152120936758719432, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 6 (Thread 0x7f4fa092c700 (LWP 6749)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f4fa4c27b8a in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f4fa4c25f51 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#4 0x00007f4fa563e227 in nm_thread (worker0=0x1246380) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x1246380
mgr = 0x7f4fa5c8a010
#5 0x00007f4fa540a6ba in start_thread (arg=0x7f4fa092c700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4fa092c700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979973117696, -5107297150600268856, 0, 140732516093279, 139979973118400, 18922944, 5152255860471968712, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#6 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 5 (Thread 0x7f4f98a6d700 (LWP 6991)):
#0 0x00007f4fa510538d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1 0x00007f4fa5136e54 in usleep (useconds=useconds@entry=1000) at ../sysdeps/posix/usleep.c:32
ts = {tv_sec = 0, tv_nsec = 1000000}
#2 0x00000000004029b2 in tlsdns_connect_thread (arg=0x7f4fa5c8a260) at tlsdns_test.c:491
connect_nm = 0x7f4fa5c8a260
tlsdns_connect_addr = {type = {sa = {sa_family = 10, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 10, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, "\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {0, 0, 0, 16777216}}}, sin6_scope_id = 0}, ss = {ss_family = 10, __ss_padding = '\000' <repeats 21 times>, "\001", '\000' <repeats 95 times>, __ss_align = 0}, sunix = {sun_family = 10, sun_path = '\000' <repeats 21 times>, "\001", '\000' <repeats 85 times>}}, length = 28, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
result = <optimized out>
#3 0x00007f4fa540a6ba in start_thread (arg=0x7f4f98a6d700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f98a6d700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979840214784, -5107297150600268856, 0, 140732516093343, 139979840215488, 140732516093784, 5152132269029929928, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 4 (Thread 0x7f4f9926e700 (LWP 6990)):
#0 0x00007f4fa510538d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1 0x00007f4fa5136e54 in usleep (useconds=useconds@entry=1000) at ../sysdeps/posix/usleep.c:32
ts = {tv_sec = 0, tv_nsec = 1000000}
#2 0x00000000004029b2 in tlsdns_connect_thread (arg=0x7f4fa5c8a260) at tlsdns_test.c:491
connect_nm = 0x7f4fa5c8a260
tlsdns_connect_addr = {type = {sa = {sa_family = 10, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 10, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, "\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {0, 0, 0, 16777216}}}, sin6_scope_id = 0}, ss = {ss_family = 10, __ss_padding = '\000' <repeats 21 times>, "\001", '\000' <repeats 95 times>, __ss_align = 0}, sunix = {sun_family = 10, sun_path = '\000' <repeats 21 times>, "\001", '\000' <repeats 85 times>}}, length = 28, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
result = <optimized out>
#3 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9926e700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9926e700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979848607488, -5107297150600268856, 0, 140732516093343, 139979848608192, 140732516093776, 5152133369078428616, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 3 (Thread 0x7f4fa5ccd8c0 (LWP 6729)):
#0 0x00007f4fa540b98d in pthread_join (threadid=139979857000192, thread_return=thread_return@entry=0x0) at pthread_join.c:90
__tid = 6989
_buffer = {__routine = 0x7f4fa540b8b0 <cleanup>, __arg = 0x7f4f99a6fd28, __canceltype = 0, __prev = 0x0}
oldtype = 0
pd = 0x7f4f99a6f700
self = 0x7f4fa5ccd8c0
result = 0
#1 0x00007f4fa568d1c0 in isc_thread_join (thread=<optimized out>, result=result@entry=0x0) at pthreads/thread.c:85
ret = <optimized out>
#2 0x000000000040236e in tlsdns_recv_send (state=<optimized out>) at tlsdns_test.c:646
nm = <optimized out>
listen_nm = <optimized out>
connect_nm = 0x7f4fa5c8a260
result = <optimized out>
listen_sock = 0x240eff0
threads = {139979857000192, 139979848607488, 139979840214784, 0 <repeats 29 times>}
#3 0x00007f4fa58b452f in ?? () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#4 0x00007f4fa58b4c6f in _cmocka_run_group_tests () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#5 0x0000000000401a3f in main () at tlsdns_test.c:831
tests = {{name = 0x403b02 "tlsdns_recv_one", test_func = 0x402ad0 <tlsdns_recv_one>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}, {name = 0x403b12 "tlsdns_recv_two", test_func = 0x402dc0 <tlsdns_recv_two>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}, {name = 0x403b22 "tlsdns_noop", test_func = 0x402710 <tlsdns_noop>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}, {name = 0x403b2e "tlsdns_noresponse", test_func = 0x4024c0 <tlsdns_noresponse>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}, {name = 0x403b40 "tlsdns_recv_send", test_func = 0x4022b0 <tlsdns_recv_send>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}, {name = 0x403b51 "tlsdns_recv_half_send", test_func = 0x402070 <tlsdns_recv_half_send>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}, {name = 0x403b67 "tlsdns_half_recv_send", test_func = 0x401e30 <tlsdns_half_recv_send>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}, {name = 0x403b7d "tlsdns_half_recv_half_send", test_func = 0x401bf0 <tlsdns_half_recv_half_send>, setup_func = 0x403360 <nm_setup>, teardown_func = 0x4032d0 <nm_teardown>}}
Thread 2 (Thread 0x7f4fa126e700 (LWP 6748)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f4fa4c27b8a in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f4fa4c25f51 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#4 0x00007f4fa563e227 in nm_thread (worker0=0x1245f00) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x1245f00
mgr = 0x7f4fa5c8a010
#5 0x00007f4fa540a6ba in start_thread (arg=0x7f4fa126e700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4fa126e700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979982825216, -5107297150600268856, 0, 140732516093279, 139979982825920, 18922944, 5152256514380739528, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#6 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
Thread 1 (Thread 0x7f4f9cfba700 (LWP 6984)):
#0 0x00007f4fa506e438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
resultvar = 0
pid = 6729
selftid = 6984
#1 0x00007f4fa507003a in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x372d303030373261, sa_sigaction = 0x372d303030373261}, sa_mask = {__val = {4121463499532887654, 8104277497642758192, 3472328296227680288, 2319406834570502192, 2314885530818453552, 2314885530818453536, 2314885530818453536, 8030873020029476896, 7378697629483797085, 3472328322907006566, 7378697629480071216, 3544392720173131366, 8104277497642758192, 3472328296227680288, 2319406834570502192, 2314885530818453552}}, sa_flags = 538976288, sa_restorer = 0x8a}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007f4fa50b07fa in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f4fa51c9f98 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
ap = <error reading variable ap (Attempt to dereference a generic pointer.)>
fd = 2
on_2 = <optimized out>
list = <optimized out>
nlist = <optimized out>
cp = <optimized out>
written = <optimized out>
#3 0x00007f4fa50b938a in malloc_printerr (ar_ptr=<optimized out>, ptr=<optimized out>, str=0x7f4fa51ca060 "double free or corruption (fasttop)", action=3) at malloc.c:5020
buf = "0000000001219fe0"
cp = <optimized out>
ar_ptr = <optimized out>
str = 0x7f4fa51ca060 "double free or corruption (fasttop)"
action = 3
#4 _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3874
size = <optimized out>
fb = <optimized out>
nextchunk = <optimized out>
nextsize = <optimized out>
nextinuse = <optimized out>
prevsize = <optimized out>
bck = <optimized out>
fwd = <optimized out>
errstr = <optimized out>
locked = <optimized out>
#5 0x00007f4fa50bd58c in __GI___libc_free (mem=<optimized out>) at malloc.c:2975
ar_ptr = <optimized out>
p = <optimized out>
hook = <optimized out>
#6 0x00007f4fa43c00cd in CRYPTO_free () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#7 0x00007f4fa47ce7fd in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#8 0x00007f4fa47d37de in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#9 0x00007f4fa47d3f52 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#10 0x00007f4fa47c53de in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#11 0x00007f4fa47b80c6 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#12 0x00007f4fa47bce0f in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#13 0x00007f4fa47cc634 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#14 0x00007f4fa5647e45 in tls_cycle_input (sock=0x7f4f7c040900) at netmgr/tlsdns.c:1200
result = 0
err = 0
rv = 1
#15 tls_cycle (sock=sock@entry=0x7f4f7c040900) at netmgr/tlsdns.c:1420
result = <optimized out>
#16 0x00007f4fa56485f8 in read_cb (stream=<optimized out>, nread=265, buf=0x7f4f9cfb59b0) at netmgr/tlsdns.c:1512
len = 265
result = <optimized out>
rv = <optimized out>
__func__ = "read_cb"
#17 0x00007f4fa4c20aff in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#18 0x00007f4fa4c2124c in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#19 0x00007f4fa4c26055 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#20 0x00007f4fa4c17efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#21 0x00007f4fa563e227 in nm_thread (worker0=0x121d8e0) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x121d8e0
mgr = 0x7f4fa5c8a138
#22 0x00007f4fa540a6ba in start_thread (arg=0x7f4f9cfba700) at pthread_create.c:333
__res = <optimized out>
pd = 0x7f4f9cfba700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139979912881920, -5107297150600268856, 0, 140732516093359, 8388608, 35313744, 5152124270190212040, 5152248593681298376}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#23 0x00007f4fa51404dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
D:tlsdns_test:backtrace from ./core.6729 end
FAIL tlsdns_test (exit status: 134)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2460CID 316784: Incorrect size passed to isc_mem_put2022-01-26T11:33:40ZMark AndrewsCID 316784: Incorrect size passed to isc_mem_putIf a invalid key name is specified in a masters list the wrong size is passed to `isc_mem_put`.
```
*** CID 316784: Incorrect expression (SIZEOF_MISMATCH)
/bin/named/config.c: 636 in named_config_getname()
630 isc_buffer_constini...If a invalid key name is specified in a masters list the wrong size is passed to `isc_mem_put`.
```
*** CID 316784: Incorrect expression (SIZEOF_MISMATCH)
/bin/named/config.c: 636 in named_config_getname()
630 isc_buffer_constinit(&b, objstr, strlen(objstr));
631 isc_buffer_add(&b, strlen(objstr));
632 dns_fixedname_init(&fname);
633 result = dns_name_fromtext(dns_fixedname_name(&fname), &b, dns_rootname,
634 0, NULL);
635 if (result != ISC_R_SUCCESS) {
CID 316784: Incorrect expression (SIZEOF_MISMATCH)
Passing argument "*namep" of type "dns_name_t *" and argument "8UL /* sizeof (*namep) */" to function "isc__mem_put" is suspicious.
636 isc_mem_put(mctx, *namep, sizeof(*namep));
637 *namep = NULL;
638 return (result);
639 }
640 dns_name_dup(dns_fixedname_name(&fname), mctx, *namep);
641
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2461Named-checkconf fails to detect illegal key names in primaries lists2021-08-26T00:00:21ZMark AndrewsNamed-checkconf fails to detect illegal key names in primaries listsThis was found when testing for #2460.
It also doesn't check for missing key names.
```
% bin/check/named-checkconf example.conf
% more example.conf
zone example {
type secondary;
primaries { 1.2.3.4 key a..b; };
};
%
```This was found when testing for #2460.
It also doesn't check for missing key names.
```
% bin/check/named-checkconf example.conf
% more example.conf
zone example {
type secondary;
primaries { 1.2.3.4 key a..b; };
};
%
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2462CID 316785: Error handling issues in dns_transport_list_new() (CHECKED_RETURN)2021-02-08T13:17:51ZMichal NowakCID 316785: Error handling issues in dns_transport_list_new() (CHECKED_RETURN)This came with the initial commit of the file (e488309da78d82e0c67990af264fcaa7b0ff0283):
```
*** CID 316785: Error handling issues (CHECKED_RETURN)
/lib/dns/transport.c: 292 in dns_transport_list_new()
286 dns_transport_list_t *
2...This came with the initial commit of the file (e488309da78d82e0c67990af264fcaa7b0ff0283):
```
*** CID 316785: Error handling issues (CHECKED_RETURN)
/lib/dns/transport.c: 292 in dns_transport_list_new()
286 dns_transport_list_t *
287 dns_transport_list_new(isc_mem_t *mctx) {
288 dns_transport_list_t *list = isc_mem_get(mctx, sizeof(*list));
289
290 *list = (dns_transport_list_t){ 0 };
291
>>> CID 316785: Error handling issues (CHECKED_RETURN)
>>> Calling "isc_rwlock_init" without checking return value (as is done elsewhere 17 out of 21 times).
292 isc_rwlock_init(&list->lock, 0, 0);
293
294 isc_mem_attach(mctx, &list->mctx);
295 isc_refcount_init(&list->references, 1);
296
297 list->magic = TRANSPORT_LIST_MAGIC;
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2464Possible double *free() in ns_interface_listentls()2021-03-08T11:15:01ZArtem BoldarievPossible double *free() in ns_interface_listentls()
There is a call to the `isc_tlsctx_free(&sslctx);` inside the body of the `ns_interface_listentls()`. I think, that this could potentially lead to a double `*free()`ing of the memory allocated by OpenSSL, because `sslctx` gets destroyed...
There is a call to the `isc_tlsctx_free(&sslctx);` inside the body of the `ns_interface_listentls()`. I think, that this could potentially lead to a double `*free()`ing of the memory allocated by OpenSSL, because `sslctx` gets destroyed during the `listenlist` destruction.
```
static isc_result_t
ns_interface_listentls(ns_interface_t *ifp, isc_tlsctx_t *sslctx) {
isc_result_t result;
result = isc_nm_listentlsdns(
ifp->mgr->nm, (isc_nmiface_t *)&ifp->addr, ns__client_request,
ifp, ns__client_tcpconn, ifp, sizeof(ns_client_t),
ifp->mgr->backlog, &ifp->mgr->sctx->tcpquota, sslctx,
&ifp->tcplistensocket);
if (result != ISC_R_SUCCESS) {
isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR,
"creating TLS socket: %s",
isc_result_totext(result));
isc_tlsctx_free(&sslctx);
return (result);
}
/*
* We call this now to update the tcp-highwater statistic:
* this is necessary because we are adding to the TCP quota just
* by listening.
*/
result = ns__client_tcpconn(NULL, ISC_R_SUCCESS, ifp);
if (result != ISC_R_SUCCESS) {
isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR,
"updating TCP stats: %s",
isc_result_totext(result));
}
return (result);
}
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2465Hang on service stop in uwait state starting in v9.16.112021-09-04T19:01:06ZMathieu ArnoldHang on service stop in uwait state starting in v9.16.11Issue from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253062
After upgrading from 9.16.10 to 9.16.11, the named service does not stop properly.
```
$ sudo service named stop
Stopping named.
Waiting for PIDS: %PID% <-- hangs here...Issue from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253062
After upgrading from 9.16.10 to 9.16.11, the named service does not stop properly.
```
$ sudo service named stop
Stopping named.
Waiting for PIDS: %PID% <-- hangs here indefinitely
```
```
$ procstat %PID%
PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM
%PID% 1 %PID% %PID% 0 26 obrienjw uwait FreeBSD ELF64 named
```
```
(lldb) bt
* thread #1, name = 'named'
* frame #0: 0x0000000800cc768c libthr.so.3`_umtx_op_err at _umtx_op_err.S:37
frame #1: 0x0000000800cc3591 libthr.so.3`join_common(pthread=0x0000000803585200, thread_return=0x0000000000000000, abstime=0x0000000000000000, peek=<unavailable>) at thr_join.c:147:9
frame #2: 0x000000000050dbef named`isc_thread_join + 31
frame #3: 0x00000000004fb49f named`isc_taskmgr_destroy + 607
frame #4: 0x00000000002dae31 named`main + 5841
frame #5: 0x00000000002d16b0 named`_start + 256
```
This is reproducible on two different 12.2R machines on which named is configured to act as a resolver. The hang does not occur on two other hosts on which named is configured to as as authoritative only. On the hosts where the hang occurs, the named logs contain lines of the form:
```
Jan 28 08:03:12 hostname named[%PID%]: creating IPv6 interface igb0 failed; interface ignored
```
These errors are absent on the hosts where the hang does not occur.
The 9.16.11 changelog includes a number of items related to threads and netmgr.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2466unable to convert libuv error code in udp_send_cb to isc_result: -90: message...2021-06-01T18:35:09ZJim Popovitchunable to convert libuv error code in udp_send_cb to isc_result: -90: message too longVersion: 9.16.11-2~bpo10+1 (Debian Stable Backports)
Kernel: 4.19.0-14-amd64 (Debian Stable)
These errors started appearing in syslog after the latest update to 9.16.11:
```
Feb 2 03:44:01 nsda named[634]: udp.c:595: unexpected error:
...Version: 9.16.11-2~bpo10+1 (Debian Stable Backports)
Kernel: 4.19.0-14-amd64 (Debian Stable)
These errors started appearing in syslog after the latest update to 9.16.11:
```
Feb 2 03:44:01 nsda named[634]: udp.c:595: unexpected error:
Feb 2 03:44:01 nsda named[634]: unable to convert libuv error code in udp_send_cb to isc_result: -90: message too long
```
My first thought was that it was being triggered by nefarious traffic, but several tests only showed normal DNS traffic.
Here is a tcpdump from that same time: (Note: 10.10.3.11/fd10:10:3::11 is the internal interfaces of the bind9 server nsda)
```
03:44:01.117113 IP 69.241.77.75.29944 > 10.10.3.11.53: 33501 [1au] A? d.ns.domainmail.org. (48)
03:44:01.117351 IP 10.10.3.11.53 > 69.241.77.75.29944: 33501*- 2/9/15 A 107.191.108.110, RRSIG (1357)
03:44:01.143210 IP 69.241.77.75.9974 > 10.10.3.11.53: 11710 [1au] A? b.ns.domainmail.org. (48)
03:44:01.143401 IP 10.10.3.11.53 > 69.241.77.75.9974: 11710*- 2/9/15 A 149.28.193.159, RRSIG (1357)
03:44:01.318600 IP 69.241.77.71.23952 > 10.10.3.11.53: 26903 [1au] A? a.ns.domainmail.org. (48)
03:44:01.318868 IP 10.10.3.11.53 > 69.241.77.71.23952: 26903*- 2/9/15 A 192.249.57.243, RRSIG (1357)
03:44:01.324725 IP 66.111.4.24.31115 > 10.10.3.11.53: 22388% [1au] A? b.ns.domainmail.org. (48)
03:44:01.324908 IP 10.10.3.11.53 > 66.111.4.24.31115: 22388*- 2/9/15 A 149.28.193.159, RRSIG (1357)
03:44:01.327499 IP 66.111.4.24.32637 > 10.10.3.11.53: 34737% [1au] A? d.ns.domainmail.org. (48)
03:44:01.327735 IP 10.10.3.11.53 > 66.111.4.24.32637: 34737*- 2/9/15 A 107.191.108.110, RRSIG (1357)
03:44:01.394857 IP 208.70.128.29.52101 > 10.10.3.11.53: 40050 [1au] TXT? ares._domainkey.domainmail.net. (59)
03:44:01.395092 IP 10.10.3.11.53 > 208.70.128.29.52101: 40050*- 1/8/9 TXT "v=DKIM1; h=sha256; k=rsa; s=email; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNWmypz1wHj9ctQtXDRdP5d7g8oUe6k0rGQ+ytNWSwelDqKVZYjYTpAJMTOv8fjW9EAuv0RMbnvht0Shsas0Hx2VFxA/UKg3FiJHn7STkzP7gEOUDg3BB6VmegE0AJlvEDF6IOxr/lqF59s3XmgABv8OykTkDb7hAPXf995wmda4slKlntKz/o+chaJsT7WEQk2HjDy9UVPvys" "yMvJfG6Fj7YdxhibgZcfcyomGA2FlNvpWVF4r/2FnBZT9VCYMMNKwYJd294rlwZIBiz1MYigJ3sqMEqUxp/ZTWXK8PidY/KrybkieEkB2pcK863kwniKpl5Nsh85weH1JiaU1rSwIDAQAB" (855)
03:44:01.471518 IP 69.241.77.85.50450 > 10.10.3.11.53: 29064 [1au] DNSKEY? domainmail.org. (43)
03:44:01.471678 IP 10.10.3.11.53 > 69.241.77.85.50450: 29064*- 2/0/1 DNSKEY, RRSIG (233)
03:44:01.560136 IP 20.186.78.216.50006 > 10.10.3.11.53: 59574 A? atlmm2.domainmail.NET. (39)
03:44:01.560341 IP 10.10.3.11.53 > 20.186.78.216.50006: 59574*- 1/8/8 A 192.249.57.242 (414)
03:44:01.571748 IP6 2603:10b0:514:8562:0:1:0:68.51100 > fd10:10:3::11.53: 53658 AAAA? atlmm2.domainmail.NET. (39)
03:44:01.571989 IP6 fd10:10:3::11.53 > 2603:10b0:514:8562:0:1:0:68.51100: 53658*- 1/8/8 AAAA 2604:180:0:6::242 (426)
03:44:01.608440 IP 76.96.47.197.37114 > 10.10.3.11.53: 16 [1au] TXT? _spf.domainmail.net. (48)
03:44:01.608452 IP 76.96.47.197.45007 > 10.10.3.11.53: 30758 [1au] A? a.ns.domainmail.net. (48)
03:44:01.608459 IP 76.96.47.197.64094 > 10.10.3.11.53: 38572 [1au] A? a.ns.domainmail.org. (48)
03:44:01.608748 IP 10.10.3.11.53 > 76.96.47.197.45007: 30758*- 2/9/15 A 192.249.57.244, RRSIG (1357)
03:44:01.608974 IP 10.10.3.11.53 > 76.96.47.197.64094: 38572*- 2/9/15 A 192.249.57.243, RRSIG (1357)
03:44:01.720424 IP6 2607:f8b0:4002:c11::108.40833 > fd10:10:3::11.53: 44325 [1au] AAAA? c.ns.domainmail.org. (59)
03:44:01.720637 IP6 fd10:10:3::11.53 > 2607:f8b0:4002:c11::108.40833: 44325*- 1/8/8 AAAA 2001:19f0:5001:3233::ca (392)
03:44:01.720854 IP6 2607:f8b0:4002:c02::10e.62330 > fd10:10:3::11.53: 51659 [1au] A? a.ns.domainmail.org. (59)
03:44:01.720964 IP6 fd10:10:3::11.53 > 2607:f8b0:4002:c02::10e.62330: 51659*- 1/8/8 A 192.249.57.243 (392)
03:44:01.781400 IP 104.208.223.97.63572 > 10.10.3.11.53: 54701 TXT? ares._domainkey.domainmail.NET. (48)
03:44:01.781639 IP 10.10.3.11.53 > 104.208.223.97.63572: 54701*-| 0/0/0 (48)
03:44:01.793719 IP 104.208.223.97.41874 > 10.10.3.11.53: Flags [S], seq 3112505391, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
03:44:01.793769 IP 10.10.3.11.53 > 104.208.223.97.41874: Flags [S.], seq 1738835983, ack 3112505392, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
03:44:01.804587 IP 104.208.223.97.41874 > 10.10.3.11.53: Flags [.], ack 1, win 2053, length 0
03:44:01.804752 IP 104.208.223.97.41874 > 10.10.3.11.53: Flags [P.], seq 1:51, ack 1, win 2053, length 50 54701 TXT? ares._domainkey.domainmail.NET. (48)
03:44:01.804807 IP 10.10.3.11.53 > 104.208.223.97.41874: Flags [.], ack 51, win 502, length 0
03:44:01.805029 IP 10.10.3.11.53 > 104.208.223.97.41874: Flags [P.], seq 1:877, ack 51, win 502, length 876 54701*- 1/8/8 TXT "v=DKIM1; h=sha256; k=rsa; s=email; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNWmypz1wHj9ctQtXDRdP5d7g8oUe6k0rGQ+ytNWSwelDqKVZYjYTpAJMTOv8fjW9EAuv0RMbnvht0Shsas0Hx2VFxA/UKg3FiJHn7STkzP7gEOUDg3BB6VmegE0AJlvEDF6IOxr/lqF59s3XmgABv8OykTkDb7hAPXf995wmda4slKlntKz/o+chaJsT7WEQk2HjDy9UVPvys" "yMvJfG6Fj7YdxhibgZcfcyomGA2FlNvpWVF4r/2FnBZT9VCYMMNKwYJd294rlwZIBiz1MYigJ3sqMEqUxp/ZTWXK8PidY/KrybkieEkB2pcK863kwniKpl5Nsh85weH1JiaU1rSwIDAQAB" (874)
03:44:01.827599 IP 3.228.170.24.37482 > 10.10.3.11.53: 5466% [1au] A? d.ns.domainmail.org. (48)
03:44:01.827838 IP 10.10.3.11.53 > 3.228.170.24.37482: 5466*- 2/9/13 A 107.191.108.110, RRSIG (1137)
03:44:01.863034 IP 104.208.223.97.41874 > 10.10.3.11.53: Flags [.], ack 877, win 2049, length 0
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2467[CVE-2021-25214] A broken inbound incremental zone update (IXFR) can cause na...2021-06-10T06:41:11ZBrian Conry[CVE-2021-25214] A broken inbound incremental zone update (IXFR) can cause named to terminate unexpectedly### CVE-specific actions
- [x] [Assign a CVE identifier](#note_190775)
- [x] [Determine CVSS score](#note_190773)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_196136)
- [x] [De...### CVE-specific actions
- [x] [Assign a CVE identifier](#note_190775)
- [x] [Determine CVSS score](#note_190773)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_196136)
- [x] [Determine whether workarounds for the problem exists](#note_196145)
- [x] Prepare a detailed description of the problem which should include the following by default:
- [instructions for reproducing the problem (a system test is good enough)](isc-private/bind9!264)
- [explanation of code flow which triggers the problem (a system test is *not* good enough)](#note_196157)
- [x] [Prepare a private merge request containing the following items in separate commits:](isc-private/bind9!239)
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle: isc-private/bind9#36
- [x] Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
---
A customer has reported the following crash in 9.11.22-S1:
```
02-Feb-2021 10:00:48.027 general: critical: zone.c:12360: fatal error:
02-Feb-2021 10:00:48.027 general: critical: RUNTIME_CHECK(dbsoacount > 0U) failed
02-Feb-2021 10:00:48.027 general: critical: exiting (due to fatal error in library)
```
At this time the only other information known is that happened on one of the "DNS servers which are used for ENUM".April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2468CID 318094: Null pointer dereferences (REVERSE_INULL)2021-03-02T13:51:47ZMark AndrewsCID 318094: Null pointer dereferences (REVERSE_INULL)Remove redundant `version == NULL` check. This should have been included in 3b11bacbb7b92aa2c1043ad27f8fd89763ed984b.
```
*** CID 318094: Null pointer dereferences (REVERSE_INULL)
/lib/dns/rbtdb.c: 1389 in newversion()
1383 vers...Remove redundant `version == NULL` check. This should have been included in 3b11bacbb7b92aa2c1043ad27f8fd89763ed984b.
```
*** CID 318094: Null pointer dereferences (REVERSE_INULL)
/lib/dns/rbtdb.c: 1389 in newversion()
1383 version->xfrsize = rbtdb->current_version->xfrsize;
1384 RWUNLOCK(&rbtdb->current_version->rwlock, isc_rwlocktype_read);
1385 rbtdb->next_serial++;
1386 rbtdb->future_version = version;
1387 RBTDB_UNLOCK(&rbtdb->lock, isc_rwlocktype_write);
1388
CID 318094: Null pointer dereferences (REVERSE_INULL)
Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1389 if (version == NULL) {
1390 return (result);
1391 }
1392
1393 *versionp = version;
1394
```February 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/2469CID 281461: untrusted loop bound2021-02-08T03:05:44ZMark AndrewsCID 281461: untrusted loop boundAttempt to silence false positive
```
213 isc_region_consume(&region, 2); /* hit length + algorithm */
9. tainted_return_value: Function uint16_fromregion returns tainted data. [show details]
10. tainted_data_transitive: ...Attempt to silence false positive
```
213 isc_region_consume(®ion, 2); /* hit length + algorithm */
9. tainted_return_value: Function uint16_fromregion returns tainted data. [show details]
10. tainted_data_transitive: Call to function uint16_fromregion with tainted argument *region.base returns tainted data.
11. tainted_return_value: Function uint16_fromregion returns tainted data.
12. tainted_data_transitive: Call to function uint16_fromregion with tainted argument *region.base returns tainted data.
13. var_assign: Assigning: key_len = uint16_fromregion(®ion), which taints key_len.
214 key_len = uint16_fromregion(®ion);
14. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
15. Condition key_len == 0, taking false branch.
215 if (key_len == 0) {
216 RETERR(DNS_R_FORMERR);
217 }
16. Condition !!(_r->length >= _l), taking true branch.
17. Condition !!(_r->length >= _l), taking true branch.
218 isc_region_consume(®ion, 2);
18. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
19. Condition region.length < (unsigned int)(hit_len + key_len), taking false branch.
219 if (region.length < (unsigned)(hit_len + key_len)) {
220 RETERR(DNS_R_FORMERR);
221 }
222
20. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
21. Condition _r != 0, taking false branch.
223 RETERR(mem_tobuffer(target, rr.base, 4 + hit_len + key_len));
22. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
23. var_assign_var: Compound assignment involving tainted variable 4 + hit_len + key_len to variable source->current taints source->current.
224 isc_buffer_forward(source, 4 + hit_len + key_len);
225
226 dns_decompress_setmethods(dctx, DNS_COMPRESS_NONE);
CID 281461 (#1 of 1): Untrusted loop bound (TAINTED_SCALAR)
24. tainted_data: Using tainted variable source->active - source->current as a loop boundary.
Ensure that tainted values are properly sanitized, by checking that their values are within a permissible range.
227 while (isc_buffer_activelength(source) > 0) {
228 dns_name_init(&name, NULL);
229 RETERR(dns_name_fromwire(&name, source, dctx, options, target));
230 }
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2470Split the tsig-keygen/ddns-confgen man page into two separate documents2022-06-14T20:57:25ZMichał KępieńSplit the tsig-keygen/ddns-confgen man page into two separate documentsWhile `tsig-keygen` and `ddns-confgen` are effectively the same binary,
their command line parameters are rather different and half of them are
specific to `ddns-confgen`. The user does not need to be aware that the
same binary is used ...While `tsig-keygen` and `ddns-confgen` are effectively the same binary,
their command line parameters are rather different and half of them are
specific to `ddns-confgen`. The user does not need to be aware that the
same binary is used "behind the scenes" for two tools serving quite
different purposes - and keeping a combined man page around [causes
headaches][1] while also not giving us many benefits.
Given the above, it seems sensible to have two separate man pages for
`tsig-keygen` and `ddns-confgen`.
[1]: 84862e96c1fcff6e7c1ca31884e2fad921afa4f7April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2471Write test for "three is a crowd" rollover bug2023-07-06T08:55:44ZMatthijs Mekkingmatthijs@isc.orgWrite test for "three is a crowd" rollover bugWrite a test for #2375Write a test for #2375July 2023 (9.18.17, 9.18.17-S1, 9.19.15)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1890automation of DS Record submit to registrar/parent, integrated with 'new' ka...2021-10-05T14:46:01Zpgndautomation of DS Record submit to registrar/parent, integrated with 'new' kasp/dnssec-policy support in bind### Description
i'm migrating/implementing the new `dnssec-policy` usage & KASP workflow in my bind 9.16.3.
the new policy does a nice job of streamlining the signing/key mgmt.
after key generation/rotation, the 'last step' is subm...### Description
i'm migrating/implementing the new `dnssec-policy` usage & KASP workflow in my bind 9.16.3.
the new policy does a nice job of streamlining the signing/key mgmt.
after key generation/rotation, the 'last step' is submitting new/changed DS Records to the relevant registrar
i'd like to automate the process of submitting generated DS Records to the registrar/parent using a capable registrar's DNSSEC API.
as i understand, there is neither any mechanism in Bind for automating the DS Record submit, nor is there
an external hook mechanism to external scripts that can handle the task.
offline, it's been suggested to me that with the current version of bind, a 'best' approach would be to write a simple script that checks for the existence of the CDS/CDNSKEY RRset in each signed zone.
then, when a new record is added, trigger a submission of the DS to the parent. and, similarly, when a record is removed, trigger a withdrawal of the DS.
rather than re-inventing the wheel ... i'm guessing i'm not the only one who'd like to automate this.
### Request
an additional response on ML
> This is where we need to get the registrars to follow standards. They are written
> so everyone doesn’t have to cobble together ad-hoc solutions. Hourly scans of all
> the DNSSEC delegations by the registrars would do.
>
> Personally I prefer push solutions but I couldn’t get the IETF to agree.
> https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04
sounds reasonable. at very least, better than nothing.
in the absence of a standards-based solution, integrated in bind's dnssec-policy/kasp feature set, an option for script/execution hooks in bind to external scripts, would be a good 1st step, even if ad-hoc
e.g., "if when change in DS Record in local bind, then fire this external script which will manage the DS submit/withdraw via API to registrar"
failing any/all of that^, a well documented example of a completely de-coupled solution, independent of bind itself, ideally registrar/API agnostic, but demonstrated to work, would be useful.
that's of course doable -- but again, ad-hoc, and seems a step backwards given the nice progress with dnssec-policy/kasp simplifications in recent versions.
### Links / referencesBIND 9.19.xMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2212NSEC3 Resalt2023-09-07T05:10:15ZMatthijs Mekkingmatthijs@isc.orgNSEC3 ResaltAdd an option to resalt `nsec3-resalt duration`. If not set, or set to 0, do not resalt. Otherwise, schedule a resalt task, similar to `zone_rekey`. This option should be checked for range (i.e. don't resalt every minute).Add an option to resalt `nsec3-resalt duration`. If not set, or set to 0, do not resalt. Otherwise, schedule a resalt task, similar to `zone_rekey`. This option should be checked for range (i.e. don't resalt every minute).Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2472too easy to configure unencrypted DoH2021-03-18T15:04:59ZEvan Hunttoo easy to configure unencrypted DoHUnencrypted DoH sessions may be useful in some operational circumstances (for instance, when load-sharing behind a reverse proxy), but those cases are not typical. If someone omits the `tls` parameter in a `listen-on` statement that spec...Unencrypted DoH sessions may be useful in some operational circumstances (for instance, when load-sharing behind a reverse proxy), but those cases are not typical. If someone omits the `tls` parameter in a `listen-on` statement that specifies `http`, it's more likely they did so by mistake than on purpose. We should prevent this by requiring a `tls` parameter whenever `http` is used. If encryption is not wanted, `tls none` can be used.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2473Run respdiff as part of daily runs2021-07-22T12:31:52ZMichal NowakRun respdiff as part of daily runsRespdiff should be run as part of daily runs to be aware of any problems we might face at release time, e.g. https://gitlab.isc.org/isc-private/bind9/-/jobs/1465251.Respdiff should be run as part of daily runs to be aware of any problems we might face at release time, e.g. https://gitlab.isc.org/isc-private/bind9/-/jobs/1465251.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2474DoH: Segmentation fault in doh_test on FreeBSD 11.42021-04-06T12:10:02ZOndřej SurýDoH: Segmentation fault in doh_test on FreeBSD 11.4```
(gdb) bt full
#0 0x00000008028922d6 in memcpy () from /lib/libc.so.7
No symbol table info available.
#1 0x00000008022f2d26 in ?? () from /usr/local/lib/libnghttp2.so.14
No symbol table info available.
#2 0x0000000802300552 in ?? (...```
(gdb) bt full
#0 0x00000008028922d6 in memcpy () from /lib/libc.so.7
No symbol table info available.
#1 0x00000008022f2d26 in ?? () from /usr/local/lib/libnghttp2.so.14
No symbol table info available.
#2 0x0000000802300552 in ?? () from /usr/local/lib/libnghttp2.so.14
No symbol table info available.
#3 0x000000080230113c in nghttp2_submit_response () from /usr/local/lib/libnghttp2.so.14
No symbol table info available.
#4 0x000000000040c5e2 in server_send_response (ngsession=<optimized out>, stream_id=0, nva=0x816c00654, nvlen=<error reading variable: Cannot access memory at address 0x28>, socket=<optimized out>) at ./../netmgr/http.c:1516
data_prd = {source = {fd = 379809792, ptr = 0x816a37000}, read_callback = 0x40bc00 <server_read_callback>}
rv = <optimized out>
#5 server_send_error_response (error=<optimized out>, ngsession=<optimized out>, socket=<optimized out>) at ./../netmgr/http.c:1555
i = <optimized out>
rv = <optimized out>
#6 0x000000000040c14d in server_on_header_callback (session=0x8040ae000, frame=<optimized out>, name=0x80230afc4 ":path", namelen=<optimized out>, value=<optimized out>, valuelen=10, flags=0 '\000', user_data=0x816a0d880)
at ./../netmgr/http.c:1472
code = ISC_HTTP_ERROR_SUCCESS
socket = <optimized out>
path = {<optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>}
method = {<optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>}
scheme = {<optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>}
accept = {<optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>, <optimized out>}
content_length = {<optimized out> <repeats 15 times>}
content_type = {<optimized out> <repeats 13 times>}
#7 0x00000008022fd5de in nghttp2_session_mem_recv () from /usr/local/lib/libnghttp2.so.14
No symbol table info available.
#8 0x000000000040b680 in https_readcb (handle=<optimized out>, result=<optimized out>, region=0x7fffdf7f1950, data=0x816a0d880) at ./../netmgr/http.c:700
session = 0x816a0d880
readlen = <optimized out>
#9 0x0000000800a7484b in tls_do_bio (sock=0x816a37e00) at netmgr/tlsstream.c:204
dregion = {base = 0x8038ac760 "", length = 70}
region = {base = 0x8038ac760 "", length = 70}
buf = ""
tls_err = <error reading variable tls_err (Cannot access memory at address 0x0)>
result = <error reading variable result (Cannot access memory at address 0x0)>
pending = 70
rv = 381683284
req = <optimized out>
#10 0x0000000800a6521b in process_netievent (worker=0x803879b00, ievent=0x809828ac8) at netmgr/netmgr.c:723
No locals.
#11 0x0000000800a61a28 in process_queue (worker=0x803879b00, queue=0x80387ab80) at netmgr/netmgr.c:765
ievent = 0x816c00654
#12 process_normal_queue (worker=0x803879b00) at netmgr/netmgr.c:651
No locals.
#13 process_queues (worker=0x803879b00) at netmgr/netmgr.c:659
No locals.
#14 async_cb (handle=<optimized out>) at netmgr/netmgr.c:617
worker = 0x803879b00
#15 0x00000008014a221a in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#16 0x00000008014b32bb in uv.io_poll () from /usr/local/lib/libuv.so.1
No symbol table info available.
#17 0x00000008014a2791 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#18 0x0000000800a61aab in nm_thread (worker0=0x803879b00) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x803879b00
mgr = <optimized out>
#19 0x000000080252108c in thread_start (curthread=0x803818a00) at /usr/src/lib/libthr/thread/thr_create.c:290
set = {__bits = {0, 0, 3758088152, 32767}}
#20 0x0000000000000000 in ?? ()
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2475ARM documentation for no-case-compress ACL seems inconsistent2023-11-01T07:35:08ZBrian ConryARM documentation for no-case-compress ACL seems inconsistent <para>
Specifies a list of addresses which require responses
to use case-insensitive compression. This ACL can be
used when <command>named</command> needs to work wit... <para>
Specifies a list of addresses which require responses
to use case-insensitive compression. This ACL can be
used when <command>named</command> needs to work with
clients that do not comply with the requirement in RFC
1034 to use case-insensitive name comparisons when
checking for matching domain names.
</para>
<para>
If left undefined, the ACL defaults to
<command>none</command>: case-insensitive compression
will be used for all clients. If the ACL is defined and
matches a client, then case will be ignored when
compressing domain names in DNS responses sent to that
client.
</para>
The first paragraph says that it "Specifies a list of addresses which require responses to use case-insensitive compression." while the second paragraph says the opposite, that when the ACL has a value of "none" (meaning that no addresses match) that "case-insensitive compression will be used for all clients."
Based on a code analysis by @pspacek, I believe that the extent of the inconsistency may be the phrase "If left undefined, the ACL defaults to `none`: **case-insensitive** compression will be used for all clients.", which seems like it should read instead "If left undefined, the ACL defaults to `none`: **case-sensitive** compression will be used for all clients."
Testing is recommended to validate behavior before making changes.https://gitlab.isc.org/isc-projects/bind9/-/issues/2476"statschannel" system test setup may fail on slow systems2023-11-02T16:26:05ZMichał Kępień"statschannel" system test setup may fail on slow systemshttps://gitlab.isc.org/isc-private/bind9/-/jobs/1465497
```
S:statschannel:2021-02-04T12:09:33+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12500 - 12599
I:statschannel:setup.sh script failed
...https://gitlab.isc.org/isc-private/bind9/-/jobs/1465497
```
S:statschannel:2021-02-04T12:09:33+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12500 - 12599
I:statschannel:setup.sh script failed
R:statschannel:FAIL
E:statschannel:2021-02-04T12:09:40+0000
```
Based on the job artifacts, it looks like test setup failed in
`ns2/sign.sh`, specifically on line 37, where the `manykeys` zone is
signed:
```sh
"$SIGNER" -S -x -O full -e "now"+1s -o "$zone" -f "$zonefile" "$infile" > "signzone.out.$zone" 2>&1
```
`bin/tests/system/statschannel/ns2/signzone.out.manykeys.` contains:
```
No self-signed KSK DNSKEY found
Fetching manykeys/RSASHA256/51699 (ZSK) from key repository.
Fetching manykeys/ECDSAP256SHA256/19507 (KSK) from key repository.
Fetching manykeys/RSASHA256/24910 (KSK) from key repository.
Fetching manykeys/ECDSAP384SHA384/27336 (ZSK) from key repository.
Fetching manykeys/ECDSAP256SHA256/61056 (ZSK) from key repository.
Fetching manykeys/ECDSAP384SHA384/43460 (KSK) from key repository.
Zone verification failed (failure)
```
Since the `dnssec-signzone` invocation includes `-e now+1s` (signatures
are supposed to expire one second after `dnssec-signzone` startup) and
this failure is intermittent, what I believe happened here is that
`dnssec-signzone` ran long enough for at least some of the signatures to
already have become expired when zone verification took place.
The simplest solution here seems to be to employ the `-P` switch for
`dnssec-signzone`, which is something we routinely do in system tests.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2477ERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds ...2021-03-10T11:16:57ZOndřej SurýERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds maximum supported size of 0x10000000000Something weird has happened in the doh_test when run under TSAN:
```
ERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds maximum supported size of 0x10000000000
#0 __interceptor_malloc ../../../../src/libsa...Something weird has happened in the doh_test when run under TSAN:
```
ERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds maximum supported size of 0x10000000000
#0 __interceptor_malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:655 (libtsan.so.0+0x31779)
#1 <null> <null> (libnghttp2.so.14+0x793f)
#2 server_send_error_response ../netmgr/http.c:1555 (doh_test+0x9eaf)
#3 server_on_header_callback ../netmgr/http.c:1472 (doh_test+0x14601)
#4 nghttp2_session_mem_recv <null> (libnghttp2.so.14+0x11f89)
#5 tls_do_bio netmgr/tlsstream.c:204 (libisc-9.17.9.so+0x4066b)
#6 isc__nm_async_tlsdobio netmgr/tlsstream.c:927 (libisc-9.17.9.so+0x4380a)
#7 process_netievent netmgr/netmgr.c:723 (libisc-9.17.9.so+0x2d423)
#8 process_queue netmgr/netmgr.c:765 (libisc-9.17.9.so+0x2d801)
#9 process_normal_queue netmgr/netmgr.c:651 (libisc-9.17.9.so+0x2d88f)
#10 process_queues netmgr/netmgr.c:659 (libisc-9.17.9.so+0x2d8d2)
#11 async_cb netmgr/netmgr.c:617 (libisc-9.17.9.so+0x2dcf7)
#12 <null> <null> (libuv.so.1+0xed7c)
#13 __tsan_thread_start_func ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:959 (libtsan.so.0+0x2e3cf)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2478Consider making the build-time dependency on nghttp2 optional2021-07-14T18:34:16ZMichał KępieńConsider making the build-time dependency on nghttp2 optionalRight now, the `main` branch needs nghttp2 to be available in order for
BIND 9 to build at all. Since nghttp2 is only required for
DNS-over-HTTPS (DoH) support - which we promised to backport to BIND
9.16 at some point - it looks slight...Right now, the `main` branch needs nghttp2 to be available in order for
BIND 9 to build at all. Since nghttp2 is only required for
DNS-over-HTTPS (DoH) support - which we promised to backport to BIND
9.16 at some point - it looks slightly harsh to have a new, hard
requirement on another library (even if it is a rather ubiquitous and
not version-picky one), especially in light of a future BIND 9.16
backport.
We should probably discuss whether nghttp2 should be considered
mandatory for:
- BIND 9.17+
- ~~BIND 9.16~~[^1]
Any changes in this area should be "announced" in:
- `README.md`
- `PLATFORMS.md`
- release notes.
[^1]: Not a possibility any more as it has been decided that DoH support
will not be backported to BIND 9.16.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/2479Comparison of integer expressions of different signedness in netmgr/http.c2021-03-04T10:04:33ZMichal NowakComparison of integer expressions of different signedness in netmgr/http.cWhen cross-compiling to 32-bit on Debian Buster I noticed this warning:
```
netmgr/http.c: In function 'https_readcb':
netmgr/http.c:707:14: warning: comparison of integer expressions of different signedness: 'ssize_t' {aka 'int'} and 'u...When cross-compiling to 32-bit on Debian Buster I noticed this warning:
```
netmgr/http.c: In function 'https_readcb':
netmgr/http.c:707:14: warning: comparison of integer expressions of different signedness: 'ssize_t' {aka 'int'} and 'unsigned int' [-Wsign-compare]
if (readlen < region->length) {
^
```
32-bit Debian sid had to be removed via 0aacabc6dc091ce3beb2d3a87d240ea7ddad8b8a.
/cc @artemMarch 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2480Feature request: signal to a secondary that received REFUSED on ixfr, to retr...2021-02-10T17:51:08ZCathy AlmondFeature request: signal to a secondary that received REFUSED on ixfr, to retry IXFR instead of AXFR on next attemptFrom [Support ticket #17554](https://support.isc.org/Ticket/Display.html?id=17554)
Use case as explained to Support:
> We have BIND transferring from a DNS device that occasionally, and temporarily, cannot provide an [AI]XFR.
> It sign...From [Support ticket #17554](https://support.isc.org/Ticket/Display.html?id=17554)
Use case as explained to Support:
> We have BIND transferring from a DNS device that occasionally, and temporarily, cannot provide an [AI]XFR.
> It signals this with a REFUSED rcode. Unfortunately when our BIND server receives this REFUSED response,
> the next XFR request is an AXFR. I understand that this is likely for compatibility reasons as some master
> may refuse an IXFR because it doesn't support it, but that is not the case here. Never mind the fact that
> one might hope to receive NOTIMP in such a case. I know that when IXFR is not available for journal reasons,
> the device is able to send AXFR as IXFR and BIND handles that perfectly fine, so I don't think its necessary
> to fail over to AXFR for the somewhat more common scenario where IXFR is not possible but AXFR is possible.
>
> Is there something that can be done on either end that would avoid this sub-optimal behaviour? Some ideas:
>
> a) Have BIND not fail over to AXFR after BIND receives a REFUSED rcode
> b) Have our device send some other rcode that BIND would not cause BIND to fail over to AXFR.
> In this case I would be looking for guidance on what RCODE we ask the device vendor to use instead.
I could envisage a configuration option for how many IXFR attempts there are on a hard fail (for some definition of 'hard fail' that includes REFUSED) before trying again with a request for an AXFR, default being 0 (which is what we do now).
I have no idea if there's a better way to handle b), although I suspect that simply just not responding would cause an IXFR retry wouldn't it?
====
This is a genuine operational problem, so suggestions for workarounds would also be much appreciated.https://gitlab.isc.org/isc-projects/bind9/-/issues/2481Forward only zones should forward queries regardless of RD flag.2022-01-19T18:47:57ZMaxim FortunForward only zones should forward queries regardless of RD flag.### Summary
When a query does not have an _RD_ flag set and a zone is configured as a _forward only_ the query does not get `recursed` and thus does not get an answer.
In my understanding _forward_ zones are not real zones, and forwardi...### Summary
When a query does not have an _RD_ flag set and a zone is configured as a _forward only_ the query does not get `recursed` and thus does not get an answer.
In my understanding _forward_ zones are not real zones, and forwarding is not really a recursion.
Not in a DNS sense anyway.
Forward zones function more in a way of a reverse proxy to an actual server and as such should always recurse
and let the downstream servers handle the query as is. That includes an _RD_ flag.
In addition, since a _forward_ zone is just a reverse proxy, it should return verbatim what it has received from the downstream. That includes authority section.
This is useful when there is a single public facing name server with subdomains controlled by different, not publically accessible, name servers throughout the intranet.
This can also be achieved by placing a public facing dns reverse proxy in front of intranet bind instances, but there is nothing quite like bind out there :)
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020
built by make with '--build=x86_64-alpine-linux-musl' '--host=x86_64-alpine-linux-musl' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dlopen=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-gssapi=/usr' '--with-libjson' '--with-libtool' '--with-libxml2' '--with-openssl=/usr' '--with-python=python3' '--enable-dnstap' '--enable-largefile' '--enable-linux-caps' '--enable-shared' '--enable-static' '--disable-isc-spnego' '--disable-backtrace' 'build_alias=x86_64-alpine-linux-musl' 'host_alias=x86_64-alpine-linux-musl' 'CC=gcc' 'CFLAGS=-Os -fomit-frame-pointer -D_GNU_SOURCE' 'LDFLAGS=-Wl,--as-needed' 'CPPFLAGS=-Os -fomit-frame-pointer'
compiled by GCC 10.2.1 20201203
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 libxml2 version: 2.9.10
linked to libxml2 version: 20910
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
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
```
### Steps to reproduce
Configure 2 instances of named.
Public named with a master zone and a forward zone
```
zone "example.com" {
type master;
file "example.com";
};
zone "sub.example.com" {
type forward;
forward only;
forwarders { ip_of_private_named port 2053; };
};
```
where zone file has
```
sub.example.com NS ip_of_private_named
```
Private named with a forwarded zone
```
zone "sub.example.com" {
type master;
file "sub.example.com";
};
```
Run a recursive query against a private named and get authoritative response:
```
$ nslookup -port=2053 sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#2053
Name: sub.example.com
Address: 127.0.0.1
```
Run a query against a public named and get non-authoritative response
```
$ nslookup -port=1053 sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#1053
Non-authoritative answer:
Name: sub.example.com
Address: 127.0.0.1
```
Run a non-recursive query against a private named and get back authoritative response
```
$ nslookup -port=2053 -norecurse sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#2053
Name: sub.example.com
Address: 127.0.0.1
```
Run a non-recursive query against a public named and get back no answer:
```
$ nslookup -port=1053 -norecurse sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#1053
Non-authoritative answer:
*** Can't find sub.example.com: No answer
```
### What is the current *bug* behavior?
Non-recursive query against a public named returns a `No answer`
Recursive query against a public named returns `non-authoritative` response
### What is the expected *correct* behavior?
Non-recursive query against a public named should forward to the specified server and behave as if it was a recursive query.
Any query against a public named should return whatever forwared named responded with AS IS, thus maintaining authority if it was returned.
### Relevant configuration files
Attaching a tar with configurations and a run.sh to spin up public and private instances.
Replace all occurences of 192.168.2.10 with the local ip of your docker host.
Run run.sh to spin up 2 containers: bind9-public and bind9-private.
Run nslookup queries from Steps to reproduce.
### Relevant logs and/or screenshots
In Steps to reproduce
### Possible fixes
I am proposing a fix that would handle the forwarding. I am not certain how to approach the authority response yet.
https://gitlab.isc.org/maxfortun/bind9/-/blob/fix-forward-zone-recursion/lib/ns/query.c
[bind-forward-test.tar.gz](/uploads/a80b7545c0fc9b8d77fa28bd65452f78/bind-forward-test.tar.gz)https://gitlab.isc.org/isc-projects/bind9/-/issues/2482compiling - bind-9.17.9/lib/isccfg - use of undeclared identifier 'DNS_R_NSEC...2021-02-07T17:27:56ZRyan Dudacompiling - bind-9.17.9/lib/isccfg - use of undeclared identifier 'DNS_R_NSEC3BADALG' - FreeBSD 12.2-RELEASE-p3[bind.txt](/uploads/b2d6f84b888da937163a027efcc21d46/bind.txt)[bind.txt](/uploads/b2d6f84b888da937163a027efcc21d46/bind.txt)https://gitlab.isc.org/isc-projects/bind9/-/issues/2483DoH could leak memory in connect2024-03-01T10:04:57ZOndřej SurýDoH could leak memory in connect```
Dump of all outstanding memory allocations:
ptr 0x8062dcad0 size 40 file ./../netmgr/http.c line 1019
ptr 0x8019fba00 size 8 file ./../netmgr/http.c line 1190
ptr 0x8019fe800 size 40 file ./../netmgr/http.c li...```
Dump of all outstanding memory allocations:
ptr 0x8062dcad0 size 40 file ./../netmgr/http.c line 1019
ptr 0x8019fba00 size 8 file ./../netmgr/http.c line 1190
ptr 0x8019fe800 size 40 file ./../netmgr/http.c line 1019
ptr 0x8051bb380 size 32 file ./../netmgr/http.c line 1193
ptr 0x8052dce10 size 40 file ./../netmgr/http.c line 1019
ptr 0x8019fe9e8 size 37 file ./../netmgr/http.c line 1021
ptr 0x808858d20 size 32 file ./../netmgr/http.c line 1193
ptr 0x8052dce78 size 37 file ./../netmgr/http.c line 1021
ptr 0x8060b60c0 size 32 file ./../netmgr/http.c line 1193
ptr 0x8019fb820 size 8 file ./../netmgr/http.c line 1190
ptr 0x8019fb5b0 size 8 file ./../netmgr/http.c line 1190
ptr 0x8062dcb38 size 37 file ./../netmgr/http.c line 1021
```
This happens mainly on FreeBSD 12.2, but generally speaking, it looks like those are all data passed to async functions and the data are freed in the callbacks. But this is not the case here, FreeBSD has a different scheduling, so it might have revealed something not present on Linux.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2484Add nghttp2 version to "named -V" output2021-02-16T22:45:54ZMichał KępieńAdd nghttp2 version to "named -V" outputSince BIND 9 is now requires nghttp2 for DNS-over-HTTPS (DoH) support,
`named -V` output should include:
- the nghttp2 version that `named` was built against,
- the nghttp2 version that `named` is linked to,
for consistency with th...Since BIND 9 is now requires nghttp2 for DNS-over-HTTPS (DoH) support,
`named -V` output should include:
- the nghttp2 version that `named` was built against,
- the nghttp2 version that `named` is linked to,
for consistency with the other libraries used.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2485DNS protocol cleanup: require correct AA bit2023-08-16T16:51:42ZPetr Špačekpspacek@isc.orgDNS protocol cleanup: require correct AA bit### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter va...### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter van Dijk is to be strict on AA bit and punish non-compliance. Main motivation seems to be code simplification when it comes various combinations of NXDOMAIN/NOERROR without SOA RR and/or "extra" NS records in authority which are sometimes added as "good measure" but do not actually mean a referral.
Anecdotes from the field:
a) Ralf Weber from Akamai has some reservations:
> Given that a lot of people use resolvers in front of their authoritative servers who don't send AA I fail to envision what resolvers should do. If we drop non AA answers I expect huge portion of the Internet to go dark, though I don't have hard numbers on that.
b) Recent versions of PowerDNS switched to stricter mode and insist on AA bit being correct. A person from Deutsche Telecom claims this:
> To give a sense of possible impact, we have tens of millions of subscribers and only 5-10 cases per year estimated. So I guess nothing would "go dark" :slightly_smiling_face:
### Links / references
Thread https://chat.dns-oarc.net/community/pl/57pcpenfkf86tr8onmhn1q5a4a
Personally I argue this is
a) not significant enough
b) not widespread enough
to warrant full fledged flag day, but we can start being stricter on AA bit if we decide to do so. PowerDNS already went in that direction so first-mover disadvantage is already paid :-)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2486dnssec-verify should be able to read journal files2022-02-25T14:21:36ZMark Andrewsdnssec-verify should be able to read journal filesWhen dnssec-verify is applied to zone files generated by `named` it may need to read the journal to get a complete picture of the zone's contents.When dnssec-verify is applied to zone files generated by `named` it may need to read the journal to get a complete picture of the zone's contents.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2487BIND 9.16.11 fails to return large response with libuv error2021-06-09T15:28:32ZAnand BuddhdevBIND 9.16.11 fails to return large response with libuv error### Summary
Queries that are supposed to elicit large responses, and cause a server to return a response with the TC bit set get no response at all.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux...### Summary
Queries that are supposed to elicit large responses, and cause a server to return a response with the TC bit set get no response at all.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019
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' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/named' '--disable-static' '--with-pic' '--without-python' '--with-libtool' '--without-lmdb' '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 ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
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.40.0
linked to libuv version: 1.40.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
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Configure a name in a zone with a very large TXT record of say 1500 bytes. Load this zone into BIND 9.16.11, and then query the server.
### What is the current *bug* behavior?
The server does not send a response to the query.
### What is the expected *correct* behavior?
The server should return a response with the TC bit set.
### Relevant configuration files
A TXT record in a zone like this can trigger this bug:
```
1500.4.dns.nl-ams-as3333-4.anchors.atlas.ripe.net. IN TXT "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
```
### Relevant logs and/or screenshots
When the server receives such a query, it logs this in the BIND log file:
```
10-Feb-2021 18:22:09.860 general: unable to convert libuv error code in udp_send_cb to isc_result: -90: message too long
```
### Possible fixes
Don't know.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2489Create test to ensure that TC responses are sent for answer sets that are too...2022-03-01T09:47:16ZBrian ConryCreate test to ensure that TC responses are sent for answer sets that are too largeAs described in #2487, this proper behavior doesn't seem to checked for in our current set of tests.As described in #2487, this proper behavior doesn't seem to checked for in our current set of tests.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2492CID 304936: Dereference before null check2021-03-02T14:31:14ZMark AndrewsCID 304936: Dereference before null checkcontrolconf.c
```
1191cleanup:
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null, but it has already been dereferenced on all paths leading t...controlconf.c
```
1191cleanup:
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1192 if (listener != NULL) {
1193 isc_refcount_decrement(&listener->refs);
1194 listener->exiting = true;
1195 free_listener(listener);
1196 }
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2493CID 281450: Dereference before null check (REVERSE_INULL)2021-09-02T11:46:51ZMark AndrewsCID 281450: Dereference before null check (REVERSE_INULL)test-async.c
```
162cleanup:
CID 281450 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking inst suggests that it may be null, but it has already been dereferenced on all paths leading to the c...test-async.c
```
162cleanup:
CID 281450 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking inst suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
163 if (result != ISC_R_SUCCESS && inst != NULL) {
164 plugin_destroy((void **)&inst);
165 }
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2494AddressSanitizer: stack-buffer-underflow in doh unit test2021-08-31T13:38:24ZMichal NowakAddressSanitizer: stack-buffer-underflow in doh unit testThe `doh` unit test failed GCC ASAN CI job on `main` (https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4680):
```
[==========] Running 8 test(s).
[ RUN ] mock_doh_uv_tcp_bind
[ OK ] mock_doh_uv_tcp_bind
[ RUN ]...The `doh` unit test failed GCC ASAN CI job on `main` (https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4680):
```
[==========] Running 8 test(s).
[ RUN ] mock_doh_uv_tcp_bind
[ OK ] mock_doh_uv_tcp_bind
[ RUN ] doh_parse_GET_query_string
[ OK ] doh_parse_GET_query_string
[ RUN ] doh_base64url_to_base64
[ OK ] doh_base64url_to_base64
[ RUN ] doh_base64_to_base64url
[ OK ] doh_base64_to_base64url
[ RUN ] doh_noop_POST
[ OK ] doh_noop_POST
[ RUN ] doh_noop_GET
[ OK ] doh_noop_GET
[ RUN ] doh_noresponse_POST
=================================================================
==3435==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f9fa3a733e0 at pc 0x7f9fab1a28ae bp 0x7f9fa3a730c0 sp 0x7f9fa3a72870
READ of size 152 at 0x7f9fa3a733e0 thread T7
#0 0x7f9fab1a28ad in __interceptor_memmove (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x378ad)
#1 0x7f9faac89948 in memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:40
#2 0x7f9faac89948 in isc___nmhandle_get netmgr/netmgr.c:1404
#3 0x556d0cb6cd3c in failed_httpstream_read_cb ../netmgr/http.c:2204
#4 0x556d0cb75262 in failed_read_cb ../netmgr/http.c:2237
#5 0x556d0cb76057 in https_readcb ../netmgr/http.c:696
#6 0x7f9faac979fb in isc__nm_async_readcb netmgr/netmgr.c:1978
#7 0x7f9faac99bfc in process_netievent netmgr/netmgr.c:742
#8 0x7f9faac9a985 in process_queue netmgr/netmgr.c:765
#9 0x7f9faac9a985 in process_normal_queue netmgr/netmgr.c:651
#10 0x7f9faac9b708 in process_queues netmgr/netmgr.c:659
#11 0x7f9faac9b708 in async_cb netmgr/netmgr.c:617
#12 0x7f9faa995667 (/usr/lib/x86_64-linux-gnu/libuv.so.1+0x10667)
#13 0x7f9faa9a44af in uv__io_poll (/usr/lib/x86_64-linux-gnu/libuv.so.1+0x1f4af)
#14 0x7f9faa995f84 in uv_run (/usr/lib/x86_64-linux-gnu/libuv.so.1+0x10f84)
#15 0x7f9faac9b4a4 in nm_thread netmgr/netmgr.c:557
#16 0x7f9faa961fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
#17 0x7f9fa99ab4ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
Address 0x7f9fa3a733e0 is located in stack of thread T7 at offset 0 in frame
#0 0x556d0cb7460e in failed_read_cb ../netmgr/http.c:2212
This frame has 1 object(s):
[32, 48) '<unknown>' <== Memory access at offset 0 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
Thread T7 created by T0 here:
#0 0x7f9fab1bbdb0 in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x50db0)
#1 0x7f9faae11e1e in isc_thread_create pthreads/thread.c:73
#2 0x7f9faac83b1b in isc_nm_start netmgr/netmgr.c:290
#3 0x556d0cb6fa57 in nm_setup /builds/isc-projects/bind9/lib/isc/tests/doh_test.c:242
#4 0x7f9fab1631e2 (/usr/lib/x86_64-linux-gnu/libcmocka.so.0+0x51e2)
SUMMARY: AddressSanitizer: stack-buffer-underflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x378ad) in __interceptor_memmove
Shadow bytes around the buggy address:
0x0ff474746620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff474746630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff474746640: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2
0x0ff474746650: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff474746660: 00 00 00 00 00 00 00 f2 f3 f3 f3 f3 00 00 00 00
=>0x0ff474746670: 00 00 00 00 00 00 00 00 00 00 00 00[f1]f1 f1 f1
0x0ff474746680: 00 00 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00
0x0ff474746690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
0x0ff4747466a0: f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f3 f3
0x0ff4747466b0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff4747466c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
==3435==ABORTING
Aborted (core dumped)
I:doh_test:Core dump found: ./core.3435
D:doh_test:backtrace from ./core.3435 start
[New LWP 4080]
[New LWP 3435]
[New LWP 4081]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/lib/isc/tests/.libs/doh_test'.
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 0x7f9fa3a78700 (LWP 4080))]
Thread 3 (Thread 0x7f9fa43bc700 (LWP 4081)):
#0 0x00007f9fa99ab62e in __GI_epoll_pwait (epfd=9, events=0x7f9fa43b7b70, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f9faa9a4399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f9faa995f85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f9faac9b4a5 in nm_thread (worker0=0x61a000003c80) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x61a000003c80
mgr = <optimized out>
#4 0x00007f9faa961fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140323631908608, 5557245483701016146, 140731872626558, 140731872626559, 140323631908608, 106858786326352, -5611479476276521390, -5611458202648013230}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#5 0x00007f9fa99ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 2 (Thread 0x7f9fa72ef980 (LWP 3435)):
#0 0x00007f9fa9978720 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffeb146d470, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
resultvar = 18446744073709551100
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f9fa99a3874 in usleep (useconds=useconds@entry=10000) at ../sysdeps/posix/usleep.c:32
ts = {tv_sec = 0, tv_nsec = 10000000}
#2 0x00007f9faac86514 in isc_nm_destroy (mgr0=0x60300004d740) at netmgr/netmgr.c:488
mgr = 0x612000243340
counter = 21
references = <optimized out>
#3 0x0000556d0cb6f175 in nm_teardown (state=<optimized out>) at doh_test.c:259
i = 0
nm = 0x60300004d740
#4 0x00007f9fab16321e in ?? () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#5 0x00007f9fab163b88 in _cmocka_run_group_tests () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#6 0x0000556d0cb9737e in main () at doh_test.c:1754
tests_short = <optimized out>
tests_long = <optimized out>
Thread 1 (Thread 0x7f9fa3a78700 (LWP 4080)):
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 3399988123389603631, 3399988123389603631, 140323569084922, 20, 140320876527616, 140323748018736, 140323622162800, 140320876527616}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007f9fa98d4535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 140323748030499, 140323622171616, 140323622171616, 152, 152, 0}}, sa_flags = -1549328384, sa_restorer = 0x7f9fabf306d8}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007f9fab271e6b in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
No symbol table info available.
#3 0x00007f9fab279ed8 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
No symbol table info available.
#4 0x00007f9fab25e97d in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
No symbol table info available.
#5 0x00007f9fab1a28d0 in memmove () from /usr/lib/x86_64-linux-gnu/libasan.so.5
No symbol table info available.
#6 0x00007f9faac89949 in memmove (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at netmgr/netmgr.c:1404
No locals.
#7 isc___nmhandle_get (sock=0x61c000010880, peer=<optimized out>, local=<optimized out>) at netmgr/netmgr.c:1404
handle = 0x61300002fec0
handlenum = <optimized out>
pos = <optimized out>
#8 0x0000556d0cb6cd3d in failed_httpstream_read_cb (sock=0x61c000010880, result=<optimized out>, session=0x6310000c8800) at ../netmgr/http.c:2204
handle = <optimized out>
addr = <optimized out>
#9 0x0000556d0cb75263 in failed_read_cb (result=<optimized out>, session=0x6310000c8800) at ../netmgr/http.c:2237
h2data = 0x61c000010958
#10 0x0000556d0cb76058 in https_readcb (handle=<optimized out>, result=20, region=0x7f9fa3a73550, data=0x6310000c8800) at ../netmgr/http.c:696
session = 0x6310000c8800
readlen = <optimized out>
#11 0x00007f9faac979fc in isc__nm_async_readcb (worker=worker@entry=0x61a000003680, ev0=ev0@entry=0x61300001c900) at netmgr/netmgr.c:1978
ievent = 0x61300001c900
sock = 0x61c000010080
uvreq = <optimized out>
eresult = 20
region = <optimized out>
#12 0x00007f9faac99bfd in process_netievent (worker=worker@entry=0x61a000003680, ievent=0x61300001c900) at netmgr/netmgr.c:742
No locals.
#13 0x00007f9faac9a986 in process_queue (queue=0x614000004280, worker=0x61a000003680) at netmgr/netmgr.c:765
ievent = <optimized out>
ievent = <optimized out>
#14 process_normal_queue (worker=worker@entry=0x61a000003680) at netmgr/netmgr.c:651
No locals.
#15 0x00007f9faac9b709 in process_queues (worker=0x61a000003680) at netmgr/netmgr.c:659
No locals.
#16 async_cb (handle=<optimized out>) at netmgr/netmgr.c:617
worker = 0x61a000003680
#17 0x00007f9faa995668 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#18 0x00007f9faa9a44b0 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#19 0x00007f9faa995f85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#20 0x00007f9faac9b4a5 in nm_thread (worker0=0x61a000003680) at netmgr/netmgr.c:557
r = <optimized out>
worker = 0x61a000003680
mgr = <optimized out>
#21 0x00007f9faa961fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140323622192896, 5557245483701016146, 140731872626558, 140731872626559, 140323622192896, 106858786326800, -5611474019520571822, -5611458202648013230}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#22 0x00007f9fa99ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
D:doh_test:backtrace from ./core.3435 end
FAIL doh_test (exit status: 134)
```
[core.3435.gz](/uploads/6a65d4cb9df646b260aa678fff32a276/core.3435.gz)April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2495Mitigation for cache bloat due to negative RRsets (NXDOMAIN and NXRRSET) when...2024-03-01T10:04:57ZCathy AlmondMitigation for cache bloat due to negative RRsets (NXDOMAIN and NXRRSET) when preserving expired RRsets using max-stale-ttlI'm tagging this as 'Customer' because it is affecting/has affected several customer caches (unanticipated cache bloat) with 'stale-cache-enable yes;'
----
By design, negative cache content is not used in the same way as positive cache...I'm tagging this as 'Customer' because it is affecting/has affected several customer caches (unanticipated cache bloat) with 'stale-cache-enable yes;'
----
By design, negative cache content is not used in the same way as positive cache content. 'stale-answer-client-timeout' does not apply to negative content, thus the clients will timeout and likely retry the same query several times before giving up, long before the resolver-query-timeout. Only when named has failed to get a response from the authoritative server(s) does the 'stale-refresh-time' window commence.
There is a good reason for this - when querying the authoritative servers for a name that is already NXDOMAIN or NXRRSET in cache, we don't know if this is going to be replaced with positive content or not. Therefore, to ensure that positive content is preferred, we have to wait to be sure that it's sensible to serve the stale negative content as a last resort.
UNFORTUNATELY:
1. Most negative content is single-use - so adding max-stale-ttl to its retention period can significantly increase cache bloat - for no useful reason whatsoever.
2. Most negative content has (also by design of sane zone administrators, or overridden by max-ncache-ttl) a much shorter TTL in cache than positive content.
So when we're not preserving stale content, the negative content is fairly quickly removed from cache, in comparison with the positive RRsets. But adding max-stale-ttl to the retention period can quite significantly tilt the balance in favour of all of this one-use-only cached negative content.
We don't have any statistics that measure cache hits for different RTYPEs, so we don't know for sure, what percentage of negative content is used again (cache hits) versus just sitting there for no good reason (cache misses) - perhaps we should? (Perhaps we should also have stats on stale hits and misses by RTYPE?)
But in any case, having seen too many caches overloaded with stale negative content, I should like to propose an option that can be used either to shorten the max-stale-ttl for negative content, but that also takes a value of zero, to disable its retention entirely.https://gitlab.isc.org/isc-projects/bind9/-/issues/2496Crash in isc_mem_checkdestroyed() with PKCS#112022-03-01T09:41:38ZMichal NowakCrash in isc_mem_checkdestroyed() with PKCS#11PKCS#11 job with SoftHSM 2.6 on Fedora 33 [asserted failure](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1498009) on `main` with the following output:
```
I:pkcs11:exit status: 0
I:pkcs11:stopping servers
I:pkcs11:Core dump(s) found...PKCS#11 job with SoftHSM 2.6 on Fedora 33 [asserted failure](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1498009) on `main` with the following output:
```
I:pkcs11:exit status: 0
I:pkcs11:stopping servers
I:pkcs11:Core dump(s) found: pkcs11/ns1/core.22627
D:pkcs11:backtrace from pkcs11/ns1/core.22627:
D:pkcs11:--------------------------------------------------------------------------------
D:pkcs11:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D pkcs11-ns1 -X named.lock'.
D:pkcs11:Program terminated with signal SIGABRT, Aborted.
D:pkcs11:#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
D:pkcs11:#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
D:pkcs11:#1 0x00007f70b07608a4 in abort () from /lib64/libc.so.6
D:pkcs11:#2 0x000000000041d679 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=0x7f70b12310f2 "0") at main.c:259
D:pkcs11:#3 0x00007f70b11fc40e in isc_assertion_failed (file=file@entry=0x7f70b122eef1 "mem.c", line=line@entry=2092, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f70b12310f2 "0") at assertions.c:46
D:pkcs11:#4 0x00007f70b120d89e in isc_mem_checkdestroyed (file=0x7f70b08ff440 <_IO_2_1_stderr_>) at mem.c:2092
D:pkcs11:#5 0x000000000041f736 in main (argc=16, argv=0x7fff9f83ca58) at main.c:1626
D:pkcs11:--------------------------------------------------------------------------------
D:pkcs11:full backtrace from pkcs11/ns1/core.22627 saved in pkcs11/ns1/core.22627-backtrace.txt
D:pkcs11:core dump pkcs11/ns1/core.22627 archived as pkcs11/ns1/core.22627.gz
R:pkcs11:FAIL
```
`named.run`:
```
17-Feb-2021 08:40:25.955 exiting
context: 0x179a180 (zonemgr-pool): 2 references
Dump of all outstanding memory allocations:
ptr 0x7f709c4b3020 size 214 file diff.c line 67
ptr 0x7f709c497f48 size 214 file diff.c line 67
mem.c:2092: INSIST(0) failed
```
Full backtrace:
```
[New LWP 22627]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D pkcs11-ns1 -X named.lock'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
Thread 1 (Thread 0x7f70b0382d80 (LWP 22627)):
#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f70b07608a4 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x000000000041d679 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=0x7f70b12310f2 "0") at main.c:259
tracebuf = {0x11, 0x7f70b1258f17 <_dl_fixup+215>, 0x5, 0x0, 0x7fff9f83c960, 0x7f70b11b94b0, 0x7fff9f83c8b0, 0x7f70b126056e <_dl_runtime_resolve_xsavec+126>, 0x0, 0x7f70b12310f2, 0x2, 0x82c, 0x7f70b122eef1, 0x0, 0x7fff9f83a5f6, 0x7f70b126056e <_dl_runtime_resolve_xsavec+126>, 0x0, 0x114a010, 0x1, 0xffff00001f80, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7f709c1ba000, 0x7fff9f83c700, 0x7f70b07afd26 <fflush+134>, 0x7f70b03420e0, 0x1, 0x7fff9f83c800, 0xffff00001f80, 0x481a10 <dns_modules+400>, 0x1158a38, 0x1158968, 0x0, 0x0, 0x45dc61, 0x7f70b0341020, 0x7fff9f83c790, 0x2525252525252525, 0x2525252525252525, 0xffffffffffffff00, 0x0, 0xffffffffffffff00, 0x0, 0x475f4300, 0x0, 0x43006f666e497465, 0x746f6c537465475f, 0x5a5a5a5a5a5a5a5a, 0x5a5a5a5a5a5a5a5a, 0x2020202020202020, 0x2020202020202020, 0x0, 0x0, 0xa, 0x6165726874702828, 0x0, 0x0, 0x20202020, 0x2000202020202020, 0x0 <repeats 18 times>, 0x3535392e35323a, 0x0, 0x0, 0x0, 0x2, 0x800000000000000e, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x800000000000000e, 0x0, 0xbe57a377d9ca5100, 0x0, 0xbe57a377d9ca5100, 0x7f704800a030, 0x7fff9f83c8c0, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7f70b122e220, 0xab0, 0x7f70b08498e3 <__fprintf_chk+163>, 0x3000000030, 0x7fff9f83c888, 0x7fff9f83c7c0, 0xbe57a377d9ca5100, 0xd68, 0x7f70b07baf86 <new_do_write+102>, 0x179a180, 0x7f709c497f48, 0xd6, 0x7f70b114f01a, 0x7f70b0900320 <__GI__IO_file_jumps>, 0x2c, 0x2c, 0x7f70b07bc36e <__GI__IO_file_xsputn+366>, 0x173c990, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x2c, 0x2c, 0x1, 0x7f70b122e1f0, 0x7f70b0900320 <__GI__IO_file_jumps>, 0x7f70b07b0c11 <fwrite+193>, 0x0, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7fff9f83c8c0, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7f70b122f19c, 0x7f70b120a656 <print_active+137>}
nframes = 32624
result = <optimized out>
logsuffix = <optimized out>
#3 0x00007f70b11fc40e in isc_assertion_failed (file=file@entry=0x7f70b122eef1 "mem.c", line=line@entry=2092, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f70b12310f2 "0") at assertions.c:46
No locals.
#4 0x00007f70b120d89e in isc_mem_checkdestroyed (file=0x7f70b08ff440 <_IO_2_1_stderr_>) at mem.c:2092
No locals.
#5 0x000000000041f736 in main (argc=16, argv=0x7fff9f83ca58) at main.c:1626
result = <optimized out>
```
Core file: [core.22627.gz](/uploads/854788c1a5b6f20c3cf5351c1ef90378/core.22627.gz)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2497Add counters for DoH queries2023-12-12T11:00:33ZVicky Riskvicky@isc.orgAdd counters for DoH queriesSince you can support DoH in addition to Do53 on the same BIND instance, it would be really nice to have some way to tell how much DoH traffic you are getting.
- [ ] Add some metric that enables the operator to tell specifically how mu...Since you can support DoH in addition to Do53 on the same BIND instance, it would be really nice to have some way to tell how much DoH traffic you are getting.
- [ ] Add some metric that enables the operator to tell specifically how much DoH traffic they are receiving.
- [ ] Please be sure to document this metric in the ARM and explain what it is measuring as specifically as possible (because we have a problem in general with not having good enough documentation of our metrics).
- [ ] Also, check to ensure that we are updating the existing counters for TCP v4 and TCP v6 queries with the DoH queries (I am told we are not entirely confident that these are always updated for DoH queries in 9.17.10)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2499A LOC record with a invalid direction field triggers an INSIST2021-03-08T12:07:03ZMark AndrewsA LOC record with a invalid direction field triggers an INSISTMarch 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2500dnssec-policy checkds does not seem to work2021-02-22T10:52:35ZMarc Dequènes (Duck)dnssec-policy checkds does not seem to workThis is a follow-up on #2488 but for a different problem.
Key 5022 is now published:
```
# rndc dnssec -status _kage.hq.duckcorp.org
dnssec-policy: generated
current time: Thu Feb 18 18:24:02 2021
key: 43281 (RSASHA512), KSK
publish...This is a follow-up on #2488 but for a different problem.
Key 5022 is now published:
```
# rndc dnssec -status _kage.hq.duckcorp.org
dnssec-policy: generated
current time: Thu Feb 18 18:24:02 2021
key: 43281 (RSASHA512), KSK
published: yes - since Fri Aug 28 00:31:44 2020
key signing: yes - since Fri Aug 28 00:31:44 2020
Rollover is due since Fri Feb 12 00:26:50 2021
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- key rrsig: omnipresent
key: 20426 (RSASHA512), ZSK
published: yes - since Sat Nov 21 00:31:44 2020
zone signing: yes - since Mon Dec 21 00:31:44 2020
Next rollover scheduled on Sat Mar 20 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
key: 5022 (RSASHA512), KSK
published: yes - since Tue Feb 16 01:47:35 2021
key signing: yes - since Tue Feb 16 01:47:35 2021
Next rollover scheduled on Wed Feb 16 01:47:35 2022
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- key rrsig: omnipresent
```
I used `rndc dnssec -checkds -key 5022 published _kage.hq.duckcorp.org` yesterday right after replying to #2488 but his did not produce anything in the logs and the status is the same. The output (forgot to keep it so doing it again): `KSK 5022: Marked DS as published since 18-Feb-2021 19:48:06.000`. And I can confirm the is nothing in the logs except `received control channel command`.
I just used `rndc loadkeys _kage.hq.duckcorp.org` as suggested in #2488, so let's see if that's a similar problem.
\\_o<https://gitlab.isc.org/isc-projects/bind9/-/issues/2501TSAN error in mdig2021-03-04T14:06:23ZMark AndrewsTSAN error in mdigJob [#1507619](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507619) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 free <null...Job [#1507619](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507619) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 free <null>
#1 default_memfree lib/isc/mem.c:440
#2 mem_put lib/isc/mem.c:363
#3 isc__mem_free lib/isc/mem.c:1012
#4 main bin/tools/mdig.c:2231
Previous read of size 1 at 0x000000000005 by thread T1:
#0 dns_name_fromtext lib/dns/name.c:1121
#1 sendquery bin/tools/mdig.c:596
#2 sendqueries bin/tools/mdig.c:779
#3 dispatch lib/isc/task.c:1152
#4 run lib/isc/task.c:1344
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 main bin/tools/mdig.c:2148
SUMMARY: ThreadSanitizer: data race in __interceptor_free
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2502Several TSAN issues.2021-04-09T09:37:34ZMark AndrewsSeveral TSAN issues.Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
See tsan directory for details.Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
See tsan directory for details.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2503New stale-answer-client-timeout crashes BIND 9.16 and 9.172021-03-03T09:10:55ZOndřej SurýNew stale-answer-client-timeout crashes BIND 9.16 and 9.17From [Support ticket #17781](https://support.isc.org/Ticket/Display.html?id=17781)
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f3c7bda4859 in __GI_abort () at abort.c:79
#2 0x000055cc6a31dd0...From [Support ticket #17781](https://support.isc.org/Ticket/Display.html?id=17781)
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f3c7bda4859 in __GI_abort () at abort.c:79
#2 0x000055cc6a31dd0a in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:261
#3 0x000055cc6a52ed20 in isc_assertion_failed (file=file@entry=0x55cc6a5a3863 "query.c", line=line@entry=6282, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x55cc6a5a42c0 "client->query.fetch == ((void *)0)") at assertions.c:46
#4 0x000055cc6a37ba6a in ns_query_recurse (client=0x7f3c540104c8, qtype=<optimized out>, qname=qname@entry=0x7f3c45331380, qdomain=0x7f3c453312e0, nameservers=0x7f3c45335bc8,
resuming=<optimized out>) at query.c:6258
#5 0x000055cc6a385e71 in query_delegation_recurse (qctx=0x7f3c721fa920) at query.c:8513
#6 query_delegation (qctx=qctx@entry=0x7f3c721fa920) at query.c:8459
#7 0x000055cc6a381f0e in query_gotanswer (qctx=qctx@entry=0x7f3c721fa920, res=res@entry=65565) at query.c:7220
#8 0x000055cc6a383e14 in query_lookup (qctx=qctx@entry=0x7f3c721fa920) at query.c:5925
#9 0x000055cc6a387e90 in query_lookup_staleonly (client=0x7f3c540104c8) at query.c:5956
#10 fetch_callback (task=<optimized out>, event=<optimized out>) at query.c:5995
#11 0x000055cc6a564131 in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1152
#12 run (queuep=<optimized out>) at task.c:1344
#13 0x00007f3c7bf8b609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#14 0x00007f3c7bea1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
The problem case here is that when we are handling a client request, and `stale-answer-client-timeout` is triggered, a separate stale only request is made, while the already started resolver fetch continues to wait for a response.
This is fine if there is a stale answer in cache, but if nothing is found, the stale only query will also start recursion.
Now we hit the `client->query.fetch == ((void *)0)` assertion.
Fix by disabling recursion on staleonly lookups.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2504System-wide libtool is required even when building from a tarball produced by...2022-01-26T11:33:40ZMichał KępieńSystem-wide libtool is required even when building from a tarball produced by "make dist"Reported by a customer: https://support.isc.org/Ticket/Display.html?id=17785
The problem is caused by a mistake in `configure.ac` which was
inadvertently introduced by !3742. We did not catch this in our own
testing because all OS imag...Reported by a customer: https://support.isc.org/Ticket/Display.html?id=17785
The problem is caused by a mistake in `configure.ac` which was
inadvertently introduced by !3742. We did not catch this in our own
testing because all OS images we use have the libtool package installed.
Only the development branch (9.17.3+) is affected.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/25059.16.11 -> 9.16.12 breaks AXFR (for me)2021-03-16T23:10:09ZErich Eckner9.16.11 -> 9.16.12 breaks AXFR (for me)### Summary
I updated from bind 9.16.11 to 9.16.12 on arch linux, restarted `named` and AXFR queries are now being rejected by my server.
### BIND version used
```
BIND 9.16.12 (Stable Release) <id:aeb943d>
running on Linux x86_64 5.1...### Summary
I updated from bind 9.16.11 to 9.16.12 on arch linux, restarted `named` and AXFR queries are now being rejected by my server.
### BIND version used
```
BIND 9.16.12 (Stable Release) <id:aeb943d>
running on Linux x86_64 5.10.16-arch1-1 #1 SMP PREEMPT Sat, 13 Feb 2021 20:50:18 +0000
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--enable-dnsrps' '--with-python=/usr/bin/python' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.0
compiled with OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.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
It's an up-to-date arch linux installation with named started via systemd. Only addition to the service file is:
```
Restart=always
RestartSec=5
ExecStartPost=/usr/bin/bash -c 'i=10; while [ $i -gt 0 ] && ! chmod g+r /var/run/named/session.key; do i=$((i-1)); sleep 1; done; [ $i -gt 0 ]'
```
One pecularity is, that bind is only listening on `127.0.0.1`, because for public access, there is dnsdist "in front".
The failure happens, when I try to get a zone from my server with `dig @127.0.0.1 ddns.eckner.net. AXFR`.
### What is the current *bug* behavior?
`dig @127.0.0.1 ddns.eckner.net. AXFR` fails with:
```
; <<>> DiG 9.16.12 <<>> @127.0.0.1 ddns.eckner.net AXFR
; (1 server found)
;; global options: +cmd
; Transfer failed.
```
### What is the expected *correct* behavior?
When running bind version 9.16.11, I properly get the zone with the above command:
```
; <<>> DiG 9.16.11 <<>> @127.0.0.1 ddns.eckner.net AXFR
; (1 server found)
;; global options: +cmd
ddns.eckner.net. 86400 IN SOA eckner.net. ddns.eckner.net. 2023118656 28800 14400 2419200 86400
ddns.eckner.net. 86400 IN NS ns2.eckner.net.
ddns.eckner.net. 86400 IN NS ns3.eckner.net.
ddns.eckner.net. 86400 IN NS uz5x36jqv06q5yulzwcblfzcrk1b479xdttdm1nrgfglzs57bmctl8.free.ns.buddyns.com.
ddns.eckner.net. 86400 IN NS uz56xw8h7fw656bpfv84pctjbl9rbzbqrw4rpzdhtvzyltpjdmx0zq.free.ns.buddyns.com.
ddns.eckner.net. 86400 IN NS uz5x6wcwzfbjs8fkmkuchydn9339lf7xbxdmnp038cmyjlgg9sprr2.free.ns.buddyns.com.
ddns.eckner.net. 86400 IN NS uz588h0rhwuu3cc03gm9uckw0w42cqr459wn1nxrbzhym2wd81zydb.free.ns.buddyns.com.
ddns.eckner.net. 86400 IN NS uz5qfm8n244kn4qz8mh437w9kzvpudduwyldp5361v9n0vh8sx5ucu.free.ns.buddyns.com.
ddns.eckner.net. 86400 IN NS uz5w6sb91zt99b73bznfkvtd0j1snxby06gg4hr0p8uum27n0hf6cd.free.ns.buddyns.com.
ddns.eckner.net. 86400 IN NS uz52u1wtmumlrx5fwu6nmv22ntcddxcjjw41z8sfd6ur9n7797lrv9.free.ns.buddyns.com.
... zone data ...
ddns.eckner.net. 86400 IN SOA eckner.net. ddns.eckner.net. 2023118656 28800 14400 2419200 86400
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Feb 19 16:16:39 CET 2021
;; XFR size: 763 records (messages 2, bytes 19821)
```
### Relevant configuration files
The interesting parts are probably only the `options` and `zone "ddns.eckner.net" IN` section, but I'm not sure, so I'll post all:
```
controls {
inet 127.0.0.1 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
};
options {
directory "/var/named";
hostname none;
listen-on {
127.0.0.1/32;
};
listen-on-v6 {
::1/128;
};
pid-file "/run/named/named.pid";
server-id none;
version none;
allow-recursion {
"any";
};
recursion yes;
response-policy {
zone "rpz";
};
allow-transfer {
"none";
};
notify-source-v6 ::1;
};
key "rndc-key" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
zone "bbs" in {
type slave;
file "/etc/opennic/slave/bbs.zone";
masters {
207.192.71.13;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "chan" in {
type slave;
file "/etc/opennic/slave/chan.zone";
masters {
94.103.153.176;
2a02:990:219:1:ba:1337:cafe:3;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "cyb" in {
type slave;
file "/etc/opennic/slave/cyb.zone";
masters {
79.124.7.81;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "dns.opennic.glue" in {
type slave;
file "/etc/opennic/slave/dns.opennic.glue.zone";
masters {
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "dyn" in {
type slave;
file "/etc/opennic/slave/dyn.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "epic" in {
type slave;
file "/etc/opennic/slave/epic.zone";
masters {
144.76.103.143;
2a01:4f8:192:43a5::2;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "geek" in {
type slave;
file "/etc/opennic/slave/geek.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "gopher" in {
type slave;
file "/etc/opennic/slave/gopher.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "indy" in {
type slave;
file "/etc/opennic/slave/indy.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "libre" in {
type slave;
file "/etc/opennic/slave/libre.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "neo" in {
type slave;
file "/etc/opennic/slave/neo.zone";
masters {
104.168.144.17;
2001:470:8269::53;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "null" in {
type slave;
file "/etc/opennic/slave/null.zone";
masters {
188.226.146.136;
2001:470:1f04:ebf::2;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "o" in {
type slave;
file "/etc/opennic/slave/o.zone";
masters {
51.75.173.177;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "opennic.glue" in {
type slave;
file "/etc/opennic/slave/opennic.glue.zone";
masters {
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "oss" in {
type slave;
file "/etc/opennic/slave/oss.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "oz" in {
type slave;
file "/etc/opennic/slave/oz.zone";
masters {
188.226.146.136;
2001:470:1f04:ebf::2;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "parody" in {
type slave;
file "/etc/opennic/slave/parody.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "pirate" in {
type slave;
file "/etc/opennic/slave/pirate.zone";
masters {
161.97.219.84;
2001:470:4212:10:0:100:53:10;
168.119.153.26;
195.201.99.61;
2a01:4f8:c17:fa94::;
2a01:4f8:c2c:e789::;
};
notify no;
};
zone "rpz" {
type master;
file "rpz.zone";
};
zone "localhost" IN {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "localhost.ip6.zone";
};
zone "e.c.6.f.0.d.0.0.1.0.a.2.ip6.arpa" IN {
type master;
file "/var/named/e.c.6.f.0.d.0.0.1.0.a.2.ip6.arpa.zone";
update-policy local;
allow-transfer {
127.0.0.1/32;
10.0.1.1/32;
};
also-notify {
10.0.1.1;
};
};
zone "1.0.10.in-addr.arpa" IN {
type master;
file "/var/named/1.0.10.in-addr.arpa.zone";
allow-transfer {
127.0.0.1/32;
10.0.1.1/32;
};
also-notify {
10.0.1.1;
};
};
zone "2.0.10.in-addr.arpa" IN {
type master;
file "/var/named/2.0.10.in-addr.arpa.zone";
update-policy local;
allow-transfer {
127.0.0.1/32;
10.0.1.1/32;
};
also-notify {
10.0.1.1;
};
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "/var/named/0.168.192.in-addr.arpa.zone";
update-policy local;
allow-transfer {
127.0.0.1/32;
10.0.1.1/32;
};
also-notify {
10.0.1.1;
};
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "/var/named/1.168.192.in-addr.arpa.zone";
update-policy local;
allow-transfer {
127.0.0.1/32;
10.0.1.1/32;
};
also-notify {
10.0.1.1;
};
};
zone "ddns.eckner.net" IN {
type master;
file "/var/named/ddns.eckner.net.zone";
update-policy local;
allow-transfer {
69.65.50.192/32;
127.0.0.1/32;
10.0.1.1/32;
};
also-notify {
10.0.1.1;
};
};
zone "home.eckner.net" IN {
type slave;
file "/var/named/home.eckner.net.zone";
masters {
10.0.1.1;
};
notify no;
};
```
### Relevant logs and/or screenshots
for the failed transfer attempt, `named.run` shows:
```
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 (no-peer): allocate new client
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: TCP request
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: using view '_default'
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: request is not signed
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: recursion available
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139 (ddns.eckner.net): AXFR request
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139 (ddns.eckner.net): zone transfer setup failed
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139 (ddns.eckner.net): reset client
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: freeing client
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2506Catalog zones ignores already loaded non primary zones on secondary2022-06-14T19:46:59ZChuck StearnsCatalog zones ignores already loaded non primary zones on secondarySequence of events:
1. A forward zone foo.com not loaded in named as part of named.conf on Primary;
2. A forward zone foo.com already loaded in named as part of named.conf on Secondary only.
3. A Primary zone foo.com is added to Catal...Sequence of events:
1. A forward zone foo.com not loaded in named as part of named.conf on Primary;
2. A forward zone foo.com already loaded in named as part of named.conf on Secondary only.
3. A Primary zone foo.com is added to Catalog Zones as primary zone on Primary server -- Success
4. Catalog zone transfer took place
5. Secondary servers added zone foo.com as Primary zone though Forward zone foo.com is already loaded.
According to the draft RFC for DNS Catalog Zones https://tools.ietf.org/html/draft-ietf-dnsop-dns-catalog-zones-01:
" If there is a clash between an existing member zone's name and an
incoming member zone's name (via transfer or update), the new
instance of the zone MUST be ignored and an error SHOULD be logged." (6.1)
It appears that the catalog zone code is probably checking the zone table for an existing zone called foo.com, but it's not checking the forwarder table.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2507CID 320483: API usage errors (LOCK)2021-03-02T14:42:03ZMark AndrewsCID 320483: API usage errors (LOCK)```
** CID 320483: API usage errors (LOCK)
/bin/dig/dighost.c: 2133 in _new_query()
________________________________________________________________________________________________________
*** CID 320483: API usage errors (LOCK)
/b...```
** CID 320483: API usage errors (LOCK)
/bin/dig/dighost.c: 2133 in _new_query()
________________________________________________________________________________________________________
*** CID 320483: API usage errors (LOCK)
/bin/dig/dighost.c: 2133 in _new_query()
2127 _new_query(dig_lookup_t *lookup, char *servname, char *userarg,
2128 const char *file, unsigned int line) {
2129 dig_query_t *query = NULL;
2130
2131 query = isc_mem_allocate(mctx, sizeof(dig_query_t));
2132 debug("create query %p linked to lookup %p", query, lookup);
CID 320483: API usage errors (LOCK)
"isc__mempool_get" unlocks "commctx->lock" while it is unlocked.
2133 *query = (dig_query_t){ .sendbuf = lookup->renderbuf,
2134 .servname = servname,
2135 .userarg = userarg,
2136 .first_pass = true,
2137 .warn_id = true,
2138 .recvspace = isc_mempool_get(commctx),
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2508CID 320481: Null pointer dereferences (REVERSE_INULL)2021-03-02T14:38:32ZMark AndrewsCID 320481: Null pointer dereferences (REVERSE_INULL)```
** CID 320481: Null pointer dereferences (REVERSE_INULL)
/bin/tests/wire_test.c: 261 in main()
________________________________________________________________________________________________________
*** CID 320481: Null pointer...```
** CID 320481: Null pointer dereferences (REVERSE_INULL)
/bin/tests/wire_test.c: 261 in main()
________________________________________________________________________________________________________
*** CID 320481: Null pointer dereferences (REVERSE_INULL)
/bin/tests/wire_test.c: 261 in main()
255 process_message(input);
256 }
257 } else {
258 process_message(input);
259 }
260
CID 320481: Null pointer dereferences (REVERSE_INULL)
Null-checking "input" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
261 if (input != NULL) {
262 isc_buffer_free(&input);
263 }
264
265 if (printmemstats) {
266 isc_mem_stats(mctx, stdout);
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2509CID 281489: Resource leaks (RESOURCE_LEAK)2021-03-02T14:29:42ZMark AndrewsCID 281489: Resource leaks (RESOURCE_LEAK)```
** CID 281489: Resource leaks (RESOURCE_LEAK)
/lib/dns/dnstap.c: 983 in dns_dt_open()
________________________________________________________________________________________________________
*** CID 281489: Resource leaks (RESO...```
** CID 281489: Resource leaks (RESOURCE_LEAK)
/lib/dns/dnstap.c: 983 in dns_dt_open()
________________________________________________________________________________________________________
*** CID 281489: Resource leaks (RESOURCE_LEAK)
/lib/dns/dnstap.c: 983 in dns_dt_open()
977
978 if (!dnstap_file(handle->reader)) {
979 CHECK(DNS_R_BADDNSTAP);
980 }
981 break;
982 case dns_dtmode_unix:
CID 281489: Resource leaks (RESOURCE_LEAK)
Variable "handle" going out of scope leaks the storage it points to.
983 return (ISC_R_NOTIMPLEMENTED);
984 default:
985 INSIST(0);
986 ISC_UNREACHABLE();
987 }
988
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2510CID 320479: Resource leaks (RESOURCE_LEAK)2021-09-02T09:05:38ZMark AndrewsCID 320479: Resource leaks (RESOURCE_LEAK)Investigate
```
* CID 320479: Resource leaks (RESOURCE_LEAK)
/lib/isc/netmgr/tlsdns.c: 1383 in tls_cycle_output()
________________________________________________________________________________________________________
*** CID 3204...Investigate
```
* CID 320479: Resource leaks (RESOURCE_LEAK)
/lib/isc/netmgr/tlsdns.c: 1383 in tls_cycle_output()
________________________________________________________________________________________________________
*** CID 320479: Resource leaks (RESOURCE_LEAK)
/lib/isc/netmgr/tlsdns.c: 1383 in tls_cycle_output()
1377
1378 err = uv_write(&req->uv_req.write, &sock->uv_handle.stream,
1379 &sock->tls.senddata, 1, tls_write_cb);
1380
1381 INSIST(err == 0);
1382
CID 320479: Resource leaks (RESOURCE_LEAK)
Variable "req" going out of scope leaks the storage it points to.
1383 break;
1384 }
1385
1386 return (result);
1387 }
1388
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2511(CSK) is now inactive2022-09-26T13:20:26ZJim Popovitch(CSK) is now inactiveI'm seeing this over and over in the log on the primary (v9.16.11-2~bpo10+1)
```
Feb 21 07:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 08:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDS...I'm seeing this over and over in the log on the primary (v9.16.11-2~bpo10+1)
```
Feb 21 07:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 08:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 09:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 10:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 11:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 12:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 13:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 14:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 15:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 16:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 17:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 18:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 19:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 20:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 21:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 22:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
Feb 21 23:06:33 ns1 named[7955]: DNSKEY domainmail.ch/ECDSAP256SHA256/4319 (CSK) is now inactive
```
```
/etc/bind/keys/Kdomainmail.ch.+013+22048.key
; This is a key-signing key, keyid 22048, for domainmail.ch.
; Created: 20210208192710 (Mon Feb 8 19:27:10 2021)
; Publish: 20210208192710 (Mon Feb 8 19:27:10 2021)
; Activate: 20210208222710 (Mon Feb 8 22:27:10 2021)
; Inactive: 20210310222710 (Wed Mar 10 22:27:10 2021)
; Delete: 20210320233210 (Sat Mar 20 23:32:10 2021)
; SyncPublish: 20210208222710 (Mon Feb 8 22:27:10 2021)
/etc/bind/keys/Kdomainmail.ch.+013+04319.key
; This is a key-signing key, keyid 4319, for domainmail.ch.
; Created: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Publish: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Activate: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Inactive: 20210221040633 (Sun Feb 21 04:06:33 2021)
; Delete: 20210303051133 (Wed Mar 3 05:11:33 2021)
; SyncPublish: 20210221023255 (Sun Feb 21 02:32:55 2021)
```
```
dnssec-policy "test" {
keys { csk lifetime P30D algorithm ECDSAP256SHA256; };
};
zone "domainmail.ch" {
type master;
file "/etc/bind/zone/domainmail.ch";
dnssec-policy "test";
};
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2512Serve-stale system tests fails often on check no. 1702023-06-01T11:58:40ZMatthijs Mekkingmatthijs@isc.orgServe-stale system tests fails often on check no. 170Job [#1512811](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1512811) failed for bb124d6056e5e8bc2a960ea9de914744803378bc.
Job [#1512944](https://gitlab.isc.org/isc-private/bind9/-/jobs/1512944) failed for a8c92e448a7e9e0cc0eee0426b1...Job [#1512811](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1512811) failed for bb124d6056e5e8bc2a960ea9de914744803378bc.
Job [#1512944](https://gitlab.isc.org/isc-private/bind9/-/jobs/1512944) failed for a8c92e448a7e9e0cc0eee0426b140c8fc0054780.
Job [#1517715](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1517715) failed for 772cad50a1d23c6686404a611bd21697c8467c3f.
Job [#1517807](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1517807) failed for d4cb312555b69c9e513e9404f67d5646819f5e7b.https://gitlab.isc.org/isc-projects/bind9/-/issues/2513Random resolve problem query.c:72742021-02-22T23:02:28ZJakubRandom resolve problem query.c:7274### Summary
Random resolve problem.
### BIND version used
```
root@cnc-dns-internal-01:/var/log/named# named -V
BIND 9.16.12-Ubuntu (Stable Release) <id:aeb943d>
running on Linux x86_64 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb...### Summary
Random resolve problem.
### BIND version used
```
root@cnc-dns-internal-01:/var/log/named# named -V
BIND 9.16.12-Ubuntu (Stable Release) <id:aeb943d>
running on Linux x86_64 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-EkwSA3/bind9-9.16.12=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.38.1
linked to libuv version: 1.38.1
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
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/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
SYSTEM:
VERSION="20.04.2 LTS (Focal Fossa)"
```
### Steps to reproduce
This is a recursive request to translate a domain from our internal servers. This problem occurs randomly with multiple independent domains.
### What is the current *bug* behavior?
Domain is not resolve.
### What is the expected *correct* behavior?
Resolve domains correctly.
### Relevant configuration files
```
options {
listen-on port 53 { 127.0.0.1; XXX;};
directory "/var/cache/bind";
dump-file "/var/cache/bind/cache_dump.db";
statistics-file "/var/cache/bind/named.stats";
memstatistics-file "/var/cache/bind/named.mem.stats";
//dnssec-enable yes;
dnssec-validation no;
empty-zones-enable no;
allow-recursion {
XXX/16;
localhost;
};
allow-query { any; };
allow-notify { none; };
allow-update { none; };
allow-transfer { XXX; };
also-notify { XXX; };
minimal-responses yes;
notify explicit;
lame-ttl 10;
max-ncache-ttl 30;
max-cache-ttl 10;
max-cache-size 512M;
masterfile-format text; /
listen-on-v6 { none; };
};
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { rndc-key; };
};
```
### Relevant logs and/or screenshots
```
/var/log/named/default.log.1:21-Feb-2021 13:00:13.280 client @0x7f25d0032c68 172.29.55.122#41055 (app.smartemailing.cz): query failed (failure) for app.smartemailing.cz/IN/A at query.c:7274
/var/log/named/default.log.1:21-Feb-2021 13:00:13.280 fetch completed at resolver.c:4276 for app.smartemailing.cz/A in 0.036000: failure/success [domain:smartemailing.cz,referral:0,restart:7,qrysent:6,timeout:0,lame:0,quota:0,neterr:6,badresp:0,adberr:0,findfail:0,valfail:0]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2514Windows 10 Insider Dev fails to resolve DoH queries against BIND2021-03-29T12:31:49ZtriaticWindows 10 Insider Dev fails to resolve DoH queries against BIND<!--
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
I cannot get DNS over HTTPS in BIND to work with Windows 10 Insider Dev, whereas I have no problems with Unbound. Unbound returns the full chain for my letsencrypt tls certificate whereas BIND does not, which may explain it.
### BIND version used
BIND 9.17.10-1+ubuntu20.10.1+isc+1-Ubuntu (Development Release) <id:>
### Steps to reproduce
Install Windows 10 Insider (Dev channel) and attempt to resolve queries against a BIND DoH server configured with a letsencrypt (or similar) certificate.
### What is the current *bug* behavior?
DNS resolution fails.
### What is the expected *correct* behavior?
DNS resolution should succeed.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2515Performance drop of 10 % in LTT/main/root zone/dnsgen Perflab scenario2021-05-24T15:18:45ZMichal NowakPerformance drop of 10 % in LTT/main/root zone/dnsgen Perflab scenarioSince isc-projects/bind9!4659 was merged the `LTT/main/root zone/dnsgen` [Perflab scenario](https://perflab.isc.org/#/config/run/5bf195f683ba91a870b29770), and only that one, shows persistent 10 % performance drop from 460,000 to 420,000...Since isc-projects/bind9!4659 was merged the `LTT/main/root zone/dnsgen` [Perflab scenario](https://perflab.isc.org/#/config/run/5bf195f683ba91a870b29770), and only that one, shows persistent 10 % performance drop from 460,000 to 420,000 qps.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2516Configuration reference is missing from the 9.17.9 ARM on the downloads page2021-02-23T12:27:29ZVicky Riskvicky@isc.orgConfiguration reference is missing from the 9.17.9 ARM on the downloads pageThe entire section 4, the Configuration Reference, is missing from the .pdf version of the 9.17.9 ARM on the downloads page. It is present on RTD, just missing on the downloads page.The entire section 4, the Configuration Reference, is missing from the .pdf version of the 9.17.9 ARM on the downloads page. It is present on RTD, just missing on the downloads page.https://gitlab.isc.org/isc-projects/bind9/-/issues/2518IPv4 Flamethrower quit abruptly on FreeBSD 122024-01-22T16:23:03ZMichal NowakIPv4 Flamethrower quit abruptly on FreeBSD 12IPv4 Flamethrower quit abruptly in [stress:recursive:freebsd12:amd64](https://gitlab.isc.org/isc-private/bind9/-/jobs/1517463) CI job over the `v9_11_sub` branch:
```
2021-02-23:03:31:55 INFO: starting TCP generators
2021-02-23:03:31:55 ...IPv4 Flamethrower quit abruptly in [stress:recursive:freebsd12:amd64](https://gitlab.isc.org/isc-private/bind9/-/jobs/1517463) CI job over the `v9_11_sub` branch:
```
2021-02-23:03:31:55 INFO: starting TCP generators
2021-02-23:03:31:55 INFO: starting generator #3 (tcp) on 10.53.0.3 in /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator3
2021-02-23:03:31:55 INFO: (using query file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile)
2021-02-23:03:31:55 INFO: starting generator #4 (tcp) on [fd92:7065:b8e:ffff::3] in /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator4
2021-02-23:03:31:55 INFO: (using query file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile)
2021-02-23:03:31:55 INFO: checking processes, 1 hours 0 minutes left
2021-02-23:03:32:56 INFO: checking processes, 59 minutes left
2021-02-23:03:32:56 ERROR: process with PID file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator3/generator.pid (pid = 60111) is no longer running
```
`generator3/generator.log` does hot have the usual final summary when it exits correctly:
```
--class: "IN"
--dnssec: true
--help: false
--qps-flow: null
--targets: null
--version: false
-F: "inet"
-M: "GET"
-P: "tcp"
-Q: "10000"
-R: false
-T: "A"
-b: null
-c: "10"
-d: "1"
-f: "/var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile"
-g: "file"
-l: "0"
-n: "0"
-o: null
-p: "5300"
-q: "10"
-r: "test.com"
-t: "3"
-v: "99"
GENOPTS: []
TARGET: "10.53.0.3"
file: push "091195.test.example.."
file: push "099598.test.example.."
file: push "011761.test.example.."
file: push "097867.test.example.."
file: push "025447.test.example.."
file: push "037011.test.example.."
file: push "050838.test.example.."
file: push "022788.test.example.."
file: push "093318.test.example.."
file: push "076772.test.example.."
0 key/value generator arguments
binding to 0.0.0.0
flaming target(s) [10.53.0.3] on port 5300 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol tcp
query generator [file] contains 105000 record(s)
rate limit @ 10000 QPS (333.333 QPS per concurrent sender)
0.00130632s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/nan/0ms, in flight: 0, timeouts: 0
1.01032s: send: 3000, avg send: 3000, recv: 2200, avg recv: 2200, min/avg/max resp: 39.3282/225.582/593.608ms, in flight: 822, timeouts: 0
```
There's no core dump file in the artifact archive.
According to logs `named` instances appear to be working at the time when generator #3 quit.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2519named won't start on Windows2021-03-02T14:41:07ZMichal Nowaknamed won't start on WindowsNearly all Windows [system tests fail](https://gitlab.isc.org/isc-projects/bind9/-/pipelines/64375) on `main` since February 19 like this:
```
S:acl:2021-02-22T20:20:39-0800
T:acl:1:A
A:acl:System test acl
I:acl:PORTS:5322,5323,5324,5325...Nearly all Windows [system tests fail](https://gitlab.isc.org/isc-projects/bind9/-/pipelines/64375) on `main` since February 19 like this:
```
S:acl:2021-02-22T20:20:39-0800
T:acl:1:A
A:acl:System test acl
I:acl:PORTS:5322,5323,5324,5325,5326,5327,5328,5329,5330,5331,5332,5333,5334
I:acl:starting servers
I:acl:Couldn't start server C:/builds/isc-projects/bind9/Build/Release/named.exe -D acl-ns2 -X named.lock -m record,size,mctx -c named.conf -d 99 -g -U 4 -T maxcachesize=2097152 >named.run 2>&1 & echo $! (pid=2678)
I:acl:failed
kill: 2678: No such process
I:acl:starting servers failed
R:acl:FAIL
E:acl:2021-02-22T20:20:56-0800
```
I'll investigate further.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2520Concurrently running dns_request-based UDP queries may inadvertently cancel e...2021-10-04T20:01:30ZMichał KępieńConcurrently running dns_request-based UDP queries may inadvertently cancel each other`lib/dns/request.c:find_udp()` [does not set][1] the
`DNS_DISPATCHATTR_EXCLUSIVE` attribute when requesting a
non-port-specific UDP dispatch to use for sending a request created by
`dns_request_createvia()` or `dns_request_createraw()`. ...`lib/dns/request.c:find_udp()` [does not set][1] the
`DNS_DISPATCHATTR_EXCLUSIVE` attribute when requesting a
non-port-specific UDP dispatch to use for sending a request created by
`dns_request_createvia()` or `dns_request_createraw()`. This may result
in multiple different `dns_request`-based queries using the same UDP
dispatch (i.e. UDP socket). Given that `lib/dns/request.c:req_cancel()`
is used for cleaning up both successful and failed requests, destroying
a properly answered request can cause an unrelated, queued send
operation (for a different request using the same UDP socket) to be
canceled. The problem manifests itself in the form of the following log
message:
21-Feb-2021 19:28:45.734 zone verify-ixfr/IN: refresh: failure trying master 10.53.0.2#9500 (source 10.53.0.3#0): operation canceled
(source: [job 1514369][2], `bin/tests/system/mirror/ns3/named.run`)
Note that the above log message is the same as the one mentioned in
https://kb.isc.org/docs/aa-01213, but the root cause is different (the
message above was generated on Windows and thus could not be caused by
Netfilter interference).
Both outgoing NOTIFY messages (on primaries) and SOA refresh queries (on
secondaries) are sent using the `dns_request` API.
An example high-level sequence of events leading to this problem is:
- request A is created using `dns_request_createvia()`,
- request A gets assigned a non-exclusive UDP dispatch,
- request A's query is sent out,
- response to request A's query arrives and its processing starts,
- request B is created using `dns_request_createvia()`,
- request B gets assigned the same UDP dispatch as request A,
- request B's query is queued for sending,
- request A is cleaned up, `req_cancel()` calls `isc_socket_cancel()`,
- request B's query is canceled before it gets put on the wire,
- request B's callback is called with `ISC_R_CANCELED`.
The simplest way to prevent this is to do what `named` [does][3] for its
outgoing resolver queries, which is to use exclusive UDP dispatches
unless `notify-source` and/or `transfer-source` includes a specific port
number (e.g. `transfer-source 10.53.0.1 port 1234;`). Here is a patch
which achieves that:
```diff
diff --git a/lib/dns/request.c b/lib/dns/request.c
index f2c3d3d94d..47429c9850 100644
--- a/lib/dns/request.c
+++ b/lib/dns/request.c
@@ -628,6 +630,11 @@ find_udp_dispatch(dns_requestmgr_t *requestmgr, const isc_sockaddr_t *srcaddr,
default:
return (ISC_R_NOTIMPLEMENTED);
}
+
+ if (isc_sockaddr_getport(srcaddr) == 0) {
+ attrs |= DNS_DISPATCHATTR_EXCLUSIVE;
+ }
+
attrmask = 0;
attrmask |= DNS_DISPATCHATTR_UDP;
attrmask |= DNS_DISPATCHATTR_TCP;
```
Without this patch, I could reproduce this problem in the `mirror`
system test within minutes. With this patch applied, I could not
reproduce it in the same environment for hours, which I think is solid
enough proof to confirm that the root cause analysis above is accurate.
However, the proposed patch still does not solve the problem for query
sources using an explicit port number.
Furthermore, fixing this might not be worth the effort as the dispatch
code is in the process of being migrated to netmgr (!4601), which means
the offending part of the code will be dropped altogether soon enough.
As for BIND 9.11, AFAICT, the problem does not have any severe
real-world consequences:
- SOA queries which fail to be sent out get requeued,
- NOTIFY messages which fail to be sent out are *not* requeued, but
the secondaries should still eventually manage to refresh the zone
(according to the SOA refresh timer).
My guess is that we have been unknowingly hitting this issue in GitLab
CI, but in order for this bug to trigger a test failure, certain
conditions must be met. In the case of the failed `mirror` system test
mentioned above, canceling the first SOA query caused a fallback to the
alternative zone transfer source address (`alt-transfer-source`), which
was not allowed to transfer the `verify-ixfr` zone from `ns2`. This
triggered an AXFR retry down the road, which was unexpected and rightly
caused the test to fail.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/076bb4f98911b9a6fe01bf537ff764bd20d0d439/lib/dns/request.c#L617-630
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/1514369
[3]: https://gitlab.isc.org/isc-projects/bind9/-/blob/076bb4f98911b9a6fe01bf537ff764bd20d0d439/bin/named/server.c#L1301-1313October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2521ThreadSanitizer: data race in memset after #24332021-03-04T10:29:23ZMichal NowakThreadSanitizer: data race in memset after #2433!4659 introduced ThreadSanitizer warnings identified by [GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507021) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507022).
GCC:
```
WARNING: ThreadSanitizer: data race ...!4659 introduced ThreadSanitizer warnings identified by [GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507021) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507022).
GCC:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 free <null>
#1 default_memfree lib/isc/mem.c:440
#2 mem_put lib/isc/mem.c:363
#3 isc__mem_free lib/isc/mem.c:1012
#4 main bin/tools/mdig.c:2231
Previous read of size 1 at 0x000000000005 by thread T1:
#0 dns_name_fromtext lib/dns/name.c:1121
#1 sendquery bin/tools/mdig.c:596
#2 sendqueries bin/tools/mdig.c:779
#3 dispatch lib/isc/task.c:1152
#4 run lib/isc/task.c:1344
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 main bin/tools/mdig.c:2148
SUMMARY: ThreadSanitizer: data race in __interceptor_free
```
Clang:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 memset <null>
#1 memset /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10
#2 mem_put lib/isc/mem.c:361:3
#3 isc__mem_free lib/isc/mem.c:1012:2
#4 main bin/tools/mdig.c:2231:3
Previous read of size 4 at 0x000000000001 by thread T1:
#0 sendquery bin/tools/mdig.c:764:10
#1 sendqueries bin/tools/mdig.c:779:3
#2 dispatch lib/isc/task.c:1152:7
#3 run lib/isc/task.c:1344:2
Location is heap block of size 1120 at 0x000000000010 allocated by main thread:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:411:8
#2 mem_get lib/isc/mem.c:343:8
#3 mem_allocateunlocked lib/isc/mem.c:918:7
#4 isc__mem_allocate lib/isc/mem.c:935:7
#5 clone_default_query bin/tools/mdig.c:1831:10
#6 parse_args bin/tools/mdig.c:1959:11
#7 parse_args bin/tools/mdig.c:2049:4
#8 main bin/tools/mdig.c:2124:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 main bin/tools/mdig.c:2148:2
SUMMARY: ThreadSanitizer: data race in memset
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2522Monitoring zone transfer dropped due to quota limits2022-03-01T09:58:59ZPeter DaviesMonitoring zone transfer dropped due to quota limitsMonitoring zone transfer dropped due to quota limits:
The maximum number of simultaneous outgoing zone transfers is defined by the value of “transfers-out” which is configurable within “options” and currently defaults to 10.
To b...Monitoring zone transfer dropped due to quota limits:
The maximum number of simultaneous outgoing zone transfers is defined by the value of “transfers-out” which is configurable within “options” and currently defaults to 10.
To better configure and supervise their servers, it would be useful for administrators to be able to retrieve information about the number of zone transfers that get dropped due to this quota limit.
An incremental counter that would record these occurrences has been suggested. The value of this counter could be exposed on the statistics channel.
[RT #17780 ](https://support.isc.org/Ticket/Display.html?id=17780)Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2524Coccinelle unhappy about lib/ns/tests/nstest.c2023-11-01T07:36:21ZMichal NowakCoccinelle unhappy about lib/ns/tests/nstest.cCoccinelle is [unhappy](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1522218) about `lib/ns/tests/nstest.c` on `main` and `v9_16`:
```
EXN: Failure("rule starting on line 26: already tagged token:\nC code context\nFile \"./lib/ns/te...Coccinelle is [unhappy](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1522218) about `lib/ns/tests/nstest.c` on `main` and `v9_16`:
```
EXN: Failure("rule starting on line 26: already tagged token:\nC code context\nFile \"./lib/ns/tests/nstest.c\", line 716, column 1, charpos = 16367\n around = 'if',\n whole content = \tif (qctx != NULL) {")
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2525Automated test for upgrading BIND2023-11-02T16:26:05ZVicky Riskvicky@isc.orgAutomated test for upgrading BINDsuggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the f...suggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the first scenario to address is migrating from the latest 9.11 version to the latest 9.16 version.
It might be good to measure how long the update takes, the time to reload (in case either of these are surprising that might indicate a problem), of course that bind restarts and reloads, maybe run a few queries??Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2526Example configuration for authoritative DNS server for docker container is mi...2021-02-24T20:45:03ZMalte BögershausenExample configuration for authoritative DNS server for docker container is misleadingThe example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```...The example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```
mean that the DNS server is not accessible from outside the container (and there is no reason to access it from inside the container).
Additionally there is no filename suggested for the config file. If `named.conf` is used the default structure for config files is overridden.https://gitlab.isc.org/isc-projects/bind9/-/issues/2527Confusing IXFR logging in BIND 9.17.7+2022-03-01T09:41:21ZMichał KępieńConfusing IXFR logging in BIND 9.17.7+A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff...A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff50b899ed4264d1d as it removed an early `return`
statement from `lib/dns/xfrin.c:xfrin_recv_done()`.
Here is what is logged for a successful IXFR in BIND 9.17.7+:
24-Feb-2021 22:17:23.280 zone nil/IN: transferred serial 2
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: failed while receiving responses: no more
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer status: IXFR failed
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 4 records, 179 bytes, 0.016 secs (11187 bytes/sec) (serial 2)
These messages are quite confusing because by the time the "failed while
receiving responses: no more" message is logged, the IXFR is already
journalled and applied to the zone.
The simplest solution seems to be to "promote" `ISC_R_NOMORE` to
`ISC_R_SUCCESS` [after going through the ANSWER section of the
transfer][1].
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/965848a11a1032d66807811e2f7e15676760d67f/lib/dns/xfrin.c#L1342-1344Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2528named does not check RDATA of the SOA record ending an AXFR2021-06-24T14:32:42ZMichał Kępieńnamed does not check RDATA of the SOA record ending an AXFRWhile `lib/dns/xfrin.c:xfr_rr()` [checks][1] whether the last RR in the
AXFR stream is an SOA record, it does not check its RDATA.
[RFC 5936 section 2.2][2] says:
An AXFR response that is transferring the zone's contents will
...While `lib/dns/xfrin.c:xfr_rr()` [checks][1] whether the last RR in the
AXFR stream is an SOA record, it does not check its RDATA.
[RFC 5936 section 2.2][2] says:
An AXFR response that is transferring the zone's contents will
consist of a series (which could be a series of length 1) of DNS
messages. In such a series, the first message MUST begin with the
SOA resource record of the zone, and the last message MUST conclude
with the same SOA resource record.
Meanwhile, `named` accepts the following AXFR stream as valid:
```
nil. 300 SOA localhost. root.nil. 3 300 300 604800 300
nil. 300 NS localhost.
nil. 300 SOA localhost. root.nil. 1 300 300 604800 300
```
This results in the following (rather confusing) set of log messages
being generated (note the serial number discrepancies):
```
24-Feb-2021 22:36:49.732 zone nil/IN: transferred serial 1
24-Feb-2021 22:36:49.732 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer status: success
24-Feb-2021 22:36:49.732 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 3 records, 121 bytes, 0.001 secs (121000 bytes/sec) (serial 3)
```
After processing the above transfer, `named` puts the SOA record with
serial number 1 into the zone database.
I do not think this problem poses a security threat, but I am reporting
it in a confidential issue to rather be safe than sorry.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/965848a11a1032d66807811e2f7e15676760d67f/lib/dns/xfrin.c#L637
[2]: https://tools.ietf.org/html/rfc5936#section-2.2June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2529Add __attribute__((malloc)) for isc_mempool_get2021-05-05T18:14:45ZMark AndrewsAdd __attribute__((malloc)) for isc_mempool_getisc_mempool_get() can fail so we need to ensure that all instances the returned value is checked for NULL. `__attribute__((malloc))` will catch missing cases at compile time where it is supported.isc_mempool_get() can fail so we need to ensure that all instances the returned value is checked for NULL. `__attribute__((malloc))` will catch missing cases at compile time where it is supported.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2530Bind 9.16.11 segfault on DLZ with mysql2022-03-01T09:45:37ZjpsollieBind 9.16.11 segfault on DLZ with mysql### Summary
When running bind with DLZ against a mysql database, the system aborts with segfault
This database is set up to answer all spam domains
### BIND version used
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 ...### Summary
When running bind with DLZ against a mysql database, the system aborts with segfault
This database is set up to answer all spam domains
### BIND version used
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 5.10.17+ #8 SMP Mon Feb 22 18:54:47 CET 2021
built by make with '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--docdir=/usr/share/doc/bind-9.16.11' '--htmldir=/usr/share/doc/bind-9.16.11/html' '--with-sysroot=/' '--libdir=/usr/lib64' 'AR=/usr/bin/x86_64-pc-linux-gnu-ar' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--without-readline' '--with-openssl=/usr' '--without-cmocka' '--enable-linux-caps' '--disable-dnsrps' '--disable-dnstap' '--disable-fixed-rrset' '--without-dlz-bdb' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--without-gssapi' '--without-json-c' '--without-dlz-ldap' '--with-dlz-mysql' '--without-dlz-odbc' '--without-dlz-postgres' '--without-lmdb' '--without-libxml2' '--with-zlib' '--without-python' '--with-maxminddb' '--enable-geoip' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=znver1 -O3 -ggdb3 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.0
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/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. install BIND 9.16.11 with DLZ support
2. install mariadb 10.5.8
3. install DLZ converted spam domain list (view attachment)
4. install DLZ connector
### What is the current *bug* behavior?
Bind crashes with segfaults, when using file instead of dlz, everything is OK.
### What is the expected *correct* behavior?
Bind loads zones + runs correctly
### Relevant configuration files
DLZ connector:
```
dlz "null_dlz" {
database "mysql
{host=127.0.0.1 port=3306 dbname=dlz_null ssl=false user=named pass=named}
{select '$zone$' AS zone from dns_records where zone = 'null' OR zone = '$zone$' LIMIT 1}
{select ttl, type, mx_priority, case when lower(type)='txt' then concat('\"', data, '\"')
else data end from dns_records where (zone = 'null' OR zone = '$zone$') and (host = '*' OR host = '$record$') AND NOT (type = 'SOA' or type='NS')}
{select ttl, type, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum
from dns_records where (zone = 'null' OR zone = '$zone$') AND (type = 'SOA' or type='NS')}
{select ttl, type, host, mx_priority, data, resp_person, serial, refresh, retry, expire,
minimum from dns_records where (zone = 'null' OR zone = '$zone$') and NOT (type = 'SOA' or type = 'NS')}
{select '$zone$' AS zone from xfr_table where (zone = 'null' OR zone = '$zone$') and client = '$client$'}
{update data_count set count = count + 1 where (zone ='null' OR zone = '$zone$') AND client = '$client$'}";
search no;
};
include "blacklist.inc.dlz"
```
SQL database dump:
```
Enter password:
-- MariaDB dump 10.18 Distrib 10.5.8-MariaDB, for Linux (x86_64)
--
-- Host: localhost Database: dlz_null
-- ------------------------------------------------------
-- Server version 10.5.8-MariaDB-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `data_count`
--
DROP TABLE IF EXISTS `data_count`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `data_count` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`count` bigint(20) unsigned NOT NULL DEFAULT 0,
`zone` varchar(255) DEFAULT 'null',
`client` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `zone` (`zone`)
) ENGINE=Aria AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `data_count`
--
LOCK TABLES `data_count` WRITE;
/*!40000 ALTER TABLE `data_count` DISABLE KEYS */;
INSERT INTO `data_count` VALUES (1,0,'null','');
/*!40000 ALTER TABLE `data_count` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `dns_records`
--
DROP TABLE IF EXISTS `dns_records`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `dns_records` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`zone` varchar(255) NOT NULL,
`host` varchar(255) NOT NULL DEFAULT '@',
`type` varchar(255) NOT NULL,
`data` text DEFAULT NULL,
`ttl` int(11) NOT NULL DEFAULT 86400,
`mx_priority` int(11) DEFAULT NULL,
`refresh` int(11) DEFAULT NULL,
`retry` int(11) DEFAULT NULL,
`expire` int(11) DEFAULT NULL,
`minimum` int(11) DEFAULT NULL,
`serial` bigint(20) DEFAULT NULL,
`resp_person` varchar(255) DEFAULT NULL,
`primary_ns` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `type` (`type`),
KEY `host` (`host`),
KEY `zone` (`zone`),
KEY `zone_host_index` (`zone`(30),`host`(30)),
KEY `type_index` (`type`(8))
) ENGINE=Aria AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `dns_records`
--
LOCK TABLES `dns_records` WRITE;
/*!40000 ALTER TABLE `dns_records` DISABLE KEYS */;
INSERT INTO `dns_records` VALUES (1,'null','@','SOA',NULL,180,NULL,10800,7200,604800,86400,2011091101,'localhost.','admin.localhost.'),(2,'null','@','NS','localhost',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(3,'null','@','A','0.0.0.0',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(4,'null','*','A','0.0.0.0',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(5,'null','*','AAAA','::',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
/*!40000 ALTER TABLE `dns_records` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `xfr_table`
--
DROP TABLE IF EXISTS `xfr_table`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `xfr_table` (
`zone` varchar(255) NOT NULL,
`client` varchar(255) NOT NULL,
KEY `zone` (`zone`),
KEY `client` (`client`),
KEY `zone_client_index` (`zone`(30),`client`(30))
) ENGINE=Aria DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `xfr_table`
--
LOCK TABLES `xfr_table` WRITE;
/*!40000 ALTER TABLE `xfr_table` DISABLE KEYS */;
INSERT INTO `xfr_table` VALUES ('null','*');
/*!40000 ALTER TABLE `xfr_table` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2021-02-25 10:21:58
```
GDB backtrace:
```
(gdb) setargs -d 1 -u named -n 1 -g -c /etc/named/named2.conf
(gdb) run
... -- truncated
Query String: select 'paczkonnat.app' AS zone from dns_records where zone = 'null' OR zone = 'paczkonnat.app' LIMIT 1
Thread 3 "isc-worker0000" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6211640 (LWP 20149)]
0x00007ffff7116746 in strlen () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7116746 in strlen () from /lib64/libc.so.6
#1 0x00005555555ab3bd in sdlzh_build_querystring (mctx=mctx@entry=0x5555555eb090, querylist=0x7fffd6acd210) at ../../contrib/dlz/drivers/sdlz_helper.c:287
#2 0x00005555555ac8ac in mysql_get_resultset (zone=<optimized out>, record=<optimized out>, client=<optimized out>, query=5, dbdata=0x7fffd6adfd68, rs=0x0) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:276
#3 0x00005555555ad5f7 in mysql_findzone (driverarg=<optimized out>, methods=<optimized out>, clientinfo=<optimized out>, name=0x7ffff6210740 "paczkonnat.app", dbdata=0x7fffd6adfd68) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:508
#4 mysql_findzone (driverarg=<optimized out>, dbdata=0x7fffd6adfd68, name=0x7ffff6210740 "paczkonnat.app", methods=<optimized out>, clientinfo=<optimized out>) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:478
#5 0x00007ffff7e70cc6 in dns_sdlzfindzone (driverarg=0x7ffff6b552e0, dbdata=0x7fffd6adfd68, mctx=0x5555555eb090, rdclass=<optimized out>, name=0x7fffde822720, methods=0x0, clientinfo=0x0, dbp=0x7ffff6210bd8) at sdlz.c:1681
#6 0x00007ffff7ed2c84 in zone_load (zone=0x7fffde8225e0, flags=<optimized out>, locked=locked@entry=true) at zone.c:2159
#7 0x00007ffff7ed3141 in zone_asyncload (task=0x7ffff091f220, event=<optimized out>) at zone.c:2303
#8 0x00007ffff7c91150 in dispatch (threadid=<optimized out>, manager=0x7ffff6b60010) at task.c:1152
#9 run (queuep=<optimized out>) at task.c:1344
#10 0x00007ffff7574fde in start_thread () from /lib64/libpthread.so.0
#11 0x00007ffff717973f in clone () from /lib64/libc.so.6
(gdb)
```
[blacklist.inc.dlz](/uploads/ce48ba8e26a6e4e5657c4a5d22e12d98/blacklist.inc.dlz)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2531TSAN: rrl: 15 sanitizer report(s) found2021-03-04T10:29:39ZMatthijs Mekkingmatthijs@isc.orgTSAN: rrl: 15 sanitizer report(s) foundJob [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
=========
S:rrl:2021-02-25T08:54:57+0000
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTS:18835,18836,18837,188...Job [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
=========
S:rrl:2021-02-25T08:54:57+0000
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTS:18835,18836,18837,18838,18839,18840,18841,18842,18843,18844,18845,18846,18847
I:rrl:starting servers
I:rrl:exit status: 0
I:rrl:stopping servers
I:rrl:15 sanitizer report(s) found
R:rrl:FAIL
E:rrl:2021-02-25T08:55:24+0000
FAIL rrl (exit status: 1)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2532TSAN: digdelv:3 sanitizer report(s) found2021-03-04T10:29:50ZMatthijs Mekkingmatthijs@isc.orgTSAN: digdelv:3 sanitizer report(s) foundS:digdelv:2021-02-18T22:30:54+0000
Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
T:digdelv:1:A
A:digdelv:System test digdelv
I:digdelv:PORTS:20841,20842...S:digdelv:2021-02-18T22:30:54+0000
Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
T:digdelv:1:A
A:digdelv:System test digdelv
I:digdelv:PORTS:20841,20842,20843,20844,20845,20846,20847,20848,20849,20850,20851,20852,20853
I:digdelv:starting servers
...
...
I:digdelv:checking mdig +multi +norrcomments works for DNSKEY (when default is rrcomments)(89)
I:digdelv:failed
I:digdelv:checking mdig +multi +norrcomments works for SOA (when default is rrcomments)(90)
I:digdelv:failed
I:digdelv:check mdig +yaml output (91)
I:digdelv:failed
...
I:digdelv:exit status: 3
I:digdelv:stopping servers
I:digdelv:3 sanitizer report(s) found
R:digdelv:FAIL
E:digdelv:2021-02-18T22:31:35+0000
FAIL digdelv (exit status: 1)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2533TSAN: pipelined:2 sanitizer report(s) found2021-03-04T14:06:23ZMatthijs Mekkingmatthijs@isc.orgTSAN: pipelined:2 sanitizer report(s) foundJob [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
===============
S:pipelined:2021-02-25T09:00:28+0000
T:pipelined:1:A
A:pipelined:System test pipelined
I:p...Job [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
===============
S:pipelined:2021-02-25T09:00:28+0000
T:pipelined:1:A
A:pipelined:System test pipelined
I:pipelined:PORTS:19342,19343,19344,19345,19346,19347,19348,19349,19350,19351,19352,19353,19354
I:pipelined:starting servers
I:pipelined:check pipelined TCP queries
I:pipelined:check pipelined TCP queries using mdig
I:pipelined:check keep-response-order
I:pipelined:check keep-response-order using mdig
I:pipelined:check mdig -4 -6
I:pipelined:check mdig -4 with an IPv6 server address
I:pipelined:exit status: 0
I:pipelined:stopping servers
I:pipelined:2 sanitizer report(s) found
R:pipelined:FAIL
E:pipelined:2021-02-25T09:00:49+0000
FAIL pipelined (exit status: 1)
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2534Cut-paste-replace error for ignore-secs-opt2021-03-22T10:57:19ZMichal NowakCut-paste-replace error for ignore-secs-opt`ecs` and `ignore-ecs-opt` were mapped to the same value.
```
server 10.53.0.8 {
ecs no;
ignore-ecs-opt yes;
};
```
produced `already exists`.
---
Originally reported as https://gitlab.isc.org/isc-private/bind9/-/issues/37.
~"...`ecs` and `ignore-ecs-opt` were mapped to the same value.
```
server 10.53.0.8 {
ecs no;
ignore-ecs-opt yes;
};
```
produced `already exists`.
---
Originally reported as https://gitlab.isc.org/isc-private/bind9/-/issues/37.
~"v9.16-S" fix: https://gitlab.isc.org/isc-private/bind9/-/merge_requests/242
~"v9.11-S" backported fix: https://gitlab.isc.org/isc-private/bind9/-/merge_requests/251March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2535Release Checklist for BIND 9.11.29, BIND 9.11.29-S1, BIND 9.16.13, BIND 9.16....2021-03-22T13:50:13ZMichal NowakRelease Checklist for BIND 9.11.29, BIND 9.11.29-S1, BIND 9.16.13, BIND 9.16.13-S1, BIND 9.17.11## Release Schedule
**Code Freeze:** Wednesday, March 3rd, 2021
**Tagging Deadline:** Monday, March 8th, 2021
**Public Release:** Wednesday, March 17th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone wi...## Release Schedule
**Code Freeze:** Wednesday, March 3rd, 2021
**Tagging Deadline:** Monday, March 8th, 2021
**Public Release:** Wednesday, March 17th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
* [9.17.11](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
* [9.16.13](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
* [9.11.29](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
* [9.17.11](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)¬[label_name][]=Release%20Notes&target_branch=main)
* [9.16.13](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)¬[label_name][]=Release%20Notes&target_branch=v9_16)
* [9.11.29](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
* [9.17.11](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)&label_name[]=No%20CHANGES&target_branch=main)
* [9.16.13](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)&label_name[]=No%20CHANGES&target_branch=v9_16)
* [9.11.29](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=March%202021%20(9.11.29%2C%209.11.29-S1%2C%209.16.13%2C%209.16.13-S1%2C%209.17.11)&label_name[]=No%20CHANGES&target_branch=v9_11)
## 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] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### 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)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [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] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** 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] ***(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.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michal NowakMichal Nowak2021-03-17https://gitlab.isc.org/isc-projects/bind9/-/issues/2536inline-signing documentation doesn't match reality2021-05-27T13:27:13ZMark Andrewsinline-signing documentation doesn't match realityinline-signing is documented as being inherited from options / view but is only accepted at the zone level.
I think the current behaviour (only effective at the zone level) is sensible and intend to fix the doc (if needed) after moving ...inline-signing is documented as being inherited from options / view but is only accepted at the zone level.
I think the current behaviour (only effective at the zone level) is sensible and intend to fix the doc (if needed) after moving to the correct cause set in namedconf.cMay 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2537Memory leak when changing config files and execute rndc reload2021-03-10T09:50:02Zpiolink-kychoMemory leak when changing config files and execute rndc reload### Summary
- I found memory leak while conducting a stress test.
- There is a memory leak when performing rndc reload after changing config files.
- I repeated apply many config file states and few config file states.
- Cha...### Summary
- I found memory leak while conducting a stress test.
- There is a memory leak when performing rndc reload after changing config files.
- I repeated apply many config file states and few config file states.
- Change config files and execute rndc reload
- I found a memory leak after the above process.
### BIND version used
- Reproduced in both versions
- 9.10.3-P4
```
# named -V
BIND 9.10.3-P4 <id:1584839>
built by make with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=no' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'LIBS=-lyaml' 'CPPFLAGS='
compiled by GCC 4.5.2
compiled with OpenSSL version: OpenSSL 1.0.1u 22 Sep 2016
linked to OpenSSL version: OpenSSL 1.0.1u 22 Sep 2016
compiled with libxml2 version: 2.7.8
linked to libxml2 version: 20708
```
- 9.16.1-Ubuntu
```
root@2b09087ca104:/# named -V
BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
running on Linux x86_64 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-yEt4rt/bind9-9.16.1=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
- Use bind config file path : /etc/bind
- Switch between two configuration file state and rndc reload
- The both config state files below are included in the attached file.
- Many file state: 10062 db-reverse-zone files, 387 db-zone files, 131 named.conf.view files, 15 etc files
- few file state: 0 db-reverse-zone files, 3 db-zone files, 3 named.views files, 15 etc files,
- No traffic required
- Reproduce order
1. Check current named RSS value
2. Execute attached script (reprocduce.sh) or execute command written at reproduce.sh
- This script switch bind config file state and execute rndc reload command
- reproduce.sh
```
cp ./few_files_state/* /etc/bind
rndc reload
cp ./many_files_state/* /etc/bind
rndc reload
```
3. Check current named RSS value
4. Repeat 2~3 until memory is increased.
- To reproduce quickly, in my case execute script like below
`while true; do ./reproduce.sh; sleep 1; done`
### What is the current *bug* behavior?
- The memory has not decreased since it increased.
- I repeat apply many config file states and few config file states.
- In my opinion, the memory usage shouldn't increase in this case.
### What is the expected *correct* behavior?
- The increased memory should be reduced again. Otherwise, memory usage should not continue to increase.
### Relevant configuration files
[reproduce_memoryleak.zip](/uploads/6ae5b93c9db53e657c3453b1dbda28f8/reproduce_memoryleak.zip)
### Relevant logs and/or screenshots
- Check named RSS value
- named version: BIND 9.10.3-P4 <id:1584839>
```
2021. 02. 16. (화) 12:46:10 UTC-9
bind 17326 34.3 3.4 2677524 2245704 ? Ssl 12:43 1:01 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:46:40 UTC-9
bind 17326 96.1 6.5 4840216 4321732 ? Ssl 12:43 3:21 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:47:10 UTC-9
bind 17326 178 8.5 6199140 5623272 ? Ssl 12:43 7:07 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:47:40 UTC-9
bind 17326 239 10.5 7490328 6942948 ? Ssl 12:43 10:46 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:48:10 UTC-9
bind 17326 290 13.4 9390872 8817968 ? Ssl 12:43 14:32 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:48:40 UTC-9
bind 17326 333 14.6 10308376 9606460 ? Ssl 12:43 18:19 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:49:10 UTC-9
bind 17326 366 15.8 11081204 10448852 ? Ssl 12:43 22:02 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:49:40 UTC-9
bind 17326 395 17.7 12391924 11676968 ? Ssl 12:43 25:46 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:50:11 UTC-9
bind 17326 420 19.2 13299940 12646596 ? Ssl 12:43 29:32 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:50:41 UTC-9
bind 17326 443 20.5 14255312 13505096 ? Ssl 12:43 33:19 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:51:11 UTC-9
bind 17326 463 22.0 15172816 14494420 ? Ssl 12:43 37:09 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:51:41 UTC-9
bind 17326 479 23.3 15959248 15333864 ? Ssl 12:43 40:51 /usr/sbin/named -u bind -f
2021. 02. 16. (화) 12:52:11 UTC-9
bind 17326 495 24.6 16942320 16221216 ? Ssl 12:43 44:41 /usr/sbin/named -u bind -f
...
2021. 02. 16. (화) 13:00:13 UTC-9
bind 17326 608 44.8 30128916 29454552 ? Ssl 12:43 103:45 /usr/sbin/named -u bind -f
```
- After 1 minute named was killed by oom-killer
- named version : BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
```
root@2b09087ca104:~# while true; do date; ps aufx| grep named | grep -v grep; sleep 3; done
Mon Feb 8 19:04:08 KST 2021
bind 5955 6.3 11.0 2453564 1811032 ? Ssl 19:03 0:02 /usr/sbin/named -u bind
Mon Feb 8 19:04:11 KST 2021
bind 5955 5.8 11.0 2453564 1811032 ? Ssl 19:03 0:02 /usr/sbin/named -u bind
Mon Feb 8 19:04:14 KST 2021
bind 5955 5.4 11.0 2453564 1811032 ? Ssl 19:03 0:02 /usr/sbin/named -u bind
Mon Feb 8 19:04:17 KST 2021
bind 5955 9.0 18.7 3629380 3064064 ? Ssl 19:03 0:03 /usr/sbin/named -u bind
Mon Feb 8 19:04:20 KST 2021
bind 5955 10.9 22.1 4217156 3617260 ? Ssl 19:03 0:05 /usr/sbin/named -u bind
Mon Feb 8 19:04:23 KST 2021
bind 5955 13.2 22.3 4215108 3653520 ? Ssl 19:03 0:06 /usr/sbin/named -u bind
Mon Feb 8 19:04:26 KST 2021
bind 5955 15.2 24.6 4542788 4030776 ? Ssl 19:03 0:08 /usr/sbin/named -u bind
Mon Feb 8 19:04:29 KST 2021
bind 5955 16.9 28.2 5132612 4606560 ? Ssl 19:03 0:09 /usr/sbin/named -u bind
Mon Feb 8 19:04:32 KST 2021
bind 5955 18.8 31.2 5656900 5101028 ? Ssl 19:03 0:11 /usr/sbin/named -u bind
Mon Feb 8 19:04:35 KST 2021
bind 5955 18.2 31.2 5656900 5101820 ? Ssl 19:03 0:11 /usr/sbin/named -u bind
Mon Feb 8 19:04:38 KST 2021
bind 5955 19.6 31.7 5787972 5188112 ? Ssl 19:03 0:12 /usr/sbin/named -u bind
Mon Feb 8 19:04:41 KST 2021
bind 5955 20.9 36.6 6576452 5986012 ? Ssl 19:03 0:14 /usr/sbin/named -u bind
Mon Feb 8 19:04:44 KST 2021
bind 5955 22.3 39.5 7033156 6464520 ? Ssl 19:03 0:15 /usr/sbin/named -u bind
Mon Feb 8 19:04:47 KST 2021
bind 5955 22.7 39.6 7033156 6476136 ? Ssl 19:03 0:16 /usr/sbin/named -u bind
Mon Feb 8 19:04:50 KST 2021
bind 5955 24.0 41.3 7295300 6746964 ? Ssl 19:03 0:18 /usr/sbin/named -u bind
Mon Feb 8 19:04:53 KST 2021
bind 5955 25.0 44.2 7754052 7222428 ? Ssl 19:03 0:20 /usr/sbin/named -u bind
Mon Feb 8 19:04:56 KST 2021
bind 5955 25.4 46.0 8016196 7525500 ? Ssl 19:03 0:21 /usr/sbin/named -u bind
Mon Feb 8 19:04:59 KST 2021
bind 5955 26.3 49.0 8540484 8014080 ? Ssl 19:03 0:22 /usr/sbin/named -u bind
Mon Feb 8 19:05:02 KST 2021
bind 5955 27.0 53.6 9329476 8758896 ? Ssl 19:03 0:24 /usr/sbin/named -u bind
Mon Feb 8 19:05:05 KST 2021
bind 5955 27.2 53.8 9329476 8786412 ? Ssl 19:03 0:25 /usr/sbin/named -u bind
^[\Mon Feb 8 19:05:08 KST 2021
bind 5955 26.5 53.8 9329476 8786412 ? Ssl 19:03 0:25 /usr/sbin/named -u bind
```
### Possible fixes
- None
- I want to know if this memory usage is correct. If it is in the right condition, please explain a little bit.
Thank you.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2538BIND 9.17 build process leaving files in unexpected locations?2021-04-28T13:35:17ZMichael McNallyBIND 9.17 build process leaving files in unexpected locations?Based on an [issue reported by a support customer](https://support.isc.org/Ticket/Display.html?id=18059).
The customer says:
```
I configured 9.17.10 with
configure --enable-full-report CFLAGS='-O3 -pipe -Wall -g -DISC_SOCKET_MAXEVENTS...Based on an [issue reported by a support customer](https://support.isc.org/Ticket/Display.html?id=18059).
The customer says:
```
I configured 9.17.10 with
configure --enable-full-report CFLAGS='-O3 -pipe -Wall -g -DISC_SOCKET_MAXEVENTS=512' LIBUV_CFLAGS='-I/home/rx5330/dns/bind/libuv-v1.40.0/include' LIBUV_LIBS='-L/home/rx5330/dns/bind/libuv-v1.40.0/.libs -luv' PKG_CONFIG_PATH='/home/rx5330/dns/bind/libuv-v1.40.0' --prefix=/opt/ATTdns --sysconfdir=/var/named --localstatedir=/var --disable-static --with-pic --with-libxml2 --without-lmdb --enable-largefile --enable-fixed-rrset --with-json-c --disable-dnstap
And I installed with
make -j40 install DESTDIR=/home/rx5330/dns/bind/debian/attbind AM_UPDATE_INFO_DIR=no
Yet when I look at that DESTDIR I see
find home -type f
home/rx5330/dns/bind/bind-9.17.10/bin/tests/system/dyndb/driver/sample.so
home/rx5330/dns/bind/bind-9.17.10/bin/tests/system/dyndb/driver/sample.la
home/rx5330/dns/bind/bind-9.17.10/bin/tests/system/dlzexternal/driver/dlzexternal.so
home/rx5330/dns/bind/bind-9.17.10/bin/tests/system/dlzexternal/driver/dlzexternal.la
home/rx5330/dns/bind/bind-9.17.10/bin/tests/system/hooks/driver/test-async.so
home/rx5330/dns/bind/bind-9.17.10/bin/tests/system/hooks/driver/test-async.la
I'm not sure why it's installing these tests in the first place, but it certainly shouldn't be installing them using the location where I built the package.
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2539systemd unit file's PIDFile path not found for COPR package2021-03-01T12:08:01ZKenneth Portersystemd unit file's PIDFile path not found for COPR packageThe systemd unit file in the Red Hat COPR package has a PIDFile setting not found in the sample named.conf and apparently not compiled in. systemctl fails with a timeout waiting for the PIDFile to be created. It hangs for many seconds be...The systemd unit file in the Red Hat COPR package has a PIDFile setting not found in the sample named.conf and apparently not compiled in. systemctl fails with a timeout waiting for the PIDFile to be created. It hangs for many seconds before failing.
The value provided is:
PIDFile=/var/opt/isc/scls/isc-bind/run/named/named.pid
A better choice might be:
PIDFile=/run/named/named.pid
The example named.conf should include this setting.
BIND 9.16.12 (Stable Release) <id:aeb943d>
OS is CentOS 8.
Package from here:
https://copr.fedorainfracloud.org/coprs/isc/bind/
I edited the unit file's PIDFile setting (using a systemd drop-in file) and the service came up normally, using my configuration from named 9.10.Michał KępieńMichał Kępień