BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-02-03T14:01:33Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1144Encrypted DNS - RFC 8484, DNS over HTTPS, DOH (also DoT comments)2021-02-03T14:01:33ZVicky Riskvicky@isc.orgEncrypted DNS - RFC 8484, DNS over HTTPS, DOH (also DoT comments)February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1295Implement PROXY protocol2023-11-27T12:46:04ZOndřej SurýImplement PROXY protocolThe PowerDNS folks are now considering dropping the XPF in favour of the [PROXY protocol](http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) which is pretty much reasonable.The PowerDNS folks are now considering dropping the XPF in favour of the [PROXY protocol](http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) which is pretty much reasonable.BIND 9.19.xArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1575Design document for native DoH RFC 84842020-04-04T06:05:54ZVicky Riskvicky@isc.orgDesign document for native DoH RFC 8484Creating a separate issue to create the initial design for DoH, specifying the components to be used, high level flow. Presumably this will be put in a wiki page? It should be sent to the bind-dev list as well.Creating a separate issue to create the initial design for DoH, specifying the components to be used, high level flow. Presumably this will be put in a wiki page? It should be sent to the bind-dev list as well.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1641RFC8484, DOH support in DIG (and any other relevant utilities)2022-04-26T13:17:14ZVicky Riskvicky@isc.orgRFC8484, DOH support in DIG (and any other relevant utilities)Creating a separate issue for this.Creating a separate issue for this.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/2217TLS offloading with DOH2021-02-03T16:10:01ZVicky Riskvicky@isc.orgTLS offloading with DOHApparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate...Apparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate dance
* client authentication - TLS client certs + augmenting HTTP headers with proxied-for information
* logging at HTTP level
* offload the TLS processing on a dedicated system to reduce the impact of TLS on the BIND server and to centralize the certificate mgmt
- [ ] Please test this to see if it works
- [ ] Please document that this is supported in the ARM
ref: https://support.isc.org/Ticket/ModifyLinks.html?id=16797February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2272Backport DoT/DoH-related merge requests2021-06-14T19:24:02ZMichał KępieńBackport DoT/DoH-related merge requestsThis issue contains a list of DoT/DoH-related merge requests which
should be eventually backported to `v9_16`, but may need to wait in a
queue for a while before that happens.
**Merge requests that *must* be backported:**
- [ ] !3532...This issue contains a list of DoT/DoH-related merge requests which
should be eventually backported to `v9_16`, but may need to wait in a
queue for a while before that happens.
**Merge requests that *must* be backported:**
- [ ] !3532 Add TLS support to named and dig
- [ ] !4373 Add support to link with libssl
- [x] !4584 refactor TLSDNS module to work with libuv/ssl directly
- [ ] !4571 Add support for incoming tranfers via XoT
- [ ] !4644 Resolve "Encrypted DNS - RFC 8484, DNS over HTTPS, DOH (also DoT comments)"
- [ ] !4653 Resolve "too easy to configure unencrypted DoH"
- [ ] !4689 report libnghttp2 version in 'named -V'
- [ ] !4766 Fix comparison between signed and unsigned integer expressions
- [ ] !4672 Resolve "RFC8484, DoH support in DIG (and any other relevant utilities)"
- [ ] !4794 Resolve "warning: array subscript is of type 'char' on NetBSD 9"
- [ ] !4792 Load full certificate chain from a certificate chain file
- [ ] !4803 Fix a XoT crash
- [ ] !4806 Resolve "Does not compile without deprecated OpenSSL APIs"
- [ ] !4820 Fix dangling uvreq when data is sent from tlsdns_cycle()
- [ ] !4809 Fix memory accounting bug in TLSDNS
- [ ] !4824 Call isc__nm_tlsdns_failed_read on tls_error to cleanup the socket
- [ ] !4851 TLS transport code refactoring and unit tests
- [ ] !4863 Fix "doth" system test failure with SSL_ERROR_SYSCALL (5)
- [ ] !4893 Merge the tls_test.c into netmgr_test.c and extend the tests suite
- [ ] !4906 Resolve "tlsstream.c: warning: comparison of integer expressions of different signedness"
- [ ] !5005 Fix flawed DoH unit tests logic and some corner cases in the DoH code. Fix doh_test failure on FreeBSD 13.0
- [ ] !5019 DoH flamethrower fixes
- [ ] !5024 Add DoH quota tests
- [ ] !5121 HTTP/2 write bufferingJuly 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/2429Consider TLS session caching for DoH (and/or DoT)2022-12-14T18:35:36ZArtem BoldarievConsider TLS session caching for DoH (and/or DoT)### Description
Establishing a TLS connection might be costly and involves some data exchanges that might exceed the actual DNS query size for simple queries. Haven't looked into it much, but WEB servers could do that, so should BIND.
...### Description
Establishing a TLS connection might be costly and involves some data exchanges that might exceed the actual DNS query size for simple queries. Haven't looked into it much, but WEB servers could do that, so should BIND.
This feature is worth at least researching because I would expect DoH clients (mostly browsers) to return shortly after making a query, so this could improve performance.Not plannedArtem BoldarievArtem Boldarievhttps://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/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/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/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/2558CID 329158: Waiting while holding a lock in lib/ns/interfacemgr.c2021-09-02T08:54:15ZMichal NowakCID 329158: Waiting while holding a lock in lib/ns/interfacemgr.cCoverity Scan [identified](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=40401352&defectInstanceId=11469125&mergedDefectId=329158) a problem on `main` after isc-projects/bind9!4672 was merged:
```
*** CID 329158: P...Coverity Scan [identified](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=40401352&defectInstanceId=11469125&mergedDefectId=329158) a problem on `main` after isc-projects/bind9!4672 was merged:
```
*** CID 329158: Program hangs (SLEEP)
/lib/ns/interfacemgr.c: 777 in purge_old_interfaces()
771 char sabuf[256];
772 ISC_LIST_UNLINK(ifp->mgr->interfaces, ifp, link);
773 isc_sockaddr_format(&ifp->addr, sabuf, sizeof(sabuf));
774 isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_INFO,
775 "no longer listening on %s", sabuf);
776 ns_interface_shutdown(ifp);
>>> CID 329158: Program hangs (SLEEP)
>>> Call to "ns_interface_detach" might sleep while holding lock "mgr->lock".
777 ns_interface_detach(&ifp);
778 }
779 }
780 UNLOCK(&mgr->lock);
781 }
782
```
/cc @each @artemSeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2605dangling HTTPS socket when ALPN negotiation fails2021-09-02T12:43:39ZOndřej Surýdangling HTTPS socket when ALPN negotiation fails```
(main $%=)$ bin/dig/dig +https
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10....```
(main $%=)$ bin/dig/dig +https
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2611doth system test fails due to SSL error in BIO: 5 unexpected error2021-04-09T08:38:34ZMatthijs Mekkingmatthijs@isc.orgdoth system test fails due to SSL error in BIO: 5 unexpected errorFor example here:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1614684
```
I:doth:checking DoH query (POST) (6)
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected e...For example here:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1614684
```
I:doth:checking DoH query (POST) (6)
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
I:doth:failed
```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/2632doh_test keeps failing in doh_half_recv_send_GET_TLS on FreeBSD 13.02021-05-11T08:57:09ZMichal Nowakdoh_test keeps failing in doh_half_recv_send_GET_TLS on FreeBSD 13.0The `doh_test` always fails in the `doh_half_recv_send_GET_TLS` test on FreeBSD 13.0, preventing us from adding FreeBSD 13.0.
```
[==========] Running 32 test(s).
[ RUN ] mock_doh_uv_tcp_bind
[ OK ] mock_doh_uv_tcp_bind
[ RUN ...The `doh_test` always fails in the `doh_half_recv_send_GET_TLS` test on FreeBSD 13.0, preventing us from adding FreeBSD 13.0.
```
[==========] Running 32 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
[ OK ] doh_noresponse_POST
[ RUN ] doh_noresponse_GET
[ OK ] doh_noresponse_GET
[ RUN ] doh_recv_one_POST
[ OK ] doh_recv_one_POST
[ RUN ] doh_recv_one_GET
[ OK ] doh_recv_one_GET
[ RUN ] doh_recv_one_POST_TLS
[ OK ] doh_recv_one_POST_TLS
[ RUN ] doh_recv_one_GET_TLS
[ OK ] doh_recv_one_GET_TLS
[ RUN ] doh_recv_two_POST
[ OK ] doh_recv_two_POST
[ RUN ] doh_recv_two_GET
[ OK ] doh_recv_two_GET
[ RUN ] doh_recv_two_POST_TLS
[ OK ] doh_recv_two_POST_TLS
[ RUN ] doh_recv_two_GET_TLS
[ OK ] doh_recv_two_GET_TLS
[ RUN ] doh_recv_send_GET
[ OK ] doh_recv_send_GET
[ RUN ] doh_recv_send_POST
[ OK ] doh_recv_send_POST
[ RUN ] doh_recv_send_GET_TLS
[ OK ] doh_recv_send_GET_TLS
[ RUN ] doh_recv_send_POST_TLS
[ OK ] doh_recv_send_POST_TLS
[ RUN ] doh_recv_half_send_GET
[ OK ] doh_recv_half_send_GET
[ RUN ] doh_recv_half_send_POST
[ OK ] doh_recv_half_send_POST
[ RUN ] doh_recv_half_send_GET_TLS
[ OK ] doh_recv_half_send_GET_TLS
[ RUN ] doh_recv_half_send_POST_TLS
[ OK ] doh_recv_half_send_POST_TLS
[ RUN ] doh_half_recv_send_GET
[ OK ] doh_half_recv_send_GET
[ RUN ] doh_half_recv_send_POST
[ OK ] doh_half_recv_send_POST
[ RUN ] doh_half_recv_send_GET_TLS
netmgr/netmgr.c:497: INSIST(references == 1) failed, back trace
0x8002d4007 <isc_assertion_setcallback+0x57> at /usr/home/newman/bind9/lib/isc/.libs/libisc-9.17.11.so
0x8002d3faa <isc_assertion_failed+0xa> at /usr/home/newman/bind9/lib/isc/.libs/libisc-9.17.11.so
0x8002adf17 <isc_nm_destroy+0xc7> at /usr/home/newman/bind9/lib/isc/.libs/libisc-9.17.11.so
0x20ce59 <nm_teardown+0x19> at /usr/home/newman/bind9/lib/isc/tests/.libs/doh_test
0x800262613 <_run_group_tests+0x7c3> at /usr/local/lib/libcmocka.so.0
0x80026054f <_cmocka_run_group_tests+0x73f> at /usr/local/lib/libcmocka.so.0
I:doh_test:Core dump found: ./core.74014
D:doh_test:backtrace from ./core.74014 start
[New LWP 101440]
[New LWP 109163]
[New LWP 109164]
[New LWP 109165]
[New LWP 109166]
Core was generated by `/usr/home/newman/bind9/lib/isc/tests/.libs/doh_test'.
Program terminated with signal SIGABRT, Aborted.
#0 0x0000000800a242ea in thr_kill () from /lib/libc.so.7
[Current thread is 1 (LWP 101440)]
Thread 5 (LWP 109166 "isc-net-0003"):
#0 0x00000008002e19b6 in delete_trace_entry (mctx=mctx@entry=0x8010d1000, ptr=0x82d5d36c8, size=<optimized out>, size@entry=264, file=0x80028be6f "netmgr/netmgr.c", line=998) at mem.c:311
idx = <optimized out>
hash = <optimized out>
dl = <optimized out>
#1 0x00000008002e1857 in isc__mem_free (ctx=0x8010d1000, ptr=0x0, file=0x801052000 "\360B\262\020\b", file@entry=0x80028be6f "netmgr/netmgr.c", line=3540050681, line@entry=998) at mem.c:1009
call_water = false
size = 264
si = 0x82d5d36c0
#2 0x00000008002b3225 in nmsocket_cleanup (sock=sock@entry=0x82ce3f000, dofree=true) at netmgr/netmgr.c:998
uvreq = <optimized out>
handle = <optimized out>
#3 0x00000008002b0018 in nmsocket_maybe_destroy (sock=sock@entry=0x82ce3f000) at netmgr/netmgr.c:1069
destroy = <optimized out>
active_handles = 0
#4 0x00000008002afead in isc___nmsocket_prep_destroy (sock=0x82ce3f000) at netmgr/netmgr.c:1131
No locals.
#5 0x00000008002ae1ad in isc___nmsocket_detach (sockp=<optimized out>) at netmgr/netmgr.c:1158
sock = <optimized out>
rsock = 0x7b984e362165e5ec
#6 0x00000008002af166 in isc__nm_put_netievent_httpclose (nm=0x801024200, ievent=ievent@entry=0x806846080) at netmgr/netmgr.c:824
No locals.
#7 0x00000008002afccc in process_netievent (worker=worker@entry=0x801c55b10, ievent=0x806846080) at netmgr/netmgr.c:740
No locals.
#8 0x00000008002b2db8 in process_queue (worker=worker@entry=0x801c55b10, queue=0x806a6b180) at netmgr/netmgr.c:766
ievent = 0x70
#9 0x00000008002b2de0 in process_normal_queue (worker=0x7b984e362165e5ec, worker@entry=0x801c55b10) at netmgr/netmgr.c:652
No locals.
#10 0x00000008002b2d7a in process_queues (worker=0x801c55b10) at netmgr/netmgr.c:660
No locals.
#11 0x00000008002ad000 in async_cb (handle=<optimized out>) at netmgr/netmgr.c:618
worker = 0x7b984e362165e5ec
#12 0x00000008004df1da in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#13 0x00000008004f044b in uv.io_poll () from /usr/local/lib/libuv.so.1
No symbol table info available.
#14 0x00000008004df751 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#15 0x00000008002ad07b in nm_thread (worker0=0x801c55b10) at netmgr/netmgr.c:558
r = <optimized out>
worker = 0x801c55b10
mgr = 0x801024200
#16 0x00000008002f35c5 in isc__trampoline_run (arg=0x80275afa0) at trampoline.c:184
trampoline = 0x80275afa0
result = <optimized out>
#17 0x00000008008cd82b in ?? () from /lib/libthr.so.3
No symbol table info available.
#18 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdf9fb000
Thread 4 (LWP 109165 "isc-net-0002"):
#0 0x00000008008cab3a in ?? () from /lib/libthr.so.3
No symbol table info available.
#1 0x00000008008da2f0 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2 0x00000008008d2eec in ?? () from /lib/libthr.so.3
No symbol table info available.
#3 0x00000008008d1cf9 in pthread_mutex_lock () from /lib/libthr.so.3
No symbol table info available.
#4 0x00000008002e192d in delete_trace_entry (mctx=mctx@entry=0x8010d1000, ptr=0x11, ptr@entry=0x868a1e800, size=1976, file=0x80028be6f "netmgr/netmgr.c", line=992) at mem.c:287
idx = <optimized out>
hash = <optimized out>
dl = <optimized out>
#5 0x00000008002e35a5 in isc__mempool_put (mpctx=0x801024000, mem=0x868a1e800, file=0x0, file@entry=0x80028be6f "netmgr/netmgr.c", line=0, line@entry=992) at mem.c:1405
item = 0x0
mctx = 0x8010d1000
freecount = 4096
freemax = 4096
#6 0x00000008002b31d9 in nmsocket_cleanup (sock=sock@entry=0x817085000, dofree=true) at netmgr/netmgr.c:992
uvreq = 0x1c6
handle = <optimized out>
#7 0x00000008002b0018 in nmsocket_maybe_destroy (sock=sock@entry=0x817085000) at netmgr/netmgr.c:1069
destroy = <optimized out>
active_handles = 0
#8 0x00000008002afead in isc___nmsocket_prep_destroy (sock=0x817085000) at netmgr/netmgr.c:1131
No locals.
#9 0x00000008002ae1ad in isc___nmsocket_detach (sockp=<optimized out>) at netmgr/netmgr.c:1158
sock = <optimized out>
rsock = 0x801600108
#10 0x00000008002af166 in isc__nm_put_netievent_httpclose (nm=0x801024200, ievent=ievent@entry=0x805e87c80) at netmgr/netmgr.c:824
No locals.
#11 0x00000008002afccc in process_netievent (worker=worker@entry=0x801c55760, ievent=0x805e87c80) at netmgr/netmgr.c:740
No locals.
#12 0x00000008002b2db8 in process_queue (worker=worker@entry=0x801c55760, queue=0x806a6ae80) at netmgr/netmgr.c:766
ievent = 0x1c6
#13 0x00000008002b2de0 in process_normal_queue (worker=0x801600108, worker@entry=0x801c55760) at netmgr/netmgr.c:652
No locals.
#14 0x00000008002b2d7a in process_queues (worker=0x801c55760) at netmgr/netmgr.c:660
No locals.
#15 0x00000008002ad000 in async_cb (handle=<optimized out>) at netmgr/netmgr.c:618
worker = 0x801600108
#16 0x00000008004df1da in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#17 0x00000008004f044b in uv.io_poll () from /usr/local/lib/libuv.so.1
No symbol table info available.
#18 0x00000008004df751 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#19 0x00000008002ad07b in nm_thread (worker0=0x801c55760) at netmgr/netmgr.c:558
r = <optimized out>
worker = 0x801c55760
mgr = 0x801024200
#20 0x00000008002f35c5 in isc__trampoline_run (arg=0x80109d140) at trampoline.c:184
trampoline = 0x80109d140
result = <optimized out>
#21 0x00000008008cd82b in ?? () from /lib/libthr.so.3
No symbol table info available.
#22 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdfbfc000
Thread 3 (LWP 109164 "isc-net-0001"):
#0 0x00000008008cab3a in ?? () from /lib/libthr.so.3
No symbol table info available.
#1 0x00000008008da2f0 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2 0x00000008008d2eec in ?? () from /lib/libthr.so.3
No symbol table info available.
#3 0x00000008008d1cf9 in pthread_mutex_lock () from /lib/libthr.so.3
No symbol table info available.
#4 0x00000008002e192d in delete_trace_entry (mctx=mctx@entry=0x8010d1000, ptr=0x11, ptr@entry=0x8527f8100, size=size@entry=360, file=0x80028be6f "netmgr/netmgr.c", line=1460) at mem.c:287
idx = <optimized out>
hash = <optimized out>
dl = <optimized out>
#5 0x00000008002e2250 in isc__mem_put (ctx=0x8010d1000, ptr=ptr@entry=0x8527f8100, size=size@entry=360, file=0x0, line=0, line@entry=1460) at mem.c:781
call_water = false
si = <optimized out>
#6 0x00000008002b33a9 in nmhandle_free (sock=sock@entry=0x824f06800, handle=0x8527f8100) at netmgr/netmgr.c:1460
extra = <optimized out>
#7 0x00000008002b312b in nmsocket_cleanup (sock=sock@entry=0x824f06800, dofree=true) at netmgr/netmgr.c:976
uvreq = 0x0
handle = 0x1c6
#8 0x00000008002b0018 in nmsocket_maybe_destroy (sock=sock@entry=0x824f06800) at netmgr/netmgr.c:1069
destroy = <optimized out>
active_handles = 0
#9 0x00000008002afead in isc___nmsocket_prep_destroy (sock=0x824f06800) at netmgr/netmgr.c:1131
No locals.
#10 0x00000008002ae1ad in isc___nmsocket_detach (sockp=<optimized out>) at netmgr/netmgr.c:1158
sock = <optimized out>
rsock = 0x801600108
#11 0x00000008002af166 in isc__nm_put_netievent_httpclose (nm=0x801024200, ievent=ievent@entry=0x856235e80) at netmgr/netmgr.c:824
No locals.
#12 0x00000008002afccc in process_netievent (worker=worker@entry=0x801c553b0, ievent=0x856235e80) at netmgr/netmgr.c:740
No locals.
#13 0x00000008002b2db8 in process_queue (worker=worker@entry=0x801c553b0, queue=0x806a6ab80) at netmgr/netmgr.c:766
ievent = 0x1c6
#14 0x00000008002b2de0 in process_normal_queue (worker=0x801600108, worker@entry=0x801c553b0) at netmgr/netmgr.c:652
No locals.
#15 0x00000008002b2d7a in process_queues (worker=0x801c553b0) at netmgr/netmgr.c:660
No locals.
#16 0x00000008002ad000 in async_cb (handle=<optimized out>) at netmgr/netmgr.c:618
worker = 0x801600108
#17 0x00000008004df1da in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#18 0x00000008004f044b in uv.io_poll () from /usr/local/lib/libuv.so.1
No symbol table info available.
#19 0x00000008004df751 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#20 0x00000008002ad07b in nm_thread (worker0=0x801c553b0) at netmgr/netmgr.c:558
r = <optimized out>
worker = 0x801c553b0
mgr = 0x801024200
#21 0x00000008002f35c5 in isc__trampoline_run (arg=0x80109db60) at trampoline.c:184
trampoline = 0x80109db60
result = <optimized out>
#22 0x00000008008cd82b in ?? () from /lib/libthr.so.3
No symbol table info available.
#23 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdfdfd000
Thread 2 (LWP 109163 "isc-net-0000"):
#0 0x00000008008cab3a in ?? () from /lib/libthr.so.3
No symbol table info available.
#1 0x00000008008da2f0 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2 0x00000008008d2eec in ?? () from /lib/libthr.so.3
No symbol table info available.
#3 0x00000008008d1cf9 in pthread_mutex_lock () from /lib/libthr.so.3
No symbol table info available.
#4 0x00000008002e192d in delete_trace_entry (mctx=mctx@entry=0x8010d1000, ptr=0x11, ptr@entry=0x862626d00, size=size@entry=360, file=0x80028be6f "netmgr/netmgr.c", line=1460) at mem.c:287
idx = <optimized out>
hash = <optimized out>
dl = <optimized out>
#5 0x00000008002e2250 in isc__mem_put (ctx=0x8010d1000, ptr=ptr@entry=0x862626d00, size=size@entry=360, file=0x0, line=0, line@entry=1460) at mem.c:781
call_water = false
si = <optimized out>
#6 0x00000008002b33a9 in nmhandle_free (sock=sock@entry=0x837431800, handle=0x862626d00) at netmgr/netmgr.c:1460
extra = <optimized out>
#7 0x00000008002b312b in nmsocket_cleanup (sock=sock@entry=0x837431800, dofree=true) at netmgr/netmgr.c:976
uvreq = 0x0
handle = 0x1c6
#8 0x00000008002b0018 in nmsocket_maybe_destroy (sock=sock@entry=0x837431800) at netmgr/netmgr.c:1069
destroy = <optimized out>
active_handles = 0
#9 0x00000008002afead in isc___nmsocket_prep_destroy (sock=0x837431800) at netmgr/netmgr.c:1131
No locals.
#10 0x00000008002ae1ad in isc___nmsocket_detach (sockp=<optimized out>) at netmgr/netmgr.c:1158
sock = <optimized out>
rsock = 0x801600108
#11 0x00000008002af166 in isc__nm_put_netievent_httpclose (nm=0x801024200, ievent=ievent@entry=0x84fb10980) at netmgr/netmgr.c:824
No locals.
#12 0x00000008002afccc in process_netievent (worker=worker@entry=0x801c55000, ievent=0x84fb10980) at netmgr/netmgr.c:740
No locals.
#13 0x00000008002b2db8 in process_queue (worker=worker@entry=0x801c55000, queue=0x806a6a880) at netmgr/netmgr.c:766
ievent = 0x1c6
#14 0x00000008002b2de0 in process_normal_queue (worker=0x801600108, worker@entry=0x801c55000) at netmgr/netmgr.c:652
No locals.
#15 0x00000008002b2d7a in process_queues (worker=0x801c55000) at netmgr/netmgr.c:660
No locals.
#16 0x00000008002ad000 in async_cb (handle=<optimized out>) at netmgr/netmgr.c:618
worker = 0x801600108
#17 0x00000008004df1da in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#18 0x00000008004f044b in uv.io_poll () from /usr/local/lib/libuv.so.1
No symbol table info available.
#19 0x00000008004df751 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#20 0x00000008002ad07b in nm_thread (worker0=0x801c55000) at netmgr/netmgr.c:558
r = <optimized out>
worker = 0x801c55000
mgr = 0x801024200
#21 0x00000008002f35c5 in isc__trampoline_run (arg=0x80275abc0) at trampoline.c:184
trampoline = 0x80275abc0
result = <optimized out>
#22 0x00000008008cd82b in ?? () from /lib/libthr.so.3
No symbol table info available.
#23 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
Thread 1 (LWP 101440):
#0 0x0000000800a242ea in thr_kill () from /lib/libc.so.7
No symbol table info available.
#1 0x0000000800999064 in raise () from /lib/libc.so.7
No symbol table info available.
#2 0x0000000800a4df29 in abort () from /lib/libc.so.7
No symbol table info available.
#3 0x00000008002d3faf in isc_assertion_failed (file=<optimized out>, line=line@entry=497, type=type@entry=isc_assertiontype_insist, cond=<optimized out>) at assertions.c:47
No locals.
#4 0x00000008002adf17 in isc_nm_destroy (mgr0=mgr0@entry=0x801a39128) at netmgr/netmgr.c:497
counter = <optimized out>
mgr = 0x801024200
references = 0
#5 0x000000000020ce59 in nm_teardown (state=<optimized out>) at doh_test.c:329
i = <optimized out>
nm = 0x801a39120
#6 0x0000000800262613 in ?? () from /usr/local/lib/libcmocka.so.0
No symbol table info available.
#7 0x000000080026054f in _cmocka_run_group_tests () from /usr/local/lib/libcmocka.so.0
No symbol table info available.
#8 0x000000000020cbe3 in main () at doh_test.c:1704
tests_short = {{name = 0x2047c6 "mock_doh_uv_tcp_bind", test_func = 0x20cbf0 <mock_doh_uv_tcp_bind>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2050e8 "doh_parse_GET_query_string", test_func = 0x20cee0 <doh_parse_GET_query_string>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x2048c2 "doh_base64url_to_base64", test_func = 0x20dc30 <doh_base64url_to_base64>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x2044b0 "doh_base64_to_base64url", test_func = 0x20e440 <doh_base64_to_base64url>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x205773 "doh_noop_POST", test_func = 0x20ec70 <doh_noop_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2047db "doh_noop_GET", test_func = 0x20ec90 <doh_noop_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2044c8 "doh_noresponse_POST", test_func = 0x20ecb0 <doh_noresponse_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2051ca "doh_noresponse_GET", test_func = 0x20ecd0 <doh_noresponse_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}}
tests_long = {{name = 0x2047c6 "mock_doh_uv_tcp_bind", test_func = 0x20cbf0 <mock_doh_uv_tcp_bind>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2050e8 "doh_parse_GET_query_string", test_func = 0x20cee0 <doh_parse_GET_query_string>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x2048c2 "doh_base64url_to_base64", test_func = 0x20dc30 <doh_base64url_to_base64>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x2044b0 "doh_base64_to_base64url", test_func = 0x20e440 <doh_base64_to_base64url>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x205773 "doh_noop_POST", test_func = 0x20ec70 <doh_noop_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2047db "doh_noop_GET", test_func = 0x20ec90 <doh_noop_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2044c8 "doh_noresponse_POST", test_func = 0x20ecb0 <doh_noresponse_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2051ca "doh_noresponse_GET", test_func = 0x20ecd0 <doh_noresponse_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x205103 "doh_recv_one_POST", test_func = 0x20ecf0 <doh_recv_one_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2043c2 "doh_recv_one_GET", test_func = 0x20ed10 <doh_recv_one_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x20463d "doh_recv_one_POST_TLS", test_func = 0x20ed30 <doh_recv_one_POST_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x20545f "doh_recv_one_GET_TLS", test_func = 0x20ed50 <doh_recv_one_GET_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2048da "doh_recv_two_POST", test_func = 0x20ed70 <doh_recv_two_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x20467f "doh_recv_two_GET", test_func = 0x20ed90 <doh_recv_two_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x205474 "doh_recv_two_POST_TLS", test_func = 0x20edb0 <doh_recv_two_POST_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x204d63 "doh_recv_two_GET_TLS", test_func = 0x20edd0 <doh_recv_two_GET_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x20424b "doh_recv_send_GET", test_func = 0x20edf0 <doh_recv_send_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x204d78 "doh_recv_send_POST", test_func = 0x20ee10 <doh_recv_send_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x20531f "doh_recv_send_GET_TLS", test_func = 0x20ee30 <doh_recv_send_GET_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x205115 "doh_recv_send_POST_TLS", test_func = 0x20ee50 <doh_recv_send_POST_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x204aa6 "doh_recv_half_send_GET", test_func = 0x20ee70 <doh_recv_half_send_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2055fd "doh_recv_half_send_POST", test_func = 0x20ee90 <doh_recv_half_send_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x20548a "doh_recv_half_send_GET_TLS", test_func = 0x20eeb0 <doh_recv_half_send_GET_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2051dd "doh_recv_half_send_POST_TLS", test_func = 0x20eed0 <doh_recv_half_send_POST_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x204abd "doh_half_recv_send_GET", test_func = 0x20eef0 <doh_half_recv_send_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x204690 "doh_half_recv_send_POST", test_func = 0x20ef10 <doh_half_recv_send_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2042ea "doh_half_recv_send_GET_TLS", test_func = 0x20ef30 <doh_half_recv_send_GET_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x204f07 "doh_half_recv_send_POST_TLS", test_func = 0x20ef50 <doh_half_recv_send_POST_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x204148 "doh_half_recv_half_send_GET", test_func = 0x20ef70 <doh_half_recv_half_send_GET>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x205512 "doh_half_recv_half_send_POST", test_func = 0x20ef90 <doh_half_recv_half_send_POST>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2054a5 "doh_half_recv_half_send_GET_TLS", test_func = 0x20efb0 <doh_half_recv_half_send_GET_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}, {name = 0x2053d3 "doh_half_recv_half_send_POST_TLS", test_func = 0x20efd0 <doh_half_recv_half_send_POST_TLS>, setup_func = 0x20cc80 <nm_setup>, teardown_func = 0x20ce40 <nm_teardown>, initial_state = 0x0}}
result = 0
D:doh_test:backtrace from ./core.74014 end
FAIL doh_test (exit status: 134)
```
Core file (1.8 G uncompressed): [core.74014.gz](/uploads/dad9a1a3ec0a480b454dece13a663045/core.74014.gz)May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2723TLS key logging2021-12-22T20:08:49ZPetr Špačekpspacek@isc.orgTLS key logging### Description
Use-case: DoT/DoH debugging
Debugging encrypted transports is very hard because we do not see in the traffic, so plain PCAPs are useless.
### Request
Introduce a new logging channel for TLS keys, which would produce st...### Description
Use-case: DoT/DoH debugging
Debugging encrypted transports is very hard because we do not see in the traffic, so plain PCAPs are useless.
### Request
Introduce a new logging channel for TLS keys, which would produce stream of TLS pre-master secrets which can be used with Wireshark to decrypt TLS traffic. (Volume of the logged data can be significant so it's important to have some size limits on the file size - that's why I'm proposing to reuse logging machinery we have already.)
Open question is if it should somehow take into account `SSLKEYLOGFILE` environment variable as it is customary in [GnuTLS](https://gnutls.org/manual/html_node/Debugging-and-auditing.html) and [NSS](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). The reason is that environment variable will be easier to use when debugging something in an automated test systems (as opposed to modifying named.conf). Maybe `SSLKEYLOGFILE` environment variable could, if present, just generate in-memory logging config snippet?
### Links / references
- https://wiki.wireshark.org/TLS#Using_the_.28Pre.29-Master-Secret
- https://www.openssl.org/docs/man1.1.0/man3/SSL_SESSION_print_keylog.htmlJanuary 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/2795We should have ability to specify supported TLS protocol versions2022-01-19T11:20:48ZArtem BoldarievWe should have ability to specify supported TLS protocol versionsCurrently, it is not possible to specify supported TLS protocols versions. In some environments it might be required or, at least, useful. In particular, only TLSv1.3 and higher should be used for XoT.
We could model the behaviour for c...Currently, it is not possible to specify supported TLS protocols versions. In some environments it might be required or, at least, useful. In particular, only TLSv1.3 and higher should be used for XoT.
We could model the behaviour for configuring this from e.g NGINX. It has [`ssl_protocols`](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols) option where multiple TLS protocol versions could be specified. It could look like this:
```
tls some-tls {
...
protocols {TLSv1.2, TLSv1.3};
...
};
```
It is going to be useful for both DoH and DoT.
*The issue is a half of #2775.*October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2796Add more configuration options to control TLS context (enough to implement Pe...2022-01-21T13:28:21ZArtem BoldarievAdd more configuration options to control TLS context (enough to implement Perfect Forward Secrecy)It would be nice for us to borrow more configuration options from NGINX, which is an industry standard. As far as I can tell, borrowing the following options will make it possible to implement [Perfect Forward Secrecy](https://en.wikiped...It would be nice for us to borrow more configuration options from NGINX, which is an industry standard. As far as I can tell, borrowing the following options will make it possible to implement [Perfect Forward Secrecy](https://en.wikipedia.org/wiki/Forward_secrecy) in BIND:
* An ability to specify supported ciphers: [ssl_ciphers](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers);
* An ability to specify Diffie-Hellman parameters for DHE ciphers: [ssl_dhparam](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_dhparam);
* An ability to inform client that server ciphers should be preferred: [ssl_prefer_server_ciphers](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_prefer_server_ciphers);
* An ability to enable/disable TLS session tickets: [ssl_session_tickets](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets)).
Implementing this is hugely beneficial for both DoH and DoT.
The end result could look like this:
```
tls some-tls {
...
ciphers "HIGH:!aNULL:!MD5";
dhparam-file "/path/to/dh3072.pem"; // theoretically, we could compile in a default value for it. this needs more research.
prefer-server-ciphers yes;
session-tickets no;
...
};
```
*Loosely related to #2775*October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2809Make quota configurable for DoH2021-08-09T11:48:30ZArtem BoldarievMake quota configurable for DoHCurrently, DoH shares the quota with TCP, which makes
little sense anyway (see `tcp-clients` option), because of the nature of
interaction of DoH clients: they tend to keep idle opened connections
for longer periods of time, preventing t...Currently, DoH shares the quota with TCP, which makes
little sense anyway (see `tcp-clients` option), because of the nature of
interaction of DoH clients: they tend to keep idle opened connections
for longer periods of time, preventing the TCP and TLS client from
being served.
Because of these differences, it makes sense for DoH to have a separate quota facility. Also, it makes sense to make the number of streams per connection configurable as well, as these are treated as virtual connections by the code.
*See !5036 for additional details.*August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2840netmgr/netmgr.c:2064: fatal error: RUNTIME_CHECK(r == 0) failed in dig on Ope...2022-02-11T14:07:38ZMichal Nowaknetmgr/netmgr.c:2064: fatal error: RUNTIME_CHECK(r == 0) failed in dig on OpenBSDJob [#1895046](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1895046) failed for f563cd570c8a4e24e0c6a1cf7cf6e11da1b090fb:
```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (71)
netmgr/netmgr.c:2064: fatal erro...Job [#1895046](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1895046) failed for f563cd570c8a4e24e0c6a1cf7cf6e11da1b090fb:
```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (71)
netmgr/netmgr.c:2064: fatal error: RUNTIME_CHECK(r == 0) failed
Abort trap (core dumped)
I:doth:exit status: 0
I:doth:stopping servers
I:doth:Core dump(s) found: doth/dig.core
D:doth:backtrace from doth/dig.core:
D:doth:--------------------------------------------------------------------------------
D:doth:Core was generated by `dig'.
D:doth:Program terminated with signal SIGABRT, Aborted.
D:doth:#0 thrkill () at /tmp/-:3
D:doth:[Current thread is 1 (process 164094)]
D:doth:#0 thrkill () at /tmp/-:3
D:doth:#1 0x00000ee3b008379e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
D:doth:#2 0x00000ee413f78d30 in isc_error_fatal (file=<optimized out>, line=<optimized out>, format=<optimized out>) at error.c:68
D:doth:#3 0x00000ee413f78d45 in isc_error_runtimecheck (file=0x0, line=6, expression=0xee3b00699ba <thrkill+10> "r\001\303d\211\004% ") at error.c:73
D:doth:#4 0x00000ee413f62522 in isc__nmsocket_timer_restart (sock=<optimized out>) at netmgr/netmgr.c:2064
D:doth:#5 0x00000ee1aa1a9e8b in launch_next_query (query=0xee3b89c1820) at dighost.c:3143
D:doth:#6 0x00000ee1aa1aa339 in tcp_connected (handle=0xee44e611420, eresult=0, arg=<optimized out>) at dighost.c:3280
D:doth:#7 0x00000ee413f63a16 in isc__nm_async_connectcb (worker=<optimized out>, ev0=<optimized out>) at netmgr/netmgr.c:2662
D:doth:#8 0x00000ee413f5fe30 in process_netievent (worker=0xee3b89c1020, ievent=0xee44e611020) at netmgr/netmgr.c:958
D:doth:#9 0x00000ee413f5ae64 in process_queue (worker=0xee3b89c1020, type=<error reading variable: Cannot access memory at address 0x3>) at netmgr/netmgr.c:998
D:doth:#10 process_all_queues (worker=0xee3b89c1020) at netmgr/netmgr.c:746
D:doth:#11 async_cb (handle=0xee3b89c12f8) at netmgr/netmgr.c:775
D:doth:#12 0x00000ee3bb4b39cd in uv.async_io () from /usr/local/lib/libuv.so.3.0
D:doth:#13 0x00000ee3bb4c5a19 in uv.io_poll () from /usr/local/lib/libuv.so.3.0
D:doth:#14 0x00000ee3bb4b40b8 in uv_run () from /usr/local/lib/libuv.so.3.0
D:doth:#15 0x00000ee413f5af4b in nm_thread (worker0=0xee3b89c1020) at netmgr/netmgr.c:681
D:doth:#16 0x00000ee413fac063 in isc__trampoline_run (arg=0xee3b89ae3c0) at trampoline.c:180
D:doth:#17 0x00000ee43eef0f51 in _rthread_start (v=<optimized out>) at /usr/src/lib/librthread/rthread.c:96
D:doth:#18 0x00000ee3b002dd1a in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
D:doth:--------------------------------------------------------------------------------
D:doth:full backtrace from doth/dig.core saved in doth/dig.core-backtrace.txt
D:doth:core dump doth/dig.core archived as doth/dig.core.gz
R:doth:FAIL
E:doth:2021-07-28T07:20:21+0000
```
#2809 might be triggering this, but I was unable to reproduce this locally (0 out of 6 attempts).
[dig.core.gz](/uploads/47a706783f8bda7af03498fe9d01a5d2/dig.core.gz)
[dig.core-backtrace.txt](/uploads/2e9bf04594dec8804aa790a3245f72f8/dig.core-backtrace.txt)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2851A rare crash in the DoH code caused by an assert2021-08-17T09:01:28ZArtem BoldarievA rare crash in the DoH code caused by an assertA rare issue was found while working on !5309. The unit test suite (`doh_test`) revealed a situation when `session->handle` got detached too early in the `http_send_outgoing()`, the function which takes data from nghttp2 and sends it via...A rare issue was found while working on !5309. The unit test suite (`doh_test`) revealed a situation when `session->handle` got detached too early in the `http_send_outgoing()`, the function which takes data from nghttp2 and sends it via the underlying connection.
As a result, when we have reached the call to `isc_nm_send()`
```
session->sending++;
isc_nm_send(session->handle, &send->data, http_writecb, send);
return (true);
}
```
the `session->handle` was `NULL` triggering an assert:
```
void
isc_nm_send(isc_nmhandle_t *handle, isc_region_t *region, isc_nm_cb_t cb,
void *cbarg) {
REQUIRE(VALID_NMHANDLE(handle));
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2854DoH: Assign HTTP responses freshness lifetime according to the smallest TTL ...2021-12-01T07:30:45ZArtem BoldarievDoH: Assign HTTP responses freshness lifetime according to the smallest TTL found in the Answer section (by setting "max-age" in "Cache-Control" header)In the DoH spec there is a section on HTTP cache interaction.
https://datatracker.ietf.org/doc/html/rfc8484#section-5.1
We are now trying to bypass the caches. However, in the long run it might be beneficial to take advantage of it by ...In the DoH spec there is a section on HTTP cache interaction.
https://datatracker.ietf.org/doc/html/rfc8484#section-5.1
We are now trying to bypass the caches. However, in the long run it might be beneficial to take advantage of it by setting `max-age` to the least TTL from the answer section. In some cases, this can help us to take advantage of the existing HTTP caching infrastructure and lessen load on the DNS server itself by reusing the HTTP infrastructure caching capabilities.
Adding such a code to `http.c` is easy, however, we seem to currently lack a mechanism to track the minimal TTL value in `dns_message`. If we were adding one, we could put it into `dns_message`, updating the lowest TTL whenever a new rdataset was added to a message.
For the reference, at least Knot Resolver does it, as do Cloudflare and Quad9. So should we.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2858dig aborts for DoH with IPv62021-08-31T13:35:49ZMichal Nowakdig aborts for DoH with IPv6`dig -6 google.cz A +https -p444` crashes for me. `dig -4`, just `dig` without `-6`, or when `+https` is not present sends the query just fine. This is BIND 9.17.16 from ISC Copr repo on Fedora 34:
```
[root@mnowak ~]# dig -6 google.cz A...`dig -6 google.cz A +https -p444` crashes for me. `dig -4`, just `dig` without `-6`, or when `+https` is not present sends the query just fine. This is BIND 9.17.16 from ISC Copr repo on Fedora 34:
```
[root@mnowak ~]# dig -6 google.cz A +https -p444
;; Connection to ::1#444(::1) for google.cz failed: failure.
10-Aug-2021 14:46:59.568 SSL error in BIO: 5 unexpected error (errno: 115). Arguments: received_data: (nil), send_data: (nil), finish: false
netmgr/netmgr.c:2499: REQUIRE((uint_fast32_t) __extension__ ({ __auto_type __atomic_load_ptr = ((&handle->references)); __typeof__ ((void)0, *__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (memory_order_acquire)); __atomic_load_tmp; }) >= 2) failed, back trace
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(+0x3af33)[0x7f3e6b1e8f33]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(isc_assertion_failed+0x10)[0x7f3e6b1e8630]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(isc_nm_read+0xea)[0x7f3e6b1d71da]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(+0x27d1b)[0x7f3e6b1d5d1b]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(+0x2e7d2)[0x7f3e6b1dc7d2]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(+0x2ed35)[0x7f3e6b1dcd35]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(+0x2f537)[0x7f3e6b1dd537]
/opt/isc/isc-bind/root/usr/lib64/libuv.so.1(+0xd91d)[0x7f3e6ad3191d]
/opt/isc/isc-bind/root/usr/lib64/libuv.so.1(+0x26ccd)[0x7f3e6ad4accd]
/opt/isc/isc-bind/root/usr/lib64/libuv.so.1(uv_run+0x114)[0x7f3e6ad3a8d4]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(+0x2edce)[0x7f3e6b1dcdce]
/opt/isc/isc-bind/root/usr/lib64/libisc-9.17.16.so(isc__trampoline_run+0x63)[0x7f3e6b226e33]
/lib64/libpthread.so.0(+0x9299)[0x7f3e6a7c3299]
/lib64/libc.so.6(clone+0x43)[0x7f3e6ae59353]
Aborted (core dumped)
```
```
Reading symbols from /opt/isc/isc-bind/root/usr/bin/dig...
Reading symbols from /usr/lib/debug/opt/isc/isc-bind/root/usr/bin/dig-9.17.16-1.1.fc34.x86_64.debug...
[New LWP 3586]
[New LWP 3585]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `dig -6 google.cz A +https -p444'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49 return ret;
[Current thread is 1 (Thread 0x7f8edff07640 (LWP 3586))]
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x00007f8ee0a628a4 in __GI_abort () at abort.c:79
#2 0x00007f8ee0ecb635 in isc_assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>)
at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/lib/isc/assertions.c:49
#3 0x00007f8ee0eba1da in isc_nm_read (handle=<optimized out>, cb=<optimized out>, cbarg=<optimized out>) at netmgr/netmgr.c:2499
#4 0x00007f8ee0eb8d1b in http_do_bio (session=0x7f8ed807b910, send_httphandle=0x0, send_cb=0x0, send_cbarg=0x0) at netmgr/http.c:1222
#5 0x00007f8ee0eb91be in http_close_direct (sock=<optimized out>) at netmgr/http.c:2557
#6 0x00007f8ee0ebf086 in isc__nm_async_httpclose (worker=<optimized out>, ev0=<optimized out>) at netmgr/http.c:2605
#7 0x00007f8ee0ebf7d2 in process_netievent (worker=worker@entry=0x557a6708a8c0, ievent=0x557a672d7890) at netmgr/netmgr.c:976
#8 0x00007f8ee0ebfd35 in process_queue (worker=worker@entry=0x557a6708a8c0, type=type@entry=NETIEVENT_NORMAL) at netmgr/netmgr.c:1018
#9 0x00007f8ee0ec0537 in process_all_queues (worker=0x557a6708a8c0) at netmgr/netmgr.c:768
#10 async_cb (handle=0x557a6708ac20) at netmgr/netmgr.c:797
#11 0x00007f8ee0a1491d in uv__async_io (loop=0x557a6708a8d0, w=<optimized out>, events=<optimized out>) at src/unix/async.c:163
#12 0x00007f8ee0a2dccd in uv__io_poll (loop=0x557a6708a8d0, timeout=<optimized out>) at src/unix/linux-core.c:462
#13 0x00007f8ee0a1d8d4 in uv_run (loop=loop@entry=0x557a6708a8d0, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:385
#14 0x00007f8ee0ebfdce in nm_thread (worker0=0x557a6708a8c0) at netmgr/netmgr.c:703
#15 0x00007f8ee0f09e33 in isc__trampoline_run (arg=0x557a672d0d60) at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/lib/isc/trampoline.c:184
#16 0x00007f8ee04a6299 in start_thread (arg=0x7f8edff07640) at pthread_create.c:481
#17 0x00007f8ee0b3c353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
`named.conf`:
<details>
```
options {
directory "/var/opt/isc/scls/isc-bind/named/data";
listen-on tls ephemeral http default { any; };
listen-on-v6 tls ephemeral http default { any; };
listen-on { any; };
listen-on-v6 { any; };
dnssec-validation auto;
allow-query { localhost; XXX.XXX.XXX.XXX; };
recursion yes;
querylog yes;
max-cache-size 50%;
https-port 444;
};
logging {
channel default_debug {
file "named.run";
print-time yes;
severity dynamic;
};
};
```
</details>
GDB `thread apply all bt full`:
<details>
```
[New LWP 3586]
[New LWP 3585]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `dig -6 google.cz A +https -p444'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49 return ret;
[Current thread is 1 (Thread 0x7f8edff07640 (LWP 3586))]
Thread 2 (Thread 0x7f8ee0049d00 (LWP 3585)):
#0 0x00007f8ee0a7a062 in __GI___sigtimedwait (set=set@entry=0x7ffc3c4fe610, info=info@entry=0x7ffc3c4fe540, timeout=timeout@entry=0x0) at ../sysdeps/unix/sysv/linux/sigtimedwait.c:54
result = <optimized out>
#1 0x00007f8ee0a796ec in __GI___sigwait (set=set@entry=0x7ffc3c4fe610, sig=sig@entry=0x7ffc3c4fe5fc) at ../sysdeps/unix/sysv/linux/sigwait.c:28
si = {si_signo = 1, si_errno = 0, si_code = 40, __pad0 = 0, _sifields = {_pad = {1728620736, 21882, -525151276, 32654, 1728607024, 21882, 8, 0, -526185176, 32654, 8, 0, 1728607024, 21882, -526284351, 32654, 1011869184, 32764, 1728607024, 21882, 1731006208, 21882, -1, 0, 1728607040, 21882, -521129860, 32654}, _kill = {si_pid = 1728620736, si_uid = 21882}, _timer = {si_tid = 1728620736, si_overrun = 21882, si_sigval = {sival_int = -525151276, sival_ptr = 0x7f8ee0b2d3d4 <__GI___libc_write+100>}}, _rt = {si_pid = 1728620736, si_uid = 21882, si_sigval = {sival_int = -525151276, sival_ptr = 0x7f8ee0b2d3d4 <__GI___libc_write+100>}}, _sigchld = {si_pid = 1728620736, si_uid = 21882, si_status = -525151276, si_utime = 93984202978096, si_stime = 8}, _sigfault = {si_addr = 0x557a6708a8c0, si_addr_lsb = -11308, _bounds = {_addr_bnd = {_lower = 0x557a67087330, _upper = 0x8}, _pkey = 1728607024}}, _sigpoll = {si_band = 93984202991808, si_fd = -525151276}, _sigsys = {_call_addr = 0x557a6708a8c0, _syscall = -525151276, _arch = 32654}}}
ret = <optimized out>
#2 0x00007f8ee0ed4453 in isc_app_ctxrun (ctx=ctx@entry=0x7f8ee0f35880 <isc_g_appctx>) at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/lib/isc/app.c:243
sset = {__val = {16387, 140251628437346, 0, 140251628437462, 93982474371105, 0, 141733920768, 16247941830063148800, 48, 93984205383696, 93984194315200, 24, 33, 93984202991360, 0, 140251628440041}}
sig = 0
strbuf = {<optimized out> <repeats 128 times>}
event = 0x0
next_event = <optimized out>
task = 0x0
#3 0x00007f8ee0ed471c in isc_app_run () at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/lib/isc/app.c:295
result = <optimized out>
#4 0x0000557a6682c25b in dig_startup () at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/bin/dig/dig.c:2907
result = <optimized out>
#5 main (argc=6, argv=0x7ffc3c4fe8c8) at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/bin/dig/dig.c:2934
No locals.
Thread 1 (Thread 0x7f8edff07640 (LWP 3586)):
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
set = {__val = {16387, 0 <repeats 15 times>}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007f8ee0a628a4 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x104c, sa_sigaction = 0x104c}, sa_mask = {__val = {0, 0, 140251486297584, 0 <repeats 11 times>, 16247941830063148800, 93984194281752}}, sa_flags = 0, sa_restorer = 0x7f8ed807b910}
sigs = {__val = {32, 0 <repeats 12 times>, 16247941830063148800, 0, 93984194281752}}
#2 0x00007f8ee0ecb635 in isc_assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/lib/isc/assertions.c:49
No locals.
#3 0x00007f8ee0eba1da in isc_nm_read (handle=<optimized out>, cb=<optimized out>, cbarg=<optimized out>) at netmgr/netmgr.c:2499
No locals.
#4 0x00007f8ee0eb8d1b in http_do_bio (session=0x7f8ed807b910, send_httphandle=0x0, send_cb=0x0, send_cbarg=0x0) at netmgr/http.c:1222
No locals.
#5 0x00007f8ee0eb91be in http_close_direct (sock=<optimized out>) at netmgr/http.c:2557
session = <optimized out>
#6 0x00007f8ee0ebf086 in isc__nm_async_httpclose (worker=<optimized out>, ev0=<optimized out>) at netmgr/http.c:2605
ievent = <optimized out>
sock = <optimized out>
#7 0x00007f8ee0ebf7d2 in process_netievent (worker=worker@entry=0x557a6708a8c0, ievent=0x557a672d7890) at netmgr/netmgr.c:976
No locals.
#8 0x00007f8ee0ebfd35 in process_queue (worker=worker@entry=0x557a6708a8c0, type=type@entry=NETIEVENT_NORMAL) at netmgr/netmgr.c:1018
stop = <optimized out>
waiting = 1
ievent = <optimized out>
#9 0x00007f8ee0ec0537 in process_all_queues (worker=0x557a6708a8c0) at netmgr/netmgr.c:768
result = <optimized out>
type = 3
reschedule = false
reschedule = <optimized out>
type = <optimized out>
result = <optimized out>
#10 async_cb (handle=0x557a6708ac20) at netmgr/netmgr.c:797
worker = 0x557a6708a8c0
#11 0x00007f8ee0a1491d in uv__async_io (loop=0x557a6708a8d0, w=<optimized out>, events=<optimized out>) at src/unix/async.c:163
buf = "\001\000\000\000\000\000\000\000\320A\006؎\177\000\000à\235\340\216\177\000\000\201 \231\340\216\177\000\000\220\037\005؎\177\000\000\236q\254\340\216\177\000\000\231\240\235\340\216\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\060\221\004؎\177\000\000\060\000\000\000\000\000\000\000\236q\254\340\216\177\000\000\003\000\000\000\216\177\000\000\000\000\000\000\000\000\000\000\001", '\000' <repeats 15 times>, "\060\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\003", '\000' <repeats 15 times>, "|\000\000\000w", '\000' <repeats 20 times>, "\317\037X\002I|\341p\031\005؎\177\000\000P@\006؎\177"...
r = <optimized out>
queue = {0x7f8edff036b0, 0x7f8edff036b0}
q = 0x557a6708ac88
h = 0x557a6708ac20
__PRETTY_FUNCTION__ = {<optimized out> <repeats 13 times>}
#12 0x00007f8ee0a2dccd in uv__io_poll (loop=0x557a6708a8d0, timeout=<optimized out>) at src/unix/linux-core.c:462
no_epoll_pwait = <optimized out>
no_epoll_wait = <optimized out>
events = {{events = 1, data = {ptr = 0x8, fd = 8, u32 = 8, u64 = 8}}, {events = 4, data = {ptr = 0xb, fd = 11, u32 = 11, u64 = 11}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}} <repeats 985 times>, {events = 0, data = {ptr = 0x7f8ed8052230, fd = -670752208, u32 = 3624215088, u64 = 140251486298672}}, {events = 3624288336, data = {ptr = 0xd805224800007f8e, fd = 32654, u32 = 32654, u64 = 15565885379709009806}}, {events = 32654, data = {ptr = 0x7f8ed8063b08, fd = -670680312, u32 = 3624286984, u64 = 140251486370568}}, {events = 1728620824, data = {ptr = 0x557a, fd = 21882, u32 = 21882, u64 = 21882}}, {events = 0, data = {ptr = 0x7f8ee0ecdf75 <isc_astack_trypush+85>, fd = -521347211, u32 = 3773620085, u64 = 140251635703669}}, {events = 3624288336, data = {ptr = 0xd805197000007f8e, fd = 32654, u32 = 32654, u64 = 15565875655903051662}}, {events = 32654, data = {ptr = 0x7f8ed8052110, fd = -670752496, u32 = 3624214800, u64 = 140251486298384}}, {events = 3773550568, data = {ptr = 0x7f8e, fd = 32654, u32 = 32654, u64 = 32654}}, {events = 0, data = {ptr = 0xe17c4902581fcf00, fd = 1478479616, u32 = 1478479616, u64 = 16247941830063148800}}, {events = 3624212848, data = {ptr = 0xe0eb22e400007f8e, fd = 32654, u32 = 32654, u64 = 16207086046670782350}}, {events = 32654, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 3773515905, data = {ptr = 0xd806389000007f8e, fd = 32654, u32 = 32654, u64 = 15566191353179176846}}, {events = 32654, data = {ptr = 0x7f8ee0ec284d <tcp_close_direct+173>, fd = -521394099, u32 = 3773573197, u64 = 140251635656781}}, {events = 0, data = {ptr = 0xe0a1d39500000000, fd = 0, u32 = 0, u64 = 16186451172649861120}}, {events = 32654, data = {ptr = 0x7f8ed8063890, fd = -670680944, u32 = 3624286352, u64 = 140251486369936}}, {events = 3773543561, data = {ptr = 0x7f8e, fd = 32654, u32 = 32654, u64 = 32654}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x581fcf0000000000, fd = 0, u32 = 0, u64 = 6350021598522638336}}, {events = 3783018754, data = {ptr = 0x7f8ed8051970, fd = -670754448, u32 = 3624212848, u64 = 140251486296432}}, {events = 3773547588, data = {ptr = 0x7f8e, fd = 32654, u32 = 32654, u64 = 32654}}, {events = 0, data = {ptr = 0xe17c4902581fcf00, fd = 1478479616, u32 = 1478479616, u64 = 16247941830063148800}}, {events = 3624212848, data = {ptr = 0xdff06b8000007f8e, fd = 32654, u32 = 32654, u64 = 16136515662368505742}}, {events = 32654, data = {ptr = 0x7f8ed8051f08, fd = -670753016, u32 = 3624214280, u64 = 140251486297864}}, {events = 3773548037, data = {ptr = 0x7f8e, fd = 32654, u32 = 32654, u64 = 32654}}, {events = 0, data = {ptr = 0x7f8ed8051970, fd = -670754448, u32 = 3624212848, u64 = 140251486296432}}, {events = 3624286352, data = {ptr = 0x7f8e, fd = 32654, u32 = 32654, u64 = 32654}}, {events = 0, data = {ptr = 0x7f8edff06b80, fd = -537891968, u32 = 3757075328, u64 = 140251619158912}}, {events = 1478479616, data = {ptr = 0xd8063b60e17c4902, fd = -511948542, u32 = 3783018754, u64 = 15566194449338616066}}, {events = 32654, data = {ptr = 0x7f8ee0a285c0 <uv__write_callbacks+240>, fd = -526219840, u32 = 3768747456, u64 = 140251630831040}}, {events = 3757075328, data = {ptr = 0xdff06b8000007f8e, fd = 32654, u32 = 32654, u64 = 16136515662368505742}}, {events = 32654, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 1478479616, data = {ptr = 0x4e17c4902, fd = -511948542, u32 = 3783018754, u64 = 20962887938}}, {events = 0, data = {ptr = 0x7f8ed8051f90, fd = -670752880, u32 = 3624214416, u64 = 140251486298000}}, {events = 4, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x7f8ed8051f08, fd = -670753016, u32 = 3624214280, u64 = 140251486297864}}, {events = 3768755471, data = {ptr = 0x7f8e, fd = 32654, u32 = 32654, u64 = 32654}}, {events = 0, data = {ptr = 0x6, fd = 6, u32 = 6, u64 = 6}}}
pe = 0x7f8edff03be0
e = {events = 4, data = {ptr = 0xb, fd = 11, u32 = 11, u64 = 11}}
real_timeout = <optimized out>
q = <optimized out>
w = 0x557a6708aa98
sigset = {__val = {0 <repeats 16 times>}}
sigmask = <optimized out>
base = <optimized out>
have_signals = 0
nevents = 0
count = <optimized out>
nfds = <optimized out>
fd = <optimized out>
op = <optimized out>
i = 0
user_timeout = <optimized out>
reset_timeout = <optimized out>
max_safe_timeout = <optimized out>
no_epoll_pwait_cached = <optimized out>
no_epoll_wait_cached = <optimized out>
__PRETTY_FUNCTION__ = {<optimized out> <repeats 12 times>}
#13 0x00007f8ee0a1d8d4 in uv_run (loop=loop@entry=0x557a6708a8d0, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:385
timeout = <optimized out>
r = <optimized out>
ran_pending = <optimized out>
#14 0x00007f8ee0ebfdce in nm_thread (worker0=0x557a6708a8c0) at netmgr/netmgr.c:703
r = <optimized out>
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
worker = 0x557a6708a8c0
mgr = 0x557a67089450
#15 0x00007f8ee0f09e33 in isc__trampoline_run (arg=0x557a672d0d60) at /usr/src/debug/isc-bind-bind-9.17.16-1.1.fc34.x86_64/lib/isc/trampoline.c:184
trampoline = 0x557a672d0d60
result = <optimized out>
#16 0x00007f8ee04a6299 in start_thread (arg=0x7f8edff07640) at pthread_create.c:481
ret = <optimized out>
pd = 0x7f8edff07640
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140251619161664, -1537989858356960344, 140721320354702, 140721320354703, 0, 140251619161664, 1565644907337147304, 1565624068595180456}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
#17 0x00007f8ee0b3c353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
```
</details>
*See also: #2860*September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2860The DoH endpoint URL in dig might get prepared in wrong format2021-08-31T13:41:21ZArtem BoldarievThe DoH endpoint URL in dig might get prepared in wrong formatOne of the causes why the problem #2858 appeared is that the URL in the DoH code might get generated in wrong format at least when IPv6 is used. In particular, in the issue `dig` was trying to connect to `https://::1:444/dns-query` inste...One of the causes why the problem #2858 appeared is that the URL in the DoH code might get generated in wrong format at least when IPv6 is used. In particular, in the issue `dig` was trying to connect to `https://::1:444/dns-query` instead of `https://[::1]:444/dns-query`. Obviously, this issue prevents `dig` from querying servers via its IPv6 addresses (querying hostnames available via IPv6 works fine).
Also, it will always generate a URL starting with `https://` regardless of the fact if we use HTTP with encryption or not.
So, while the fix for the problem reported is already prepared (!5319), this issue needs to be taken care of as well. The code which prepared the URL needs to be revisited.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2861Extend the doth system test with dig invocations doing name resolution agains...2021-09-01T10:43:40ZArtem BoldarievExtend the doth system test with dig invocations doing name resolution against an IPv6 addressCurrently the `doth` system test uses IPv4 addresses exclusively. We might want to extend it with `dig` invocations against a server listening on an IPv6 address. That should help preventing issues like #2858, #2860.Currently the `doth` system test uses IPv4 addresses exclusively. We might want to extend it with `dig` invocations against a server listening on an IPv6 address. That should help preventing issues like #2858, #2860.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2863WSL crash with Dig when querying DoH server2021-08-16T11:29:58ZtriaticWSL crash with Dig when querying DoH server<!--
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
Following the decision to remove the native Windows binaries I would like to use Dig under Windows Subsystem for Linux (WSL, Ubuntu on Windows). Specifically I would like to use Dig to query DNS-over-HTTPS, so have installed the dev PPA. However a crash is observed when running DoH queries on WSL, but no such crash for non-DoH queries.
### BIND version used
```
C:\>wsl dig -v
DiG 9.17.16-1+ubuntu20.04.1+isc+1-Ubuntu
```
### Steps to reproduce
Install Ubuntu on Windows, add the dev PPA, and run the following command:
`wsl dig +https @dns.google isc.org A`
### What is the current *bug* behavior?
Error output:
`netmgr/tcp.c:135: fatal error: RUNTIME_CHECK(result == 0) failed`
### What is the expected *correct* behavior?
The A record for isc.org.
This is the output for non DoH:
```
C:\>wsl dig @dns.google isc.org A
; <<>> DiG 9.17.16-1+ubuntu20.04.1+isc+1-Ubuntu <<>> @dns.google isc.org A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40794
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;isc.org. IN A
;; ANSWER SECTION:
isc.org. 59 IN A 149.20.1.66
;; Query time: 27 msec
;; SERVER: 8.8.8.8#53(dns.google) (UDP)
;; WHEN: Mon Aug 16 11:19:05 BST 2021
;; MSG SIZE rcvd: 52
```
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
N/ASeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2875DoH code relies on HTTP headers processing order2021-08-25T08:02:29ZArtem BoldarievDoH code relies on HTTP headers processing orderDoH code makes assumptions regarding the HTTP (pseudo)header processing order. In particular, it assumes that `:method:` pseudo-header will be processed one of the first, which might not be true. In this case, the request will be treated...DoH code makes assumptions regarding the HTTP (pseudo)header processing order. In particular, it assumes that `:method:` pseudo-header will be processed one of the first, which might not be true. In this case, the request will be treated as a bad one.
The problem was found when testing the DoH code with `h2load`, an `HTTP/2` and `HTTP 1.1` benchmarking tool being developed by `libnghttp2` authors. The problem revealed itself only when testing `POST` requests (`GET` requests were fine).
```
h2load -t 8 -c 300 -m 100 -n 1000000 -d ~/projects/isc/request_data.bin -H "content-type:application/dns-message" https://doh.example.com/dns-query
```
In order to resolve the problem we need to move the checks which require certain headers to be processed first into `server_on_request_recv()`, which knows all the required context.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2877v9.17 cannot be compiled on a system without libnghttp2 library2021-09-01T10:37:04ZPetr Špačekpspacek@isc.orgv9.17 cannot be compiled on a system without libnghttp2 library### Summary
main branch cannot be compiled on a system without libnghttp2 library.
### BIND version used
00c376f34d6e4732e5bb68638db7fca488ae26d1
### Steps to reproduce
1. Start with a system without libnghttp2
2. Run ./configure '-...### Summary
main branch cannot be compiled on a system without libnghttp2 library.
### BIND version used
00c376f34d6e4732e5bb68638db7fca488ae26d1
### Steps to reproduce
1. Start with a system without libnghttp2
2. Run ./configure '--disable-doh'
3. Run make
### What is the current *bug* behavior?
Compilation fails:
```
main.c:104:10: fatal error: nghttp2/nghttp2.h: No such file or directory
104 | #include <nghttp2/nghttp2.h>
```
Also, it seems that `--with-libnghttp2=no` is not implied by `--disable-doh`, but using both switches at the same time does not fix the build.
### What is the expected *correct* behavior?
Compiles and works.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2902wrong default is used for HTTP port2021-10-04T09:33:00ZEvan Huntwrong default is used for HTTP portNoticed while looking at code, if the HTTP (non-encrypted) listening port is specified on the command line, the wrong value is used for the listener.
```
} else if (http && !do_tls) {
if (named_g_ht...Noticed while looking at code, if the HTTP (non-encrypted) listening port is specified on the command line, the wrong value is used for the listener.
```
} else if (http && !do_tls) {
if (named_g_httpport != 0) {
port = named_g_port;
```
This means if you ran `named -p http=N`, it would try to listen for HTTP connections on port 53.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2923Dig crashes with SIGABRT when parsing invalid DoH endpoint location2022-04-26T13:21:41ZfriedlhoDig crashes with SIGABRT when parsing invalid DoH endpoint location### Summary
Dig crashes with SIGABRT when providing an invalid DoH endpoint location.
### BIND version used
DiG 9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu
(Bind9-Dev Branch)
Tested on Ubuntu 20 & Fedora 34.
### Steps to reproduce
Call d...### Summary
Dig crashes with SIGABRT when providing an invalid DoH endpoint location.
### BIND version used
DiG 9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu
(Bind9-Dev Branch)
Tested on Ubuntu 20 & Fedora 34.
### Steps to reproduce
Call dig with a DoH URI and manually specify the DoH Endpoint location without a leading "/":
dig +https=doh/family-filter @doh.cleanbrowsing.org rub.de
The correct command would be:
dig +https=/doh/family-filter @doh.cleanbrowsing.org rub.de
### What is the current *bug* behavior?
Dig crashed with SIGABRT in isc_assertion_failed()
### What is the expected *correct* behavior?
Dig outputs an error message to tell the user that the endpoint location is invalid.
### Relevant logs and/or screenshots
```
dig +https=doh/family-filter @doh.cleanbrowsing.org google.de#
netmgr/http.c:3098: REQUIRE(isc_nm_http_path_isvalid(abs_path)) failed, back trace
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x31d93)[0x7f3798d69d93]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_assertion_failed+0x10)[0x7f3798d69cd0]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_nm_http_makeuri+0x2aa)[0x7f3798da924a]
dig(+0x13ff7)[0x558504aa0ff7]
dig(+0x1721a)[0x558504aa421a]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_task_run+0x162)[0x7f3798d99572]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x19ead)[0x7f3798d51ead]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x204f1)[0x7f3798d584f1]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x20c15)[0x7f3798d58c15]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x213e7)[0x7f3798d593e7]
/lib/x86_64-linux-gnu/libuv.so.1(+0xfea8)[0x7f379885eea8]
/lib/x86_64-linux-gnu/libuv.so.1(uv__io_poll+0x360)[0x7f379886fb80]
/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x11c)[0x7f379885f84c]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x20ca7)[0x7f3798d58ca7]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc__trampoline_run+0x1a)[0x7f3798da08ba]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609)[0x7f3798a7b609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f37989a2293]
Aborted (core dumped)
```
```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `dig +https doh/family-filter @doh.cleanbrowsing.org rub.de'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f2629900700 (LWP 52138))]
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f262c3de859 in __GI_abort () at abort.c:79
#2 0x00007f262c8a2cd5 in isc_assertion_failed () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#3 0x00007f262c8e224a in isc_nm_http_makeuri () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#4 0x0000564d70879ff7 in ?? ()
#5 0x0000564d7087d21a in ?? ()
#6 0x00007f262c8d2572 in isc_task_run () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#7 0x00007f262c88aead in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#8 0x00007f262c8914f1 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#9 0x00007f262c891c15 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#10 0x00007f262c8923e7 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#11 0x00007f262c397ea8 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x00007f262c3a8b80 in uv.io_poll () from /lib/x86_64-linux-gnu/libuv.so.1
#13 0x00007f262c39884c in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#14 0x00007f262c891ca7 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#15 0x00007f262c8d98ba in isc.trampoline_run () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#16 0x00007f262c5b4609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#17 0x00007f262c4db293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2924heap-use-after-free caused by checking for duplicate "http" configurations2021-10-04T10:15:31ZArtem Boldarievheap-use-after-free caused by checking for duplicate "http" configurationsChecking for duplicate `http` clauses in configuration files leads to heap use after free.
```
=================================================================
==1833==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300002b...Checking for duplicate `http` clauses in configuration files leads to heap use after free.
```
=================================================================
==1833==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300002b420 at pc 0x7fbcc0f4c4f2 bp 0x7ffdd9e9a170 sp 0x7ffdd9e99920
READ of size 1 at 0x60300002b420 thread T0
#0 0x7fbcc0f4c4f1 (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb64f1)
#1 0x7fbcc0b2dacd in isc_symtab_define /builds/isc-projects/bind9/lib/isc/symtab.c:221
#2 0x7fbcbe556dfc in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2046
#3 0x7fbcbe556dfc in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#4 0x7fbcbe556dfc in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#5 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#6 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
#7 0x55798af697c9 in _start (/builds/isc-projects/bind9/bin/check/.libs/named-checkconf+0xa7c9)
0x60300002b420 is located 0 bytes inside of 18-byte region [0x60300002b420,0x60300002b432)
freed by thread T0 here:
#0 0x7fbcc0f7efb0 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
#1 0x7fbcc0ac2ca6 in sdallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:39
#2 0x7fbcc0ac2ca6 in mem_put /builds/isc-projects/bind9/lib/isc/mem.c:361
#3 0x7fbcc0ac2ca6 in isc__mem_free /builds/isc-projects/bind9/lib/isc/mem.c:977
#4 0x7fbcbe556e22 in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2066
#5 0x7fbcbe556e22 in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#6 0x7fbcbe556e22 in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#7 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#8 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7fbcc0f7f330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7fbcc0ac1020 in mallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:29
#2 0x7fbcc0ac1020 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:341
#3 0x7fbcc0ac1020 in isc__mem_allocate /builds/isc-projects/bind9/lib/isc/mem.c:886
#4 0x7fbcc0ac429b in isc__mem_strdup /builds/isc-projects/bind9/lib/isc/mem.c:996
#5 0x7fbcbe556d8b in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2039
#6 0x7fbcbe556d8b in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#7 0x7fbcbe556d8b in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#8 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#9 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb64f1)
Shadow bytes around the buggy address:
0x0c067fffd630: 00 00 00 fa fa fa 00 00 02 fa fa fa 00 00 00 fa
0x0c067fffd640: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00
0x0c067fffd650: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa
0x0c067fffd660: 00 00 02 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c067fffd670: fa fa 00 00 00 00 fa fa 00 00 02 fa fa fa 00 00
=>0x0c067fffd680: 00 fa fa fa[fd]fd fd fa fa fa 00 00 02 fa fa fa
0x0c067fffd690: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==1833==ABORTING
```
The problem was found by accident while working on a similar code in !5444October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2925Defining "default" "http" clause should not be allowed in the configuration2021-10-05T10:12:27ZArtem BoldarievDefining "default" "http" clause should not be allowed in the configurationDefining 'default' 'http' configuration should not be allowed in configuration files, as `default` is reserved for internal use in `listen-on` statements. For example, the following configuration file should be rejected:
```
tls local-t...Defining 'default' 'http' configuration should not be allowed in configuration files, as `default` is reserved for internal use in `listen-on` statements. For example, the following configuration file should be rejected:
```
tls local-tls {
key-file "key.pem";
cert-file "cert.pem";
};
http default {
endpoints { "/dns-query"; };
listener-clients 100;
streams-per-connection 100;
};
options {
listen-on { 10.53.0.1; };
http-port 80;
https-port 443;
http-listener-clients 100;
http-streams-per-connection 100;
listen-on port 443 tls local-tls http default { 10.53.0.1; };
listen-on port 8080 tls none http default { 10.53.0.1; };
};
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3019doth max-age tests failing on ALPN negotiation MacOS (macports)2021-11-25T09:19:42ZMark Andrewsdoth max-age tests failing on ALPN negotiation MacOS (macports)```
I:doth:checking max-age for positive answer (136)
I:doth:failed
I:doth:checking max-age for negative answer (137)
I:doth:failed
I:doth:exit status: 2
```
```
[ant-2875:bin/tests/system] marka% /opt/local/bin/curl -vkD headers 'https...```
I:doth:checking max-age for positive answer (136)
I:doth:failed
I:doth:checking max-age for negative answer (137)
I:doth:failed
I:doth:exit status: 2
```
```
[ant-2875:bin/tests/system] marka% /opt/local/bin/curl -vkD headers 'https://10.53.0.1:5303/dns-query?dns=AAEAAAABAAAAAAAAB2V4YW1wbGUAAAYAAQ'
* Trying 10.53.0.1:5303...
* Connected to 10.53.0.1 (10.53.0.1) port 5303 (#0)
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=AQ; O=BIND9 ephemeral certificate; CN=bind9.local
* start date: Nov 19 01:27:08 2021 GMT
* expire date: Nov 17 01:27:08 2031 GMT
* issuer: C=AQ; O=BIND9 ephemeral certificate; CN=bind9.local
* SSL certificate verify result: self-signed certificate (18), continuing anyway.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /dns-query?dns=AAEAAAABAAAAAAAAB2V4YW1wbGUAAAYAAQ HTTP/1.1
> Host: 10.53.0.1:5303
> User-Agent: curl/7.80.0
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS alert, close notify (256):
* Empty reply from server
* Closing connection 0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (52) Empty reply from server
[ant-2875:bin/tests/system] marka%
```
Nothing is logged in `named.run`.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3022DoH: dig eventually aborts on ALPN negotiation failure when issuing a DoH que...2021-12-01T08:58:44ZArtem BoldarievDoH: dig eventually aborts on ALPN negotiation failure when issuing a DoH query (because of dangling handles)It was found by accident that `dig` crashes when issuing a query against a server which does not support HTTP/2, or to be more precise, when 'h2' ALPN token negotiation fails.
```
;; Connection to 127.0.0.1#44344(127.0.0.1) for example ...It was found by accident that `dig` crashes when issuing a query against a server which does not support HTTP/2, or to be more precise, when 'h2' ALPN token negotiation fails.
```
;; Connection to 127.0.0.1#44344(127.0.0.1) for example failed: ALPN for HTTP/2 failed.
;; Connection to 127.0.0.1#44344(127.0.0.1) for example failed: ALPN for HTTP/2 failed.
;; Connection to 127.0.0.1#44344(127.0.0.1) for example failed: ALPN for HTTP/2 failed.
Outstanding sockets
=================
Active server socket 0x7f172da91a00, type isc_nm_tlssocket, refs 1
Parent (nil), listener (nil), server (nil), statichandle = (nil)
Flags: closing
Created by:
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc___nmsocket_init+0x276)[0x7f1732594301]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_tlsconnect+0xb9)[0x7f17325fbfdb]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_httpconnect+0x89f)[0x7f17325f1ce2]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x18fb5)[0x560157b26fb5]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e20d)[0x560157b2c20d]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x14874)[0x560157b22874]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e2a6)[0x560157b2c2a6]
=================
Active server socket 0x7f172da93800, type isc_nm_tlssocket, refs 1
Parent (nil), listener (nil), server (nil), statichandle = (nil)
Flags: closing
Created by:
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc___nmsocket_init+0x276)[0x7f1732594301]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_tlsconnect+0xb9)[0x7f17325fbfdb]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_httpconnect+0x89f)[0x7f17325f1ce2]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x18fb5)[0x560157b26fb5]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e20d)[0x560157b2c20d]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x14874)[0x560157b22874]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x13dfd)[0x560157b21dfd]
=================
Active server socket 0x7f172da91000, type isc_nm_tlssocket, refs 1
Parent (nil), listener (nil), server (nil), statichandle = (nil)
Flags: closing
Created by:
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc___nmsocket_init+0x276)[0x7f1732594301]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_tlsconnect+0xb9)[0x7f17325fbfdb]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_httpconnect+0x89f)[0x7f17325f1ce2]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x18fb5)[0x560157b26fb5]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e20d)[0x560157b2c20d]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x14874)[0x560157b22874]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x13dfd)[0x560157b21dfd]
netmgr/netmgr.c:578: INSIST(0) failed, back trace
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(+0x42894)[0x7f17325b2894]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_assertion_failed+0x31)[0x7f17325b27a7]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc__netmgr_destroy+0x10d)[0x7f173258f0d8]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_managers_destroy+0xf5)[0x7f17325ca823]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e815)[0x560157b2c815]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0xef35)[0x560157b1cf35]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0xef96)[0x560157b1cf96]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7f1731645b25]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x5e9e)[0x560157b13e9e]
Aborted (core dumped)
```December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3053named crash after reconfiguration when "allow-recursion" changed2022-04-05T16:02:29ZMichal Nowaknamed crash after reconfiguration when "allow-recursion" changedWith BIND 9.17.20 on Fedora 35 from my [Copr fork](https://copr.fedorainfracloud.org/coprs/mnohime/bind-dev/packages/) I get a reproducible `named` segfault few seconds after I add IP entry to `allow-recursion` list, save `named.conf` (a...With BIND 9.17.20 on Fedora 35 from my [Copr fork](https://copr.fedorainfracloud.org/coprs/mnohime/bind-dev/packages/) I get a reproducible `named` segfault few seconds after I add IP entry to `allow-recursion` list, save `named.conf` (attached), and reconfigure `named` with `rndc reconfig` (if I restart `named` service instead of reconfiguration in the last step, no crash happens).
Also happens with Fedora 34 BIND 9.17.20 packages on Fedora 35 from the official Copr repo (we don't provide official Fedora 35 packages yet).
backtrace:
```
Core was generated by `/opt/isc/isc-bind/root/usr/sbin/named -u named'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:476
476 VMOVU -VEC_SIZE(%rsi, %rdx), %VEC(5)
[Current thread is 1 (Thread 0x7f0479b7f640 (LWP 1360))]
(gdb) bt
#0 __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:476
#1 0x00007f047b342de2 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:29
#2 OPENSSL_sk_dup (sk=0x7f04740138f0) at crypto/stack/stack.c:66
#3 0x00007f047ad25111 in sk_SSL_CIPHER_dup (sk=<optimized out>) at include/openssl/ssl.h:963
#4 SSL_new (ctx=ctx@entry=0x7f04740161a0) at ssl/ssl_lib.c:717
#5 0x00007f047b7d1a23 in isc_tls_create (ctx=0x7f04740161a0) at /usr/src/debug/isc-bind-bind-9.17.20-1.1.fc35.x86_64/lib/isc/tls.c:607
#6 0x00007f047b7df109 in tlslisten_acceptcb (handle=0x7f04789ee280, result=<optimized out>, cbarg=0x7f0478976800) at netmgr/tlsstream.c:595
#7 0x00007f047b7a062e in accept_connection (ssock=ssock@entry=0x7f0478977c00, quota=<optimized out>) at netmgr/tcp.c:1018
#8 0x00007f047b7a137e in tcp_connection_cb (server=<optimized out>, status=<optimized out>) at netmgr/tcp.c:632
#9 0x00007f047b1892f7 in uv__server_io (loop=0x7f047a231010, w=0x7f04789781b8, events=<optimized out>) at src/unix/stream.c:570
#10 0x00007f047b18ed3d in uv__io_poll (loop=0x7f047a231010, timeout=<optimized out>) at src/unix/linux-core.c:462
#11 0x00007f047b17e8e4 in uv_run (loop=loop@entry=0x7f047a231010, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:385
#12 0x00007f047b7a201e in nm_thread (worker0=0x7f047a231000) at netmgr/netmgr.c:688
#13 0x00007f047b7d517a in isc__trampoline_run (arg=0x561a73df6500) at /usr/src/debug/isc-bind-bind-9.17.20-1.1.fc35.x86_64/lib/isc/trampoline.c:185
#14 0x00007f047ae0bad7 in start_thread (arg=<optimized out>) at pthread_create.c:435
#15 0x00007f047ae90770 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
```
[full backtrace](/uploads/f32799c1cd4ec7910ca867060a4cc82b/coredump.txt)
<details><summary>named.conf</summary>
```
tls local-tls {
key-file "/etc/letsencrypt/live/dns.mnowak.cz/privkey.pem";
cert-file "/etc/letsencrypt/live/dns.mnowak.cz/fullchain.pem";
};
options {
directory "/var/opt/isc/scls/isc-bind/named/data";
listen-on port 443 tls local-tls http default { any; };
listen-on-v6 port 443 tls local-tls http default { any; };
listen-on { any; };
listen-on-v6 { any; };
listen-on tls ephemeral { any; };
listen-on-v6 tls ephemeral { any; };
dnssec-validation auto;
recursion yes;
allow-recursion { 2a02:8308:a007:f700::0/64; 86.49/16; localhost; };
querylog yes;
max-cache-size 90%;
};
statistics-channels {
inet * port 666 allow { 2a02:8308:a007:f700::0/64; 86.49/16; localhost; };
};
logging {
channel default_debug {
file "named.run";
print-time yes;
severity dynamic;
};
};
key "rndc-key" {
algorithm hmac-sha256;
secret "5BLhJni/LLWlg8Lo09iTqhvJgvLmViEmcf60b+XX07o=";
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
```
</details>
[core.gz](/uploads/b1e7ef5c910e925f1a8392237f3408ad/core.gz)
[named.gz](/uploads/b1ce3ea46b71e50fa430e4be0838a5a4/named.gz)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/3056TLS/HTTPS interfaces should only be shut down when reconfiguring2022-01-11T14:18:57ZEvan HuntTLS/HTTPS interfaces should only be shut down when reconfiguringAfter #3053 was merged, scanning interfaces became a destructive process - whenever there's a change to the listening interfaces, all TLS and HTTPS listeners are shut down and recreated. This was only meant to happen when the server was ...After #3053 was merged, scanning interfaces became a destructive process - whenever there's a change to the listening interfaces, all TLS and HTTPS listeners are shut down and recreated. This was only meant to happen when the server was being reconfigured, and we need to fix it so that's the only time it does happen.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3067Implement TLS context cache2022-01-04T16:05:39ZArtem BoldarievImplement TLS context cacheThe intention of having a TLS context cache object is manyfold:
- In the case of client-side contexts: allow reusing the previously
created contexts to employ the context-specific TLS session resumption
cache. That will enable XoT conne...The intention of having a TLS context cache object is manyfold:
- In the case of client-side contexts: allow reusing the previously
created contexts to employ the context-specific TLS session resumption
cache. That will enable XoT connection to be reestablished faster and
with fewer resources by not going through the full TLS handshake
procedure.
- In the case of server-side contexts: reduce the number of contexts
created on startup. That could reduce startup time in a case when
there are many `listen-on` statements referring to a smaller amount of
`tls` statements, especially when `ephemeral` certificates are
involved.
- The long-term goal is to provide in-memory storage for additional
data associated with the certificates, like runtime
representation (`X509_STORE`) of intermediate CA-certificates bundle for
Strict TLS/Mutual TLS (`ca-file`).
*See !5672, #1784*January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3087ephemeral TLS certificate incompatible with GnuTLS and NSS libraries2022-01-27T05:30:45ZPetr Špačekpspacek@isc.orgephemeral TLS certificate incompatible with GnuTLS and NSS libraries### Summary
It seems that GnuTLS and NSS libraries do not accept ephemeral TLS certificate we generate internally in `named`.
### BIND version used
* ~"Affects v9.17": 47a9915888b188d9e612b0f79e71cf72b84b511c
* openssl 1.1.1.m-1
* gnu...### Summary
It seems that GnuTLS and NSS libraries do not accept ephemeral TLS certificate we generate internally in `named`.
### BIND version used
* ~"Affects v9.17": 47a9915888b188d9e612b0f79e71cf72b84b511c
* openssl 1.1.1.m-1
* gnutls 3.7.2-2
* firefox 95.0.2-1
Arch Linux, 64-bit x86_64.
### Steps to reproduce
* Configure BIND to use ephemeral TLS certificate: [named.conf](/uploads/8b4f1cc392a72a994987eaf91a914bd9/named.conf) (It does not matter if it is DoT or DoH.)
* Try to connect to BIND over TLS using GnuTLS or Firefox (NSS) libraries.
### What is the current *bug* behavior?
* GnuTLS reports:
```
$ gnutls-cli --no-ca-verification 127.0.0.1:4433
Connecting to '127.0.0.1:4433'...
*** Fatal error: Error in parsing.
```
* Firefox reports:
```
An error occurred during a connection to 127.0.0.1:4433. Peer’s certificate has an invalid signature.
Error code: SEC_ERROR_BAD_SIGNATURE
```
### What is the expected *correct* behavior?
Well, all usual libraries should be able to use the cert.
### Relevant configuration files
[named.conf](/uploads/8b4f1cc392a72a994987eaf91a914bd9/named.conf)
### Relevant logs and/or screenshots
GnuTLS debug log: [gnutls.log](/uploads/6aacb4ce6290a1435c3480a2f0607e90/gnutls.log) (generated using -d 999)
PCAP: [pcap](/uploads/d131de40ea1fde80b1a3c2035d03edae/pcap)
pre-master secrets: [tlskeys](/uploads/9eed6628650cfb01afb986e23f7201c4/tlskeys)January 2022 (9.18.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3122DoT stops working after "rndc reconfigure" when running named as non-root2024-01-11T14:13:01ZsthaugDoT stops working after "rndc reconfigure" when running named as non-root<!--
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
DoT stops working after "rndc reconfigure" when running named as non-root
### BIND version used
```
BIND 9.18.0 (Stable Release) <id:8db45af>
running on FreeBSD amd64 12.3-STABLE FreeBSD 12.3-STABLE r371270 DNS_VIMAGE
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--enable-dnsrps' '--with-readline=libedit' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-querytrace' '--enable-tcp-fastopen' '--prefix=/usr/local' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.2' 'build_alias=amd64-portbld-freebsd12.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 'READLINE_CFLAGS=-L/usr/local/lib'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
compiled with OpenSSL version: OpenSSL 1.1.1m-freebsd 14 Dec 2021
linked to OpenSSL version: OpenSSL 1.1.1m-freebsd 14 Dec 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libnghttp2 version: 1.44.0
linked to libnghttp2 version: 1.44.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
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.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
Also tried 9.17.18 (Installed from FreeBSD package) and 9.17.22 (compiled from source).
### Steps to reproduce
Start named with the following command line:
/usr/local/sbin/named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
and with the following named.conf file:
```
options {
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { 193.75.110.2; 127.0.0.1; };
listen-on port 853 tls dotas2116 { 193.75.110.2; 127.0.0.1; };
interface-interval 0;
recursion yes;
max-cache-size 1500M;
minimal-any yes;
minimal-responses yes;
querylog yes;
allow-query { 194.19.2.0/24; 193.75.110.0/24; 127.0.0.1; };
};
tls dotas2116 {
cert-file "/usr/local/etc/namedb/fullchain.pem";
key-file "/usr/local/etc/namedb/privkey.pem";
protocols { TLSv1.2; TLSv1.3; };
};
```
### What is the current *bug* behavior?
After doing "rndc reconfigure" named no longer listens to TCP port 853. This is visible in the log:
```
Jan 31 16:29:08 nslum named[42849]: no longer listening on 127.0.0.1#853
Jan 31 16:29:08 nslum named[42849]: listening on IPv4 interface lo0, 127.0.0.1#853
Jan 31 16:29:08 nslum named[42849]: creating TLS socket: permission denied
Jan 31 16:29:08 nslum named[42849]: creating IPv4 interface lo0 failed; interface ignored
Jan 31 16:29:08 nslum named[42849]: no longer listening on 193.75.110.2#853
Jan 31 16:29:08 nslum named[42849]: listening on IPv4 interface ixl1.15, 193.75.110.2#853
Jan 31 16:29:08 nslum named[42849]: creating TLS socket: permission denied
Jan 31 16:29:08 nslum named[42849]: creating IPv4 interface ixl1.15 failed; interface ignored
```
Using "dig +tls" to test results in:
;; Connection to 193.75.110.2#853(193.75.110.2) for vg.no failed: connection refused.
and using the FreeBSD "sockstat" command shows named is not listening to TCP port 853.
### What is the expected *correct* behavior?
The expected behavior is that "dig +tls" works, and resolves names normally. This works right after startup - and using the "sockstat command I can see that named is listening to TCP port 853:
```
Jan 31 16:27:10 nslum named[42849]: listening on IPv4 interface lo0, 127.0.0.1#853
Jan 31 16:27:10 nslum named[42849]: listening on IPv4 interface ixl1.15, 193.75.110.2#853
```
### Relevant configuration files
See named.conf above.
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3163Add remote TLS certificate verification support, implement Strict and Mutual ...2022-05-16T10:24:55ZArtem BoldarievAdd remote TLS certificate verification support, implement Strict and Mutual TLS authentication[RFC 9103, Section 9.3,](https://www.rfc-editor.org/rfc/rfc9103.html#name-tls) discusses three TLS-based authentication mechanisms:
- Opportunistic TLS;
- Strict TLS;
- Mutual TLS.
Currently, the released version of BIND and its comple...[RFC 9103, Section 9.3,](https://www.rfc-editor.org/rfc/rfc9103.html#name-tls) discusses three TLS-based authentication mechanisms:
- Opportunistic TLS;
- Strict TLS;
- Mutual TLS.
Currently, the released version of BIND and its complementary tools have support for the first one.
In order to implement support for Strict and Mutual TLS, the functionality to verify the remote TLS certificates needs to be added first.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3216[CVE-2022-1183] Destroying TLS stream too early triggers assertion failure2022-06-27T21:14:33ZOndřej Surý[CVE-2022-1183] Destroying TLS stream too early triggers assertion failure### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exist...### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exists
- [x] Create a draft of the security advisory and put the information above in there
- [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)
- explanation of code flow which triggers the problem (a system test is *not* good enough)
- [x] Prepare a private merge request containing the following items in separate commits: https://gitlab.isc.org/isc-private/bind9/-/merge_requests/395
- 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
- [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
### Post-disclosure actions
- [x] [Merge a regression test reproducing the bug into all affected (and still maintained) BIND branches](!6365)
---
Reported by Thomas Amgarten to security-officer
As described here https://www.isc.org/reportbug/, I want you to inform about a denial-of-service situation, which is triggered with a simple [ssl-scanner](https://www.kali.org/tools/sslyze/) from the kali-suite.
Using BIND-9.18.1 and a DoH-configuration like this:
```
http myserver {
endpoints { "/dns-query"; };
};
options {
listen-on port 443 tls ephemeral http myserver { 127.0.0.1; 10.100.102.21; };
};
```
BIND is compiled with the following options.....
```
$ named -V
BIND 9.18.1 (Stable Release) <id:1a4e4c2>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.18.1' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' 'PKG_CONFIG_PATH=:/usr/local/libuv/lib/pkgconfig/'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
....and is started like this:
```
$ ps -o command -u named
COMMAND
/usr/local/bind/sbin/named -4 -t /opt/chroot/bind -u named -c /etc/named/named.conf
```
Running the following oneliner - where 10.100.102.21 is the IP address of BIND with the enabled DoH-configuration on port TCP-443 - triggers an assertion failure in 99% of all my tries and named stops working:
`$ for ((i=1; i<10; i++)); do sslyze 10.100.102.21 & done`
```
17-Mar-2022 14:58:25.213 general: critical: netmgr/netmgr.c:1423: REQUIRE(((*sockp) != ((void *)0) && ((const isc__magic_t *)(*sockp))->magic == ((('N') << 24 | ('M') << 16 | ('S') << 8 | ('K'))))) failed, back trace
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind/sbin/named() [0x41da4d]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(isc_assertion_failed+0xa) [0x7fa283bf665a]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(isc___nmsocket_detach+0xc6) [0x7fa283be3e96]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(isc__nm_put_netievent_connectcb+0x15) [0x7fa283be4425]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(+0x2329f) [0x7fa283be529f]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(+0x239e6) [0x7fa283be59e6]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(+0x24162) [0x7fa283be6162]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/libuv-1.41.0/lib/libuv.so.1(+0x11501) [0x7fa282386501]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/libuv-1.41.0/lib/libuv.so.1(uv__io_poll+0x475) [0x7fa282396de5]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/libuv-1.41.0/lib/libuv.so.1(uv_run+0x104) [0x7fa282386c24]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(+0x23a7f) [0x7fa283be5a7f]
17-Mar-2022 14:58:25.213 general: critical: /usr/local/bind-9.18.1/lib/libisc-9.18.1.so(isc__trampoline_run+0x15) [0x7fa283c1cf35]
17-Mar-2022 14:58:25.213 general: critical: /lib64/libpthread.so.0(+0x815a) [0x7fa28190b15a]
17-Mar-2022 14:58:25.213 general: critical: /lib64/libc.so.6(clone+0x43) [0x7fa28163add3]
17-Mar-2022 14:58:25.213 general: critical: exiting (due to assertion failure)
```
**The patch for 9.18.2:**
~~[sslyze-crash-fix-9.18.2.patch](/uploads/0ed4688783cd37d8e3fc0f2a55c68f88/sslyze-crash-fix-9.18.2.patch)~~
[0001-CVE-2022-1183.patch](/uploads/f8efad10f54069fe51cc200022c06508/0001-CVE-2022-1183.patch)May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/326932-bit named sometimes fails to start in doth test2023-03-28T14:42:19ZMichal Nowak32-bit named sometimes fails to start in doth testJob [#2440515](https://gitlab.isc.org/isc-private/bind9/-/jobs/2440515) failed for cab15392afd841fe3b0bacd894003376d857459a:
```
S:doth:2022-04-11T08:39:50+0000
T:doth:1:A
A:doth:System test doth
I:doth:PORTS:30179,30180,30181,30182,3018...Job [#2440515](https://gitlab.isc.org/isc-private/bind9/-/jobs/2440515) failed for cab15392afd841fe3b0bacd894003376d857459a:
```
S:doth:2022-04-11T08:39:50+0000
T:doth:1:A
A:doth:System test doth
I:doth:PORTS:30179,30180,30181,30182,30183,30184,30185,30186,30187,30188,30189,30190,30191
I:doth:starting servers
I:doth:Couldn't start server /builds/isc-private/bind9/bin/named/named -D doth-ns1 -X named.lock -m record -c named.conf -d 99 -g -U 4 -T maxcachesize=2097152 >named.run 2>&1 & echo $! (pid=1600)
I:doth:failed
I:doth:ns1 didn't die when sent a SIGTERM
I:doth:starting servers failed
I:doth:No tests were found and run
I:doth:Core dump(s) found: doth/ns1/core.1600
D:doth:backtrace from doth/ns1/core.1600:
D:doth:--------------------------------------------------------------------------------
D:doth:Core was generated by `/builds/isc-private/bind9/bin/named/.libs/named -D doth-ns1 -X named.lock -m re'.
D:doth:Program terminated with signal SIGABRT, Aborted.
D:doth:#0 0xf7f98069 in __kernel_vsyscall ()
D:doth:[Current thread is 1 (Thread 0xf4f384c0 (LWP 1600))]
D:doth:#0 0xf7f98069 in __kernel_vsyscall ()
D:doth:#1 0xf72b4cd2 in sigtimedwait () from /lib/i386-linux-gnu/libc.so.6
D:doth:#2 0xf747c13d in sigwait () from /lib/i386-linux-gnu/libpthread.so.0
D:doth:#3 0xf7cba3e4 in isc_app_ctxrun (ctx=<optimized out>) at app.c:236
D:doth:#4 0xf7cba57b in isc_app_run () at app.c:288
D:doth:#5 0x5663b81a in main (argc=16, argv=0xff99aa34) at main.c:1459
D:doth:--------------------------------------------------------------------------------
D:doth:full backtrace from doth/ns1/core.1600 saved in doth/ns1/core.1600-backtrace.txt
D:doth:core dump doth/ns1/core.1600 archived as doth/ns1/core.1600.gz
R:doth:FAIL
E:doth:2022-04-11T08:41:53+0000
FAIL doth (exit status: 1)
```
Lines about `named` listening on interfaces is missing (ns1 `named.run`):
```
11-Apr-2022 08:39:50.952 starting BIND 9.19.0 (Development Release) <id:cab1539>
11-Apr-2022 08:39:50.952 running on Linux x86_64 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
11-Apr-2022 08:39:50.952 built with '--disable-maintainer-mode' '--enable-developer' '--enable-option-checking=fatal' '--enable-dnstap' '--with-cmocka' '--with-libxml2' '--with-json-c' '--build=x86_64-linux-gnu' '--host=i686-linux-gnu' '--with-libidn2' '--with-readline=libedit' 'build_alias=x86_64-linux-gnu' 'host_alias=i686-linux-gnu' 'CFLAGS=-fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra'
11-Apr-2022 08:39:50.952 running as: named -D doth-ns1 -X named.lock -m record -c named.conf -d 99 -g -U 4 -T maxcachesize\=2097152
11-Apr-2022 08:39:50.952 compiled by GCC 10.2.1 20210110
11-Apr-2022 08:39:50.952 compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
11-Apr-2022 08:39:50.952 linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
11-Apr-2022 08:39:50.952 compiled with libxml2 version: 2.9.10
11-Apr-2022 08:39:50.952 linked to libxml2 version: 20910
11-Apr-2022 08:39:50.952 compiled with json-c version: 0.15
11-Apr-2022 08:39:50.952 linked to json-c version: 0.15
11-Apr-2022 08:39:50.952 compiled with zlib version: 1.2.11
11-Apr-2022 08:39:50.952 linked to zlib version: 1.2.11
11-Apr-2022 08:39:50.952 ----------------------------------------------------
11-Apr-2022 08:39:50.952 BIND 9 is maintained by Internet Systems Consortium,
11-Apr-2022 08:39:50.952 Inc. (ISC), a non-profit 501(c)(3) public-benefit
11-Apr-2022 08:39:50.952 corporation. Support and training for BIND 9 are
11-Apr-2022 08:39:50.952 available at https://www.isc.org/support
11-Apr-2022 08:39:50.952 ----------------------------------------------------
11-Apr-2022 08:39:50.952 found 12 CPUs, using 12 worker threads
11-Apr-2022 08:39:50.952 using 4 UDP listeners per interface
11-Apr-2022 08:39:50.960 Registering DLZ_dlopen driver
11-Apr-2022 08:39:50.960 Registering SDLZ driver 'dlopen'
11-Apr-2022 08:39:50.960 Registering DLZ driver 'dlopen'
11-Apr-2022 08:39:50.980 config.c: option 'trust-anchor-telemetry' is experimental and subject to change in the future
11-Apr-2022 08:39:50.980 loading configuration from '/builds/isc-private/bind9/bin/tests/system/doth/ns1/named.conf'
11-Apr-2022 08:39:50.980 unable to open '/usr/local/etc/bind.keys'; using built-in keys instead
11-Apr-2022 08:39:50.980 exclusive task mode: starting
11-Apr-2022 08:39:51.004 exclusive task mode: started
11-Apr-2022 08:39:51.004 set maximum stack size to 18446744073709551615: success
11-Apr-2022 08:39:51.004 set maximum data size to 18446744073709551615: success
11-Apr-2022 08:39:51.004 set maximum core size to 18446744073709551615: success
11-Apr-2022 08:39:51.004 set maximum open files to 18446744073709551615: success
11-Apr-2022 08:39:51.004 looking for GeoIP2 databases in '/usr/share/GeoIP'
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoIP2-Country.mmdb' (status 1)
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoLite2-Country.mmdb' (status 1)
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoIP2-City.mmdb' (status 1)
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoLite2-City.mmdb' (status 1)
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoIP2-ASN.mmdb' (status 1)
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoLite2-ASN.mmdb' (status 1)
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoIP2-ISP.mmdb' (status 1)
11-Apr-2022 08:39:51.004 unable to open GeoIP2 database '/usr/share/GeoIP/GeoIP2-Domain.mmdb' (status 1)
11-Apr-2022 08:39:51.004 using default UDP/IPv4 port range: [32768, 60999]
11-Apr-2022 08:39:51.004 using default UDP/IPv6 port range: [32768, 60999]
```
Happened a day before in the [2439503](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2439503) job, again `doth` system test.
Note that this job employs 32-bit BIND with 32-bit dependencies on otherwise 64-bit system.
[core.1600-backtrace.txt](/uploads/b99233defa71f1ab35bdc5c021447cc4/core.1600-backtrace.txt)June 2022 (9.16.30, 9.16.30-S1, 9.18.4, 9.19.2)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3285dig hangs when there is a TLS context creation failure2022-04-27T14:02:09ZArаm Sаrgsyаndig hangs when there is a TLS context creation failureFor testing, you can simulate an error by providing TLS certificate file without a key. This will hang in `main` until interrupted:
```
bin/dig/dig +tcp +tls +tls-certfile=/dev/null localhost
;; both TLS client certificate and key file ...For testing, you can simulate an error by providing TLS certificate file without a key. This will hang in `main` until interrupted:
```
bin/dig/dig +tcp +tls +tls-certfile=/dev/null localhost
;; both TLS client certificate and key file must be specified a the same time
^C
```
There seems to be a missing detachment of the `connectquery` in dighost.c:start_tcp() when `get_create_tls_context()` call fails.
Assigning to @artem by his request.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3415"rndc reconfig" does not reload http statements2024-01-11T14:13:02ZThomas Beati"rndc reconfig" does not reload http statements### Summary
When we add an endpoint in an http statement in named.conf and run ```rndc reconfig```, the new endpoint is not effective. \
Bind needs to be restarted for the endpoint to be effective. \
The reconfig was working in 9.18.2.
...### Summary
When we add an endpoint in an http statement in named.conf and run ```rndc reconfig```, the new endpoint is not effective. \
Bind needs to be restarted for the endpoint to be effective. \
The reconfig was working in 9.18.2.
### BIND version used
Bug introduced in 9.18.3
BIND 9.18.3 (Stable Release) <id:16aefa3>
### Steps to reproduce
1) Bind is started as an http server:
```
http local-http-server {
endpoints {
"/endpoint1/dns-query";
};
};
option {
...
listen-on port 8443 tls tls_conf http local-http-server {any;};
...
}
```
2) Add an endpoint in named.conf :
```
http local-http-server {
endpoints {
"/endpoint1/dns-query";
"/endpoint2/dns-query";
};
};
```
3) Run ```rndc reconfig```
### What is the current *bug* behavior ?
Configuration is not reloaded, the new endpoint responds with 404 error.
### What is the expected *correct* behavior?
Configuration is reloaded, the new endpoint responds to dns queries.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3504Unable to specify only TLSv1.3 ciphersuites in named.conf2024-03-08T05:16:39ZManuel StausbergUnable to specify only TLSv1.3 ciphersuites in named.conf### Summary
We recently played around with XoT and discovered that we were unable to configure *only* TLSv1.3 ciphersuites in the `tls` section of `named.conf`, even though we specified TLSv1.3 as the only protocol.
This is rather low ...### Summary
We recently played around with XoT and discovered that we were unable to configure *only* TLSv1.3 ciphersuites in the `tls` section of `named.conf`, even though we specified TLSv1.3 as the only protocol.
This is rather low priority (since to my knowledge all of the TLSv1.3 ciphersuites are considered secure for the time being), but it is at least unexpected behaviour.
### BIND version used
```txt
BIND 9.18.6 (Stable Release) <id:8dbd488>
running on Linux x86_64 3.10.0-1160.71.1.el7.x86_64 #1 SMP Tue Jun 28 15:37:28 UTC 2022
built by make with '--prefix=/usr/local/denic-bind918-9.18.6' '--exec-prefix=/usr/local/denic-bind918-9.18.6' '--bindir=/usr/local/denic-bind918-9.18.6/bin' '--sbindir=/usr/local/denic-bind918-9.18.6/bin' '--libexecdir=/usr/local/denic-bind918-9.18.6/lib' '--localstatedir=/var' '--without-libxml2' '--enable-full-report' '--with-tuning=large' '--disable-doh' '--disable-geoip' '--disable-auto-validation' '--with-openssl=/usr' 'LIBUV_CFLAGS= ' 'LIBUV_LIBS=-luv -ldl ' 'OPENSSL_CFLAGS=-I/usr/include/openssl11' 'OPENSSL_LIBS=-L/usr/lib64/openssl11 -lssl -lcrypto'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
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: /usr/local/denic-bind918-9.18.6/etc/named.conf
rndc configuration: /usr/local/denic-bind918-9.18.6/etc/rndc.conf
DNSSEC root key: /usr/local/denic-bind918-9.18.6/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
```
### Steps to reproduce
try to start `named` with a `named.conf` containing only TLSv1.3 ciphersuites in a `tls` block's `cipher` key.
### What is the current *bug* behavior?
`named` does not start because the `named.conf` validation fails ("'ciphers' in the 'tls' clause 'tlsclients' is not a valid cipher list string")
### What is the expected *correct* behavior?
`named` sets the specified TLSv1.3 ciphersuites and starts.
### Relevant configuration files
Using the following `tls` block in named.conf will trigger the observed behaviour:
```txt
tls tlsclients {
key-file "/path/to/key";
cert-file "/path/to/cert";
protocols { TLSv1.3; };
ciphers "TLS_AES_256_GCM_SHA384";
dhparam-file "/path/to/dhparam";
prefer-server-ciphers yes;
session-tickets no;
};
# same with ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
```
If we append some ciphers (TLSv1.2-Style), the check succeeds and `named` starts:
```
tls tlsclients {
key-file "/path/to/key";
cert-file "/path/to/cert";
protocols { TLSv1.3; };
ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
dhparam-file "/path/to/dhparam";
prefer-server-ciphers yes;
session-tickets no;
};
```
(Realized that the dhparam-file is not needed if we use TLSv1.3 only, but leaving it in here in case it might be relevant to the observed behaviour)
### Possible fixes
We suspect that this is due to the use of [`SSL_CTX_set_cipher_list()`](https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_18/lib/isc/tls.c#L706) in the validation function [`isc_tls_cipherlist_valid()`](https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_18/lib/isc/tls.c#L687) - according to the [OpenSSL manpages](https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_cipher_list.html), this function can only set the ciphers for TLSv1.2 and below, whereas `SSL_CTX_set_ciphersuites()` can be used to set ciphersuites for TLSv1.3.
Maybe we can pass the cipher string to both Functions and return `true` if either of them returns `1`?March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3596"doth" system test fails intermittently with "The single DIG instance has sto...2022-12-12T15:49:55ZMichał Kępień"doth" system test fails intermittently with "The single DIG instance has stopped prematurely"Sample failure: https://gitlab.isc.org/isc-private/bind9/-/jobs/2819987
```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (170)
Traceback (most recent call last):
File "/builds/isc-private/bind9/bin/tests/syste...Sample failure: https://gitlab.isc.org/isc-private/bind9/-/jobs/2819987
```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (170)
Traceback (most recent call last):
File "/builds/isc-private/bind9/bin/tests/system/doth/stress_http_quota.py", line 252, in <module>
sys.exit(main())
File "/builds/isc-private/bind9/bin/tests/system/doth/stress_http_quota.py", line 244, in main
run_test(http_secure=True)
File "/builds/isc-private/bind9/bin/tests/system/doth/stress_http_quota.py", line 225, in run_test
assert (
AssertionError: The single DIG instance has stopped prematurely
I:doth:failed
```
Just in the public BIND 9 project in the past 6 days, this failure mode
has been triggered **over 50 times**.
Except for [two][1] [outliers][2], it always happened in system test jobs
with either ASAN or TSAN enabled and, AFAICT, only for MRs targeting the
`main` branch, so this might be related to !6040 (see also #3595).
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2811437
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2813094November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3606Ensure atomicity/synchronisation in isc_nmsocket_shutdown() for multi-layer t...2022-10-26T07:54:37ZArtem BoldarievEnsure atomicity/synchronisation in isc_nmsocket_shutdown() for multi-layer transports (HTTP/2 and Generic TLS code).The current implementation of `isc_nmsocket_shutdown()` for HTTP/2 and generic TLS transport does not explicitly guarantee that clean shutdown is performed and no new associated connections will be accepted after the call of `isc_nmsocke...The current implementation of `isc_nmsocket_shutdown()` for HTTP/2 and generic TLS transport does not explicitly guarantee that clean shutdown is performed and no new associated connections will be accepted after the call of `isc_nmsocket_shutdown()` has been completed, and its associated data is safe to destroy. That could lead to potential issues on a BIND shutdown as well as unit tests for "multilayer" transports.
To fix that, we can do the following:
1. Mark the listening socket as being shutting down so that the associated connections being accepted at the moment might notice that we are wrapping up and handle the situation accordingly;
2. Broadcast a "stop" message on all worker threads and wait for them to be processed. Then, the underlying listening socket can be safely shot down too. Something very similar is being done in other transports implemented directly on top of libUV - but there is a separate "child" socket object associated with any worker. For "multilayer" transports, we can do simpler than that, as there is no direct need to maintain a per-worker object.November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3610bind 9.18.5 doh stop service: general: info: Accepting TCP connection failed:...2023-05-04T03:39:37Zshipei.xubind 9.18.5 doh stop service: general: info: Accepting TCP connection failed: quota reached
### Summary
When running for more than a month, the service suddenly stopped
There are a lot of following errors
```
16-Oct-2022 05:29:48.090 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:30:03.814 genera...
### Summary
When running for more than a month, the service suddenly stopped
There are a lot of following errors
```
16-Oct-2022 05:29:48.090 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:30:03.814 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:30:30.818 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:30:40.826 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:30:42.298 lame-servers: info: timed out resolving 'inforec-img.nos-eastchina1.126.net/A/IN': 59.37.133.11#5533
16-Oct-2022 05:30:44.902 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:32:52.990 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:32:53.442 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:32:57.986 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:33:03.266 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:33:27.742 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:33:58.866 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:34:08.878 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:34:27.210 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:34:37.222 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:34:47.218 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:34:48.510 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:35:03.218 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:35:08.442 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:35:38.642 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:35:40.498 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:35:46.622 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:36:28.166 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:36:40.550 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 05:36:54.950 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:26:06.354 general: info: Accepting TCP connection failed: socket is not connected
16-Oct-2022 10:26:17.538 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:26:18.206 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:26:23.090 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:26:28.090 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:26:31.062 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:26:56.790 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:27:45.890 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:27:58.690 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:28:29.074 general: info: Accepting TCP connection failed: quota reached
16-Oct-2022 10:28:30.934 general: info: Accepting TCP connection failed: quota reached
```
### BIND version used
```
BIND 9.18.5 (Stable Release) <id:>
running on Linux x86_64 5.10.130-118.517.amzn2.x86_64 #1 SMP Wed Jul 13 16:51:52 UTC 2022
built by make with '--enable-dnstap' '--enable-epoll' '--with-json-c' '--with-libnghttp2' '--enable-doh' '--prefix=/data/named' 'PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig'
compiled by GCC 7.3.1 20180712 (Red Hat 7.3.1-15)
compiled with OpenSSL version: OpenSSL 1.1.1q 5 Jul 2022
linked to OpenSSL version: OpenSSL 1.1.1q 5 Jul 2022
compiled with libuv version: 1.39.0
linked to libuv version: 1.39.0
compiled with libnghttp2 version: 1.41.0
linked to libnghttp2 version: 1.41.0
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.0.2
linked to protobuf-c version: 1.0.2
threads support is enabled
default paths:
named configuration: /data/named/etc/named.conf
rndc configuration: /data/named/etc/rndc.conf
DNSSEC root key: /data/named/etc/bind.keys
nsupdate session key: /data/named/var/run/named/session.key
named PID file: /data/named/var/run/named/named.pid
named lock file: /data/named/var/run/named/named.lock
```
### Steps to reproduce
run for a month!
### What is the current *bug* behavior?
stopped for service. Doh requests no longer respond
### What is the expected *correct* behavior?
run smoothly
### Relevant configuration files
```
tls test-tls {
key-file "/ssl_cert/star_net.key";
cert-file "/ssl_cert/star_net.pem";
dhparam-file "/ssl_cert/dhparam.pem";
ciphers "HIGH:!kRSA:!aNULL:!eNULL:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SHA1:!SHA256:!SHA384";
prefer-server-ciphers yes;
session-tickets no;
};
http local {
endpoints { "/dns-query"; };
};
options {
#listen-on port 53 { any; };
listen-on tls test-tls http local { any; };
listen-on-v6 { none; };
directory "/var/named/";
dump-file "/var/named/data/cache_dump.db";
session-keyfile "/var/named/run/session.key";
bindkeys-file "/etc/bind.keys";
key-directory "/etc";
version none;
notify no;
servfail-ttl 30;
allow-query { any; };
allow-query-cache { any; };
forward first;
hostname none;
max-cache-size 12g;
recursion yes;
querylog no;
clients-per-query 400;
max-clients-per-query 2000;
};
```
### Relevant logs and/or screenshots
### Possible fixeshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3725TLS session resumption via session IDs leads to handshake errors when Mutual ...2023-01-03T08:58:48ZOndřej SurýTLS session resumption via session IDs leads to handshake errors when Mutual TLS (client certificate) is used~~When reusing the TLS context to the same endpoint, the previous connection has to be finished otherwise, the following error happens:~~
```
TLS error in tls_cycle_input: error:0A000115:SSL routines::session id context uninitialized
``...~~When reusing the TLS context to the same endpoint, the previous connection has to be finished otherwise, the following error happens:~~
```
TLS error in tls_cycle_input: error:0A000115:SSL routines::session id context uninitialized
```
~~This happens f.e. in the new dispatch where there's a little delay between tearing down the whole TLSDNS connection and starting up the new one.~~
After the investigation is turned out that in order to make TLS session resumption via session IDs work, we need to use `SSL[_CTX]_set_session_id_context()` function to initialise the session identifier within a server TLS context, otherwise we will get the error above.
*(excerpt from the `SSL[_CTX]_set_session_id_context()` documentation)*
> WARNINGS
> If the session id context is not set on an SSL/TLS server and client certificates are used, stored sessions will not be reused but a fatal error will be flagged and the handshake will fail.
As @aram found, there is a specialised check within OpenSSL specifically for that case:
```
if ((s->verify_mode & SSL_VERIFY_PEER) && s->sid_ctx_length == 0) {
/*
* We can't be sure if this session is being used out of context,
* which is especially important for SSL_VERIFY_PEER. The application
* should have used SSL[_CTX]_set_session_id_context. For this error
* case, we generate an error instead of treating the event like a
* cache miss (otherwise it would be easy for applications to
* effectively disable the session cache by accident without anyone
* noticing).
*/
SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_SSL_GET_PREV_SESSION,
SSL_R_SESSION_ID_CONTEXT_UNINITIALIZED);
fatal = 1;
goto err;
}
```
Unfortunately, we have not been doing that. So, the first resumption attempt after a successful connection in case of Mutual TLS (when client certificates are used) will always fail.
So, the problem was not in the TLS context reuse per se, which is the only way to make TLS session resumption work, but in incomplete server TLS context initialisation procedure for that case.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4528rndc reconfig/reload ignores changes to listen-on statements when port or int...2024-03-11T14:38:57ZArtem Boldarievrndc reconfig/reload ignores changes to listen-on statements when port or interface address are left unchangedOne could change `listen-on` statements to change DNS transports without changing both port and interface addresses. For example, one could change a line:
```
listen-on port 1234;
```
to
```
listen-on port 1234 tls some-tls-config;
``...One could change `listen-on` statements to change DNS transports without changing both port and interface addresses. For example, one could change a line:
```
listen-on port 1234;
```
to
```
listen-on port 1234 tls some-tls-config;
```
and then run `rndc reconfig`. However, that would not work because we lack a mechanism for changing listener type. Moreover, the example above will crash BIND with abort() because the code will try to update a TLS context on a listener that does not support TLS.
The problem was found while investigating issue #4518, which can be considered a special case of this issue: it can be described as a lack of ability to update/recreate listeners on reconfiguration.
The solution is to always recreate listeners on listener type change (e.g. Do53->DoT or enabling PROXY). That partially raises the issue mentioned in #3122, but there is no way around that except for allowing any process to bind "privileged" ports on affected platforms (read: BSDs). That might bring some troubles, but:
It is a very edge case, as listener types do not change often. The fact that no one has reported the issue in at least two years or more proves that.
We have no mechanism to dynamically change layers in an active listener, and it is hard to justify adding such a complex mechanism in the critical part of the code.
**P.S.**
Historically, we would recreate listeners on reconfiguration for new transports in order to ensure that TLS certificates are reloaded, but we changed that (see #3122 and, to a lesser extent, #3415, as well as the related merge requests for additional details). That made this issue more apparent, although even back then, reconfiguration would have been broken for plain HTTP/2 listeners.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4536The new "cipher-suites" system test fails in FIPS mode2024-03-08T05:23:01ZMichał KępieńThe new "cipher-suites" system test fails in FIPS mode!8576 was merged 3 days ago and here is a list of its failures in GitLab
CI since:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938188
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938189
- https://gitlab.isc.org/isc-...!8576 was merged 3 days ago and here is a list of its failures in GitLab
CI since:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938188
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938189
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939001
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939002
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939846
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939847
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939988
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939989
These look like permanent failures; it is probably a rare case of a
FIPS-only failure that was not caught before merging since we only run
FIPS-mode jobs in scheduled pipelines rather than for every merge
request.
Looks like there is a pattern to these failures - there seem to be
different issues on different platforms:
- on Oracle Linux 9 in FIPS mode, there is often a **crash**:
```
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D cipher-suites_tmp__8wequ'.
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:Program terminated with signal SIGABRT, Aborted.
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#0 0x00007fde4caa158c in __pthread_kill_implementation () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:[Current thread is 1 (Thread 0x7fde49fba600 (LWP 103424))]
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#0 0x00007fde4caa158c in __pthread_kill_implementation () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#1 0x00007fde4ca54d06 in raise () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#2 0x00007fde4ca287f3 in abort () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#3 0x0000000000422b05 in assertion_failed (file=0x7fde4d8c26a1 "netmgr/tcp.c", line=918, type=isc_assertiontype_insist, cond=0x7fde4d8c2720 "csock->recv_cb != ((void *)0)") at main.c:234
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#4 0x00007fde4d88aace in isc_assertion_failed (file=file@entry=0x7fde4d8c26a1 "netmgr/tcp.c", line=line@entry=918, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fde4d8c2720 "csock->recv_cb != ((void *)0)") at assertions.c:48
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#5 0x00007fde4d8829e3 in accept_connection (csock=<optimized out>, csock@entry=0x7fde48c0b000) at netmgr/tcp.c:918
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#6 0x00007fde4d882c1d in tcp_connection_cb (server=<optimized out>, status=<optimized out>) at netmgr/tcp.c:558
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#7 0x00007fde4d481e77 in uv.server_io () from /lib64/libuv.so.1
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#8 0x00007fde4d49285e in uv.io_poll.part () from /lib64/libuv.so.1
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#9 0x00007fde4d47c5a8 in uv_run () from /lib64/libuv.so.1
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#10 0x00007fde4d89d896 in loop_thread (arg=arg@entry=0x7fde4bea6180) at loop.c:282
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#11 0x00007fde4d8af4b5 in thread_body (wrap=wrap@entry=0x1dc7350) at thread.c:85
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#12 0x00007fde4d8af4de in thread_run (wrap=0x1dc7350) at thread.c:100
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#13 0x00007fde4ca9f812 in start_thread () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#14 0x00007fde4ca3f450 in clone3 () from /lib64/libc.so.6
```
- on Oracle Linux 8 in FIPS mode, there is often a **test failure**:
```
2024-01-13 00:16:03 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns2" (1)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns3" (2)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns4" (3)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns2" (4)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns3" (5)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns4" (6)
2024-01-13 00:16:13 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:failed
2024-01-13 00:16:13 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns2", failure expected (7)
2024-01-13 00:16:22 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns2", failure expected (8)
2024-01-13 00:16:32 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns3", failure expected (9)
2024-01-13 00:16:41 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns3", failure expected (10)
2024-01-13 00:16:51 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns4", failure expected (11)
2024-01-13 00:17:00 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns4", failure expected (12)
2024-01-13 00:17:09 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns5", failure expected (13)
2024-01-13 00:17:19 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns5", failure expected (14)
2024-01-13 00:17:28 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns5", failure expected (15)
2024-01-13 00:17:38 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns5", failure expected (16)
2024-01-13 00:17:47 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:exit status: 1
```
I would normally follow up on the original issue in cases like this, but
it seems that at least the crash may be a pre-existing issue, so I
thought that separating it out might be prudent.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4545Flamethrower DoH queries timeout with BIND on FreeBSD2024-03-04T16:12:33ZMichal NowakFlamethrower DoH queries timeout with BIND on FreeBSDIn "stress" CI jobs, we run three types of scenarios where we send thousands of UDP and TCP queries per second to an authoritative, recursive, or recursive RPZ server. Each scenario runs on Linux amd64, Linux arm64, and FreeBSD 12.4 amd6...In "stress" CI jobs, we run three types of scenarios where we send thousands of UDP and TCP queries per second to an authoritative, recursive, or recursive RPZ server. Each scenario runs on Linux amd64, Linux arm64, and FreeBSD 12.4 amd64 platforms. For a long time, I have tried to add support for DoT and DoH, and with the adoption of AWS for CI, this is now possible.
The major problem now is that there's something wrong with BIND-Flamethrower cooperation for DoH queries on FreeBSD 12.4 for all scenarios (authoritative, recursive, and recursive with RPZ). The problem is that Flamethrower 0.12 from upstream Git `master` - run on FreeBSD in CI or Linux in my local environment - never gets answers to DoH queries from BIND on FreeBSD (DoH on BIND on Linux is fine; DoT, TCP, and UDP on FreeBSD are fine as well). 100% of queries are timeouted. During the Flamethrower runtime, in the BIND `-d 99` log, there is only a lot of lines like this: `22-Jan-2024 14:39:14.040 socket 0x8030df800: TLS server session created for 192.168.122.1#43511 on 192.168.122.73#4430`. However, the query does not seem to be processed in any way. It gets processed fine when sent by `dig +https`.
See job [#3956703](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3956703) for logs and config files.
Here's a 10-second PCAP (`tcpdump port 4430 -i vtnet0`) from my local environment: [cap.pcap](/uploads/5b4bfee595db99cb92b220ce97eff697/cap.pcap).
Flamethrower output with 100% of timeouted queries:
<details><summary>Click to expand</summary>
```
/usr/local/bin/flame --dnssec -P doh -F inet -g file -f ~/Downloads/fbsddoh/query_datafile -Q 1 -p 4430 192.168.122.73
WARNING: QPS limit is less than concurrent senders, changing limit to 30
binding traffic generators to 0.0.0.0
flaming target(s) [192.168.122.73] on port 4430 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol doh
query generator [file] contains 105000 record(s)
rate limit @ 30 QPS (1 QPS per concurrent sender)
1.1768e-05s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
1.00012s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
2.00152s: send: 30, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
3.00237s: send: 0, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
4.00255s: send: 0, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
5.00297s: send: 90, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 30
6.00343s: send: 0, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
7.00418s: send: 0, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
8.00446s: send: 90, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 90
9.00494s: send: 0, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
10.0056s: send: 0, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
11.0064s: send: 90, avg send: 75, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 90
^C11.1595s: send: 0, avg send: 75, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
stopping, waiting up to 3s for in flight to finish...
------
run id : 7ffd5c99e030
run start : 2024-01-22T16:41:23Z
runtime : 14.1608 s
total sent : 300
total rcvd : 0
min resp : 0 ms
avg resp : -nan ms
max resp : 0 ms
avg r qps : 0
avg s qps : 75
avg pkt : 35.3258 bytes
tcp conn. : 568
timeouts : 300 (100%)
bad recv : 0
net errors : 0
```
</details>
BIND config file:
<details><summary>Click to expand</summary>
```
http local {
endpoints { "/dns-query"; };
};
options {
port 5300;
listen-on port 5300 { 10.53.0.2; };
listen-on-v6 port 5300 { fd92:7065:b8e:ffff::2; };
listen-on port 8530 tls ephemeral { 10.53.0.2; }; // DoT IPv4
listen-on-v6 port 8530 tls ephemeral { fd92:7065:b8e:ffff::2; }; // DoT IPv6
listen-on port 4430 tls ephemeral http local { 10.53.0.2; }; // DoH IPv4
listen-on port 4430 tls ephemeral http local { 192.168.122.73; }; // DoH IPv4
listen-on-v6 port 4430 tls ephemeral http local { fd92:7065:b8e:ffff::2; }; // DoH IPv6
#directory "/var/tmp/gitlab_runner/builds/e-TSUMFs/0/isc-projects/bind9/output/ns2";
allow-query { any ; };
query-source address 10.53.0.2;
pid-file "named.pid";
recursion no;
tcp-clients 50;
statistics-file "named.stats";
};
statistics-channels {
inet 10.53.0.2 port 5308 allow { any; };
};
key "rndc-key" {
algorithm hmac-sha256;
secret "G+hIujn1FwNv1QgEWLrzN8ZXodAHzciE7tMSYDIiw54=";
};
controls {
inet 10.53.0.2 port 5309
allow { any; } keys { "rndc-key"; };
};
include "trusted-keys.conf";
view "default" {
zone "." {
type hint;
file "root.hint";
};
zone "test.example." in {
type master ;
file "test.example.db.signed";
};
};
logging {
channel "namedlog" {
file "named.log" versions 5 size 50M;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"namedlog";
};
};
```
</details>
The `query_datafile` file is in the CI job artifact.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldariev