BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-01-26T11:33:40Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2504System-wide libtool is required even when building from a tarball produced by...2022-01-26T11:33:40ZMichał KępieńSystem-wide libtool is required even when building from a tarball produced by "make dist"Reported by a customer: https://support.isc.org/Ticket/Display.html?id=17785
The problem is caused by a mistake in `configure.ac` which was
inadvertently introduced by !3742. We did not catch this in our own
testing because all OS imag...Reported by a customer: https://support.isc.org/Ticket/Display.html?id=17785
The problem is caused by a mistake in `configure.ac` which was
inadvertently introduced by !3742. We did not catch this in our own
testing because all OS images we use have the libtool package installed.
Only the development branch (9.17.3+) is affected.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2503New stale-answer-client-timeout crashes BIND 9.16 and 9.172021-03-03T09:10:55ZOndřej SurýNew stale-answer-client-timeout crashes BIND 9.16 and 9.17From [Support ticket #17781](https://support.isc.org/Ticket/Display.html?id=17781)
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f3c7bda4859 in __GI_abort () at abort.c:79
#2 0x000055cc6a31dd0...From [Support ticket #17781](https://support.isc.org/Ticket/Display.html?id=17781)
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f3c7bda4859 in __GI_abort () at abort.c:79
#2 0x000055cc6a31dd0a in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:261
#3 0x000055cc6a52ed20 in isc_assertion_failed (file=file@entry=0x55cc6a5a3863 "query.c", line=line@entry=6282, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x55cc6a5a42c0 "client->query.fetch == ((void *)0)") at assertions.c:46
#4 0x000055cc6a37ba6a in ns_query_recurse (client=0x7f3c540104c8, qtype=<optimized out>, qname=qname@entry=0x7f3c45331380, qdomain=0x7f3c453312e0, nameservers=0x7f3c45335bc8,
resuming=<optimized out>) at query.c:6258
#5 0x000055cc6a385e71 in query_delegation_recurse (qctx=0x7f3c721fa920) at query.c:8513
#6 query_delegation (qctx=qctx@entry=0x7f3c721fa920) at query.c:8459
#7 0x000055cc6a381f0e in query_gotanswer (qctx=qctx@entry=0x7f3c721fa920, res=res@entry=65565) at query.c:7220
#8 0x000055cc6a383e14 in query_lookup (qctx=qctx@entry=0x7f3c721fa920) at query.c:5925
#9 0x000055cc6a387e90 in query_lookup_staleonly (client=0x7f3c540104c8) at query.c:5956
#10 fetch_callback (task=<optimized out>, event=<optimized out>) at query.c:5995
#11 0x000055cc6a564131 in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1152
#12 run (queuep=<optimized out>) at task.c:1344
#13 0x00007f3c7bf8b609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#14 0x00007f3c7bea1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
The problem case here is that when we are handling a client request, and `stale-answer-client-timeout` is triggered, a separate stale only request is made, while the already started resolver fetch continues to wait for a response.
This is fine if there is a stale answer in cache, but if nothing is found, the stale only query will also start recursion.
Now we hit the `client->query.fetch == ((void *)0)` assertion.
Fix by disabling recursion on staleonly lookups.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2502Several TSAN issues.2021-04-09T09:37:34ZMark AndrewsSeveral TSAN issues.Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
See tsan directory for details.Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
See tsan directory for details.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2501TSAN error in mdig2021-03-04T14:06:23ZMark AndrewsTSAN error in mdigJob [#1507619](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507619) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 free <null...Job [#1507619](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507619) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 free <null>
#1 default_memfree lib/isc/mem.c:440
#2 mem_put lib/isc/mem.c:363
#3 isc__mem_free lib/isc/mem.c:1012
#4 main bin/tools/mdig.c:2231
Previous read of size 1 at 0x000000000005 by thread T1:
#0 dns_name_fromtext lib/dns/name.c:1121
#1 sendquery bin/tools/mdig.c:596
#2 sendqueries bin/tools/mdig.c:779
#3 dispatch lib/isc/task.c:1152
#4 run lib/isc/task.c:1344
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 main bin/tools/mdig.c:2148
SUMMARY: ThreadSanitizer: data race in __interceptor_free
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2500dnssec-policy checkds does not seem to work2021-02-22T10:52:35ZMarc Dequènes (Duck)dnssec-policy checkds does not seem to workThis is a follow-up on #2488 but for a different problem.
Key 5022 is now published:
```
# rndc dnssec -status _kage.hq.duckcorp.org
dnssec-policy: generated
current time: Thu Feb 18 18:24:02 2021
key: 43281 (RSASHA512), KSK
publish...This is a follow-up on #2488 but for a different problem.
Key 5022 is now published:
```
# rndc dnssec -status _kage.hq.duckcorp.org
dnssec-policy: generated
current time: Thu Feb 18 18:24:02 2021
key: 43281 (RSASHA512), KSK
published: yes - since Fri Aug 28 00:31:44 2020
key signing: yes - since Fri Aug 28 00:31:44 2020
Rollover is due since Fri Feb 12 00:26:50 2021
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- key rrsig: omnipresent
key: 20426 (RSASHA512), ZSK
published: yes - since Sat Nov 21 00:31:44 2020
zone signing: yes - since Mon Dec 21 00:31:44 2020
Next rollover scheduled on Sat Mar 20 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
key: 5022 (RSASHA512), KSK
published: yes - since Tue Feb 16 01:47:35 2021
key signing: yes - since Tue Feb 16 01:47:35 2021
Next rollover scheduled on Wed Feb 16 01:47:35 2022
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- key rrsig: omnipresent
```
I used `rndc dnssec -checkds -key 5022 published _kage.hq.duckcorp.org` yesterday right after replying to #2488 but his did not produce anything in the logs and the status is the same. The output (forgot to keep it so doing it again): `KSK 5022: Marked DS as published since 18-Feb-2021 19:48:06.000`. And I can confirm the is nothing in the logs except `received control channel command`.
I just used `rndc loadkeys _kage.hq.duckcorp.org` as suggested in #2488, so let's see if that's a similar problem.
\\_o<https://gitlab.isc.org/isc-projects/bind9/-/issues/2499A LOC record with a invalid direction field triggers an INSIST2021-03-08T12:07:03ZMark AndrewsA LOC record with a invalid direction field triggers an INSISTMarch 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2498Regression in BIND 9.16.10, DNSSEC fails due to improper NSEC3 creation witih...2021-03-29T07:12:15ZKris KarasRegression in BIND 9.16.10, DNSSEC fails due to improper NSEC3 creation witihin named### Summary
I could not renew LetsEncrypt certs due to what it reported as a *SERVFAIL on CAA*. Turns out that's a red herring; the actual error was a failure with DNSSEC, in particular the NSEC3 proving that no CAA exists was in error...### Summary
I could not renew LetsEncrypt certs due to what it reported as a *SERVFAIL on CAA*. Turns out that's a red herring; the actual error was a failure with DNSSEC, in particular the NSEC3 proving that no CAA exists was in error, causing Unbound to report:
* validate(nodata): **sec_status_bogus**
Debugging with *wireshark* showed nothing unusual. On a whim, I reverted from BIND 9.16.11 to 9.16.9, which is the version I was running the last time that LetsEncrypt renewal worked. **Success!** A check with [unboundtest.com](https://unboundtest.com) showed no errors, and LetsEncrypt worked fine.
Next, I installed BIND 9.16.10, and that failed. So the bug is a regression of some sort introduced sometime between 9.16.9 and 9.16.10. I could *git bisect*, but as this is my production system, I'm hoping somebody here at ISC might have a better idea of what to test, or how to test off-line.
There is more written about it here:
* https://community.letsencrypt.org/t/bind-regression-in-9-16-10-triggers-servfail-on-caa/145482
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 5.10.16 #1 SMP Sun Feb 14 18:52:33 EST 2021
built by make with '--build=x86_64-slackware-linux-gnu' '--docdir=/usr/doc/bind-9.16.11' '--sysconfdir=/etc/bind' '--infodir=/usr/info' '--libdir=/usr/lib64' '--mandir=/usr/man' '--prefix=/usr' '--localstatedir=/var' '--enable-largefile' '--with-libtool' '--enable-shared' '--with-gssapi=/usr' '--with-libidn2' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--enable-auto-validation' '--enable-dnsrps' '--enable-full-report' '--enable-fixed-rrset' '--enable-querytrace' '--with-python=/usr/bin/python3' '--with-openssl' 'build_alias=x86_64-slackware-linux-gnu' 'CFLAGS=-g -O2 -fPIC -march=opteron' 'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.2.0
compiled with OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
- Create a simple *example.com* zone with some name servers, a content server, CNAME aliases for www.example.com, ftp.example.com and so forth pointing to content-server.example.com
- Set up BIND with *dnssec-validation: auto*, and give it a generic/default policy.
```
dnssec-policy "example" {
keys {
ksk key-directory lifetime unlimited algorithm ecdsa256;
zsk key-directory lifetime P90D algorithm ecdsa256;
};
};
```
- Add a ZSK and KSK to your named.conf for BIND to use in signing the zone. Publish the DS to the parent zone/registrar to allow the zone to be validated by public tools.
- To the example.com.zone file, add a line to instruct BIND to create and maintain NSEC3 records.
```
example.com. IN NSEC3PARAM 1 0 15 fedcba9876543210
```
- Start bind, and allow it to create the DNSSEC RRSIGs and other records.
- Analyze the result using an external tool, such as dnsvis:
https://dnsviz.net/d/example.com/dnssec/
- Or, you can analyze it locally:
- dig example.com axfr | grep -v TSIG > example.com.signed.zone
- dnssec-verify -o example.com example.com.signed.zone
```
Loading zone 'example.com' from file 'example.com.signed.zone'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
No correct ECDSAP256SHA256 signature for T6FO800JTQPO6ARFM1A2U9RNPG2PBQFR.example.com NSEC3
The zone is not fully signed for the following algorithms: ECDSAP256SHA256.
DNSSEC completeness test failed.
```
- rndc zonestatus example.com IN external
```
name: example.com
type: master
files: external/example.com.zone
serial: 2021021708
nodes: 14
last loaded: Wed, 17 Feb 2021 08:35:10 GMT
secure: yes
inline signing: no
key maintenance: automatic
next key event: Sat, 20 Feb 2021 20:59:19 GMT
next resign node: U5OQPCDUCDD204VCT9H7GM8K3G8U8205.example.com/NSEC3
next resign time: Thu, 18 Feb 2021 20:17:17 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```
### What is the current *bug* behavior?
According to dnsviz.net, the NSEC3 records are not properly populated to prove a zone node does not exist. Some of the RRSIG/DNSKEY records also appear to be improper, as LetsEncrypt (which uses Unbound) cannot validate some records that **do** exist, such as the *TXT* of the *_acme_challenge* it uses.
[**Update**] It appears that even in BIND 9.16.9, there is still a bug in that NSEC3 records are only partially populated. According to **dnsviz.net**, checking for *example.com* succeeds, but checking for *doesnotexist.example.com* may or may not show DNSSEC validation errors. But of course, in BIND 9.16.10 and 9.16.11, even the check of the existing example.com results in red portions of the graph it presents.
### What is the expected *correct* behavior?
BIND should properly maintain its NSEC3 and related DNSSEC records so that validation tools show no errors.
### Relevant configuration files
I think the snippets I included in the *Steps to Reproduce* section, above, should be sufficient. I am not doing anything unusual here, to the best of my knowledge; I'm using a dnssec-policy that's essentially the built-in default, except for elliptic-curve encryption types. Keys are all *Algorithm 13*.
### Relevant logs and/or screenshots
When running BIND 9.16.10, I see the following which is *not* present running 9.16.9 and below:
```
dnssec: warning: client @0x7fffb001a5a8 66.133.109.36#47330 (nS3.eXamPle.com): view external: expected a exact match NSEC3, got a covering record
dnssec: warning: client @0x7fffc000cec8 66.133.109.36#11834 (FTp.EXaMplE.COM): view external: expected a exact match NSEC3, got a covering record
```
### Possible fixes
I have not *yet* done a **git bisect**, and hope not to do it as my means of testing (running LetsEncrypt to generate certificates) requires this to be my live, production site. But bisecting is possible if the devos cannot guess what might be the issue.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/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/2493CID 281450: Dereference before null check (REVERSE_INULL)2021-09-02T11:46:51ZMark AndrewsCID 281450: Dereference before null check (REVERSE_INULL)test-async.c
```
162cleanup:
CID 281450 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking inst suggests that it may be null, but it has already been dereferenced on all paths leading to the c...test-async.c
```
162cleanup:
CID 281450 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking inst suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
163 if (result != ISC_R_SUCCESS && inst != NULL) {
164 plugin_destroy((void **)&inst);
165 }
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2492CID 304936: Dereference before null check2021-03-02T14:31:14ZMark AndrewsCID 304936: Dereference before null checkcontrolconf.c
```
1191cleanup:
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null, but it has already been dereferenced on all paths leading t...controlconf.c
```
1191cleanup:
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1192 if (listener != NULL) {
1193 isc_refcount_decrement(&listener->refs);
1194 listener->exiting = true;
1195 free_listener(listener);
1196 }
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2488Update key refresh timer after 'rndc dnssec -rollover'2022-03-14T09:47:54ZMarc Dequènes (Duck)Update key refresh timer after 'rndc dnssec -rollover'### Summary
`rndc dnssec -rollover` does not trigger a KSK rollover as expected.
### BIND version used
```
BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
...### Summary
`rndc dnssec -rollover` does not trigger a KSK rollover as expected.
### BIND version used
```
BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-Pv1hAF/bind9-9.16.8=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libuv version: 1.24.1
linked to libuv version: 1.24.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
* on a domain with one single KSK currently in use and working properly as reported by dnsviz
* rndc dnssec -rollover -key <ksk-id> <domain>
### What is the current *bug* behavior?
Status before:
```dnssec-policy: generated
current time: Wed Feb 10 20:16:26 2021
key: 43281 (RSASHA512), KSK
published: yes - since Fri Aug 28 00:31:44 2020
key signing: yes - since Fri Aug 28 00:31:44 2020
Next rollover scheduled on Sun Sep 26 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 20426 (RSASHA512), ZSK
published: yes - since Sat Nov 21 00:31:44 2020
zone signing: yes - since Mon Dec 21 00:31:44 2020
Next rollover scheduled on Sat Mar 20 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
```
Status after:
```
dnssec-policy: generated
current time: Thu Feb 11 16:03:34 2021
key: 43281 (RSASHA512), KSK
published: yes - since Fri Aug 28 00:31:44 2020
key signing: yes - since Fri Aug 28 00:31:44 2020
Next rollover scheduled on Wed Feb 10 20:21:50 2021
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 20426 (RSASHA512), ZSK
published: yes - since Sat Nov 21 00:31:44 2020
zone signing: yes - since Mon Dec 21 00:31:44 2020
Next rollover scheduled on Sat Mar 20 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
```
Except for the rollover date, which is now in the past, *nothing* happened.
### What is the expected *correct* behavior?
I was expecting:
* the key to have a new goal state (there is no doc on the possible states, so I don't know which one would be appropriate)
* a new KSK to be automatically generated as per the policy
* the new key to be introduced so that I can mark it as seen when published (with `rndc dnssec -checkds` IIUC)
* and the rest of the rollover steps to follow
Since I asked for a forced rollover and the time when not set is *now* according to the doc (the scheduled time matches, so that's fine), then I would expect things to be set in motion very quickly. I did not try to restart to do anything that might supposedly trigger the scheduler but it should not be necessary. I'm also not expecting to have to create a new key by myself, as I think it's the policy's responsibility to create keys with the proper parameters.
### Relevant configuration files
The policy:
```
dnssec-policy "generated" {
keys {
ksk key-directory lifetime P1Y algorithm rsasha512 4096;
zsk key-directory lifetime 30d algorithm rsasha512 2048;
};
max-zone-ttl PT1H;
};
```
The zone config:
```
zone "_kage.hq.duckcorp.org" IN {
type master;
allow-transfer { key duckcorp-internal; };
update-policy { grant duckcorp-le-Elwing name _acme-challenge.smtp._kage.hq.duckcorp.org TXT; grant duckcorp-le-Elwing name _25._tcp.smtp._kage.hq.duckcorp.org TLSA; };
file "/var/cache/bind/masters/_kage.hq.duckcorp.org.zone";
dnssec-policy "generated";
};
```
### Possible fixes
Maybe this command is not doing what I expect but since there is no documentation about procedures with the new dnssec-policy system and it seems almost noone is writing on it on the Internet I'm at a loss to understand what to do.
Btw I was thinking about doing an algo rollover in the future, and I was wondering if simply changing the policy would automagically do the required steps the next time a key is replaced (or when you force a rollover).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)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2487BIND 9.16.11 fails to return large response with libuv error2021-06-09T15:28:32ZAnand BuddhdevBIND 9.16.11 fails to return large response with libuv error### Summary
Queries that are supposed to elicit large responses, and cause a server to return a response with the TC bit set get no response at all.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux...### Summary
Queries that are supposed to elicit large responses, and cause a server to return a response with the TC bit set get no response at all.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/named' '--disable-static' '--with-pic' '--without-python' '--with-libtool' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Configure a name in a zone with a very large TXT record of say 1500 bytes. Load this zone into BIND 9.16.11, and then query the server.
### What is the current *bug* behavior?
The server does not send a response to the query.
### What is the expected *correct* behavior?
The server should return a response with the TC bit set.
### Relevant configuration files
A TXT record in a zone like this can trigger this bug:
```
1500.4.dns.nl-ams-as3333-4.anchors.atlas.ripe.net. IN TXT "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
```
### Relevant logs and/or screenshots
When the server receives such a query, it logs this in the BIND log file:
```
10-Feb-2021 18:22:09.860 general: unable to convert libuv error code in udp_send_cb to isc_result: -90: message too long
```
### Possible fixes
Don't know.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2486dnssec-verify should be able to read journal files2022-02-25T14:21:36ZMark Andrewsdnssec-verify should be able to read journal filesWhen dnssec-verify is applied to zone files generated by `named` it may need to read the journal to get a complete picture of the zone's contents.When dnssec-verify is applied to zone files generated by `named` it may need to read the journal to get a complete picture of the zone's contents.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2484Add nghttp2 version to "named -V" output2021-02-16T22:45:54ZMichał KępieńAdd nghttp2 version to "named -V" outputSince BIND 9 is now requires nghttp2 for DNS-over-HTTPS (DoH) support,
`named -V` output should include:
- the nghttp2 version that `named` was built against,
- the nghttp2 version that `named` is linked to,
for consistency with th...Since BIND 9 is now requires nghttp2 for DNS-over-HTTPS (DoH) support,
`named -V` output should include:
- the nghttp2 version that `named` was built against,
- the nghttp2 version that `named` is linked to,
for consistency with the other libraries used.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2483DoH could leak memory in connect2024-03-01T10:04:57ZOndřej SurýDoH could leak memory in connect```
Dump of all outstanding memory allocations:
ptr 0x8062dcad0 size 40 file ./../netmgr/http.c line 1019
ptr 0x8019fba00 size 8 file ./../netmgr/http.c line 1190
ptr 0x8019fe800 size 40 file ./../netmgr/http.c li...```
Dump of all outstanding memory allocations:
ptr 0x8062dcad0 size 40 file ./../netmgr/http.c line 1019
ptr 0x8019fba00 size 8 file ./../netmgr/http.c line 1190
ptr 0x8019fe800 size 40 file ./../netmgr/http.c line 1019
ptr 0x8051bb380 size 32 file ./../netmgr/http.c line 1193
ptr 0x8052dce10 size 40 file ./../netmgr/http.c line 1019
ptr 0x8019fe9e8 size 37 file ./../netmgr/http.c line 1021
ptr 0x808858d20 size 32 file ./../netmgr/http.c line 1193
ptr 0x8052dce78 size 37 file ./../netmgr/http.c line 1021
ptr 0x8060b60c0 size 32 file ./../netmgr/http.c line 1193
ptr 0x8019fb820 size 8 file ./../netmgr/http.c line 1190
ptr 0x8019fb5b0 size 8 file ./../netmgr/http.c line 1190
ptr 0x8062dcb38 size 37 file ./../netmgr/http.c line 1021
```
This happens mainly on FreeBSD 12.2, but generally speaking, it looks like those are all data passed to async functions and the data are freed in the callbacks. But this is not the case here, FreeBSD has a different scheduling, so it might have revealed something not present on Linux.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2482compiling - bind-9.17.9/lib/isccfg - use of undeclared identifier 'DNS_R_NSEC...2021-02-07T17:27:56ZRyan Dudacompiling - bind-9.17.9/lib/isccfg - use of undeclared identifier 'DNS_R_NSEC3BADALG' - FreeBSD 12.2-RELEASE-p3[bind.txt](/uploads/b2d6f84b888da937163a027efcc21d46/bind.txt)[bind.txt](/uploads/b2d6f84b888da937163a027efcc21d46/bind.txt)https://gitlab.isc.org/isc-projects/bind9/-/issues/2481Forward only zones should forward queries regardless of RD flag.2022-01-19T18:47:57ZMaxim FortunForward only zones should forward queries regardless of RD flag.### Summary
When a query does not have an _RD_ flag set and a zone is configured as a _forward only_ the query does not get `recursed` and thus does not get an answer.
In my understanding _forward_ zones are not real zones, and forwardi...### Summary
When a query does not have an _RD_ flag set and a zone is configured as a _forward only_ the query does not get `recursed` and thus does not get an answer.
In my understanding _forward_ zones are not real zones, and forwarding is not really a recursion.
Not in a DNS sense anyway.
Forward zones function more in a way of a reverse proxy to an actual server and as such should always recurse
and let the downstream servers handle the query as is. That includes an _RD_ flag.
In addition, since a _forward_ zone is just a reverse proxy, it should return verbatim what it has received from the downstream. That includes authority section.
This is useful when there is a single public facing name server with subdomains controlled by different, not publically accessible, name servers throughout the intranet.
This can also be achieved by placing a public facing dns reverse proxy in front of intranet bind instances, but there is nothing quite like bind out there :)
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020
built by make with '--build=x86_64-alpine-linux-musl' '--host=x86_64-alpine-linux-musl' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dlopen=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-gssapi=/usr' '--with-libjson' '--with-libtool' '--with-libxml2' '--with-openssl=/usr' '--with-python=python3' '--enable-dnstap' '--enable-largefile' '--enable-linux-caps' '--enable-shared' '--enable-static' '--disable-isc-spnego' '--disable-backtrace' 'build_alias=x86_64-alpine-linux-musl' 'host_alias=x86_64-alpine-linux-musl' 'CC=gcc' 'CFLAGS=-Os -fomit-frame-pointer -D_GNU_SOURCE' 'LDFLAGS=-Wl,--as-needed' 'CPPFLAGS=-Os -fomit-frame-pointer'
compiled by GCC 10.2.1 20201203
compiled with OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
```
### Steps to reproduce
Configure 2 instances of named.
Public named with a master zone and a forward zone
```
zone "example.com" {
type master;
file "example.com";
};
zone "sub.example.com" {
type forward;
forward only;
forwarders { ip_of_private_named port 2053; };
};
```
where zone file has
```
sub.example.com NS ip_of_private_named
```
Private named with a forwarded zone
```
zone "sub.example.com" {
type master;
file "sub.example.com";
};
```
Run a recursive query against a private named and get authoritative response:
```
$ nslookup -port=2053 sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#2053
Name: sub.example.com
Address: 127.0.0.1
```
Run a query against a public named and get non-authoritative response
```
$ nslookup -port=1053 sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#1053
Non-authoritative answer:
Name: sub.example.com
Address: 127.0.0.1
```
Run a non-recursive query against a private named and get back authoritative response
```
$ nslookup -port=2053 -norecurse sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#2053
Name: sub.example.com
Address: 127.0.0.1
```
Run a non-recursive query against a public named and get back no answer:
```
$ nslookup -port=1053 -norecurse sub.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#1053
Non-authoritative answer:
*** Can't find sub.example.com: No answer
```
### What is the current *bug* behavior?
Non-recursive query against a public named returns a `No answer`
Recursive query against a public named returns `non-authoritative` response
### What is the expected *correct* behavior?
Non-recursive query against a public named should forward to the specified server and behave as if it was a recursive query.
Any query against a public named should return whatever forwared named responded with AS IS, thus maintaining authority if it was returned.
### Relevant configuration files
Attaching a tar with configurations and a run.sh to spin up public and private instances.
Replace all occurences of 192.168.2.10 with the local ip of your docker host.
Run run.sh to spin up 2 containers: bind9-public and bind9-private.
Run nslookup queries from Steps to reproduce.
### Relevant logs and/or screenshots
In Steps to reproduce
### Possible fixes
I am proposing a fix that would handle the forwarding. I am not certain how to approach the authority response yet.
https://gitlab.isc.org/maxfortun/bind9/-/blob/fix-forward-zone-recursion/lib/ns/query.c
[bind-forward-test.tar.gz](/uploads/a80b7545c0fc9b8d77fa28bd65452f78/bind-forward-test.tar.gz)https://gitlab.isc.org/isc-projects/bind9/-/issues/2480Feature request: signal to a secondary that received REFUSED on ixfr, to retr...2021-02-10T17:51:08ZCathy AlmondFeature request: signal to a secondary that received REFUSED on ixfr, to retry IXFR instead of AXFR on next attemptFrom [Support ticket #17554](https://support.isc.org/Ticket/Display.html?id=17554)
Use case as explained to Support:
> We have BIND transferring from a DNS device that occasionally, and temporarily, cannot provide an [AI]XFR.
> It sign...From [Support ticket #17554](https://support.isc.org/Ticket/Display.html?id=17554)
Use case as explained to Support:
> We have BIND transferring from a DNS device that occasionally, and temporarily, cannot provide an [AI]XFR.
> It signals this with a REFUSED rcode. Unfortunately when our BIND server receives this REFUSED response,
> the next XFR request is an AXFR. I understand that this is likely for compatibility reasons as some master
> may refuse an IXFR because it doesn't support it, but that is not the case here. Never mind the fact that
> one might hope to receive NOTIMP in such a case. I know that when IXFR is not available for journal reasons,
> the device is able to send AXFR as IXFR and BIND handles that perfectly fine, so I don't think its necessary
> to fail over to AXFR for the somewhat more common scenario where IXFR is not possible but AXFR is possible.
>
> Is there something that can be done on either end that would avoid this sub-optimal behaviour? Some ideas:
>
> a) Have BIND not fail over to AXFR after BIND receives a REFUSED rcode
> b) Have our device send some other rcode that BIND would not cause BIND to fail over to AXFR.
> In this case I would be looking for guidance on what RCODE we ask the device vendor to use instead.
I could envisage a configuration option for how many IXFR attempts there are on a hard fail (for some definition of 'hard fail' that includes REFUSED) before trying again with a request for an AXFR, default being 0 (which is what we do now).
I have no idea if there's a better way to handle b), although I suspect that simply just not responding would cause an IXFR retry wouldn't it?
====
This is a genuine operational problem, so suggestions for workarounds would also be much appreciated.https://gitlab.isc.org/isc-projects/bind9/-/issues/2479Comparison of integer expressions of different signedness in netmgr/http.c2021-03-04T10:04:33ZMichal NowakComparison of integer expressions of different signedness in netmgr/http.cWhen cross-compiling to 32-bit on Debian Buster I noticed this warning:
```
netmgr/http.c: In function 'https_readcb':
netmgr/http.c:707:14: warning: comparison of integer expressions of different signedness: 'ssize_t' {aka 'int'} and 'u...When cross-compiling to 32-bit on Debian Buster I noticed this warning:
```
netmgr/http.c: In function 'https_readcb':
netmgr/http.c:707:14: warning: comparison of integer expressions of different signedness: 'ssize_t' {aka 'int'} and 'unsigned int' [-Wsign-compare]
if (readlen < region->length) {
^
```
32-bit Debian sid had to be removed via 0aacabc6dc091ce3beb2d3a87d240ea7ddad8b8a.
/cc @artemMarch 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2477ERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds ...2021-03-10T11:16:57ZOndřej SurýERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds maximum supported size of 0x10000000000Something weird has happened in the doh_test when run under TSAN:
```
ERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds maximum supported size of 0x10000000000
#0 __interceptor_malloc ../../../../src/libsa...Something weird has happened in the doh_test when run under TSAN:
```
ERROR: ThreadSanitizer: requested allocation size 0xefdb1e501e16b787 exceeds maximum supported size of 0x10000000000
#0 __interceptor_malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:655 (libtsan.so.0+0x31779)
#1 <null> <null> (libnghttp2.so.14+0x793f)
#2 server_send_error_response ../netmgr/http.c:1555 (doh_test+0x9eaf)
#3 server_on_header_callback ../netmgr/http.c:1472 (doh_test+0x14601)
#4 nghttp2_session_mem_recv <null> (libnghttp2.so.14+0x11f89)
#5 tls_do_bio netmgr/tlsstream.c:204 (libisc-9.17.9.so+0x4066b)
#6 isc__nm_async_tlsdobio netmgr/tlsstream.c:927 (libisc-9.17.9.so+0x4380a)
#7 process_netievent netmgr/netmgr.c:723 (libisc-9.17.9.so+0x2d423)
#8 process_queue netmgr/netmgr.c:765 (libisc-9.17.9.so+0x2d801)
#9 process_normal_queue netmgr/netmgr.c:651 (libisc-9.17.9.so+0x2d88f)
#10 process_queues netmgr/netmgr.c:659 (libisc-9.17.9.so+0x2d8d2)
#11 async_cb netmgr/netmgr.c:617 (libisc-9.17.9.so+0x2dcf7)
#12 <null> <null> (libuv.so.1+0xed7c)
#13 __tsan_thread_start_func ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:959 (libtsan.so.0+0x2e3cf)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldariev