BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-03-04T14:06:23Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2533TSAN: pipelined:2 sanitizer report(s) found2021-03-04T14:06:23ZMatthijs Mekkingmatthijs@isc.orgTSAN: pipelined:2 sanitizer report(s) foundJob [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
===============
S:pipelined:2021-02-25T09:00:28+0000
T:pipelined:1:A
A:pipelined:System test pipelined
I:p...Job [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
===============
S:pipelined:2021-02-25T09:00:28+0000
T:pipelined:1:A
A:pipelined:System test pipelined
I:pipelined:PORTS:19342,19343,19344,19345,19346,19347,19348,19349,19350,19351,19352,19353,19354
I:pipelined:starting servers
I:pipelined:check pipelined TCP queries
I:pipelined:check pipelined TCP queries using mdig
I:pipelined:check keep-response-order
I:pipelined:check keep-response-order using mdig
I:pipelined:check mdig -4 -6
I:pipelined:check mdig -4 with an IPv6 server address
I:pipelined:exit status: 0
I:pipelined:stopping servers
I:pipelined:2 sanitizer report(s) found
R:pipelined:FAIL
E:pipelined:2021-02-25T09:00:49+0000
FAIL pipelined (exit status: 1)
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/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/2357Cannot compile current versions on macOS "Catalina"2021-03-04T12:22:26ZJP MensCannot compile current versions on macOS "Catalina"Compiling on macOS Catalina 10.15.7 is failing for current versions:
- 9.16.10
- 9.17.8
- git checkout
I believe this is _supposed_ to be possible, at least it used to be: going back to `9.11.26` shows it was: that version builds tools ...Compiling on macOS Catalina 10.15.7 is failing for current versions:
- 9.16.10
- 9.17.8
- git checkout
I believe this is _supposed_ to be possible, at least it used to be: going back to `9.11.26` shows it was: that version builds tools and _named_ (but fails at the end on tests on my machine because of missing Python2).
I've got output of `make -k` [at this gist](https://gist.github.com/jpmens/291a7a2013ed17623cc4b44e63e3dbce).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/2532TSAN: digdelv:3 sanitizer report(s) found2021-03-04T10:29:50ZMatthijs Mekkingmatthijs@isc.orgTSAN: digdelv:3 sanitizer report(s) foundS:digdelv:2021-02-18T22:30:54+0000
Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
T:digdelv:1:A
A:digdelv:System test digdelv
I:digdelv:PORTS:20841,20842...S:digdelv:2021-02-18T22:30:54+0000
Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
T:digdelv:1:A
A:digdelv:System test digdelv
I:digdelv:PORTS:20841,20842,20843,20844,20845,20846,20847,20848,20849,20850,20851,20852,20853
I:digdelv:starting servers
...
...
I:digdelv:checking mdig +multi +norrcomments works for DNSKEY (when default is rrcomments)(89)
I:digdelv:failed
I:digdelv:checking mdig +multi +norrcomments works for SOA (when default is rrcomments)(90)
I:digdelv:failed
I:digdelv:check mdig +yaml output (91)
I:digdelv:failed
...
I:digdelv:exit status: 3
I:digdelv:stopping servers
I:digdelv:3 sanitizer report(s) found
R:digdelv:FAIL
E:digdelv:2021-02-18T22:31:35+0000
FAIL digdelv (exit status: 1)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2531TSAN: rrl: 15 sanitizer report(s) found2021-03-04T10:29:39ZMatthijs Mekkingmatthijs@isc.orgTSAN: rrl: 15 sanitizer report(s) foundJob [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
=========
S:rrl:2021-02-25T08:54:57+0000
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTS:18835,18836,18837,188...Job [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
=========
S:rrl:2021-02-25T08:54:57+0000
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTS:18835,18836,18837,18838,18839,18840,18841,18842,18843,18844,18845,18846,18847
I:rrl:starting servers
I:rrl:exit status: 0
I:rrl:stopping servers
I:rrl:15 sanitizer report(s) found
R:rrl:FAIL
E:rrl:2021-02-25T08:55:24+0000
FAIL rrl (exit status: 1)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2521ThreadSanitizer: data race in memset after #24332021-03-04T10:29:23ZMichal NowakThreadSanitizer: data race in memset after #2433!4659 introduced ThreadSanitizer warnings identified by [GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507021) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507022).
GCC:
```
WARNING: ThreadSanitizer: data race ...!4659 introduced ThreadSanitizer warnings identified by [GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507021) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507022).
GCC:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 free <null>
#1 default_memfree lib/isc/mem.c:440
#2 mem_put lib/isc/mem.c:363
#3 isc__mem_free lib/isc/mem.c:1012
#4 main bin/tools/mdig.c:2231
Previous read of size 1 at 0x000000000005 by thread T1:
#0 dns_name_fromtext lib/dns/name.c:1121
#1 sendquery bin/tools/mdig.c:596
#2 sendqueries bin/tools/mdig.c:779
#3 dispatch lib/isc/task.c:1152
#4 run lib/isc/task.c:1344
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 main bin/tools/mdig.c:2148
SUMMARY: ThreadSanitizer: data race in __interceptor_free
```
Clang:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 memset <null>
#1 memset /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10
#2 mem_put lib/isc/mem.c:361:3
#3 isc__mem_free lib/isc/mem.c:1012:2
#4 main bin/tools/mdig.c:2231:3
Previous read of size 4 at 0x000000000001 by thread T1:
#0 sendquery bin/tools/mdig.c:764:10
#1 sendqueries bin/tools/mdig.c:779:3
#2 dispatch lib/isc/task.c:1152:7
#3 run lib/isc/task.c:1344:2
Location is heap block of size 1120 at 0x000000000010 allocated by main thread:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:411:8
#2 mem_get lib/isc/mem.c:343:8
#3 mem_allocateunlocked lib/isc/mem.c:918:7
#4 isc__mem_allocate lib/isc/mem.c:935:7
#5 clone_default_query bin/tools/mdig.c:1831:10
#6 parse_args bin/tools/mdig.c:1959:11
#7 parse_args bin/tools/mdig.c:2049:4
#8 main bin/tools/mdig.c:2124:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 main bin/tools/mdig.c:2148:2
SUMMARY: ThreadSanitizer: data race in memset
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2298multiple definition of `librpz_dnsrpzd_path'2021-03-04T10:29:10ZDavid Fordmultiple definition of `librpz_dnsrpzd_path'<!--
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
during compilation, a link failure is returned because of multiple definitions of the `librpz_dnsrpzd_path` symbol
### BIND version used
source of 9.14.7
### Steps to reproduce
compile with dnsrps enabled
### What is the current *bug* behavior?
```
gcc -I/tmp/bind/trunk/src/bind-9.14.7 -I../.. -I. -I../../lib/dns -Iinclude -I/tmp/bind/trunk/src/bind-9.14.7/lib/dns/include -I../../lib/dns/include -I/tmp/bind/trunk/src/bind-9.14.7/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I/usr/include -I/usr/include -DGSSAPI -DUSE_ISC_SPNEGO -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE -I/usr/include -pthread -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--export-dynamic -o libdns.la -rpath /usr/lib \
-version-info 1310:2:0 \
acl.lo adb.lo badcache.lo byaddr.lo cache.lo callbacks.lo catz.lo clientinfo.lo compress.lo db.lo dbiterator.lo dbtable.lo diff.lo dispatch.lo dlz.lo dns64.lo dnsrps.lo dnssec.lo ds.lo dyndb.lo ecs.lo fixedname.lo forward.lo ipkeylist.lo iptable.lo journal.lo keydata.lo keytable.lo lib.lo log.lo lookup.lo master.lo masterdump.lo message.lo name.lo ncache.lo nsec.lo nsec3.lo nta.lo order.lo peer.lo portlist.lo private.lo rbt.lo rbtdb.lo rcode.lo rdata.lo rdatalist.lo rdataset.lo rdatasetiter.lo rdataslab.lo request.lo resolver.lo result.lo rootns.lo rpz.lo rrl.lo rriterator.lo sdb.lo sdlz.lo soa.lo ssu.lo ssu_external.lo stats.lo tcpmsg.lo time.lo timer.lo tkey.lo tsec.lo tsig.lo ttl.lo update.lo validator.lo version.lo view.lo xfrin.lo zone.lo zonekey.lo zoneverify.lo zt.lo spnego.lo dst_api.lo dst_parse.lo dst_result.lo gssapi_link.lo gssapictx.lo hmac_link.lo openssl_link.lo openssldh_link.lo opensslecdsa_link.lo openssleddsa_link.lo opensslrsa_link.lo pkcs11rsa_link.lo pkcs11ecdsa_link.lo pkcs11eddsa_link.lo pkcs11.lo key.lo client.lo ecdb.lo geoip.lo ../../lib/isc/libisc.la -L/usr/lib -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ljson-c -llmdb -lm -lGeoIP -L/usr/lib -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl
libtool: link: gcc -shared -fPIC -DPIC .libs/acl.o .libs/adb.o .libs/badcache.o .libs/byaddr.o .libs/cache.o .libs/callbacks.o .libs/catz.o .libs/clientinfo.o .libs/compress.o .libs/db.o .libs/dbiterator.o .libs/dbtable.o .libs/diff.o .libs/dispatch.o .libs/dlz.o .libs/dns64.o .libs/dnsrps.o .libs/dnssec.o .libs/ds.o .libs/dyndb.o .libs/ecs.o .libs/fixedname.o .libs/forward.o .libs/ipkeylist.o .libs/iptable.o .libs/journal.o .libs/keydata.o .libs/keytable.o .libs/lib.o .libs/log.o .libs/lookup.o .libs/master.o .libs/masterdump.o .libs/message.o .libs/name.o .libs/ncache.o .libs/nsec.o .libs/nsec3.o .libs/nta.o .libs/order.o .libs/peer.o .libs/portlist.o .libs/private.o .libs/rbt.o .libs/rbtdb.o .libs/rcode.o .libs/rdata.o .libs/rdatalist.o .libs/rdataset.o .libs/rdatasetiter.o .libs/rdataslab.o .libs/request.o .libs/resolver.o .libs/result.o .libs/rootns.o .libs/rpz.o .libs/rrl.o .libs/rriterator.o .libs/sdb.o .libs/sdlz.o .libs/soa.o .libs/ssu.o .libs/ssu_external.o .libs/stats.o .libs/tcpmsg.o .libs/time.o .libs/timer.o .libs/tkey.o .libs/tsec.o .libs/tsig.o .libs/ttl.o .libs/update.o .libs/validator.o .libs/version.o .libs/view.o .libs/xfrin.o .libs/zone.o .libs/zonekey.o .libs/zoneverify.o .libs/zt.o .libs/spnego.o .libs/dst_api.o .libs/dst_parse.o .libs/dst_result.o .libs/gssapi_link.o .libs/gssapictx.o .libs/hmac_link.o .libs/openssl_link.o .libs/openssldh_link.o .libs/opensslecdsa_link.o .libs/openssleddsa_link.o .libs/opensslrsa_link.o .libs/pkcs11rsa_link.o .libs/pkcs11ecdsa_link.o .libs/pkcs11eddsa_link.o .libs/pkcs11.o .libs/key.o .libs/client.o .libs/ecdb.o .libs/geoip.o -Wl,-rpath -Wl,/tmp/bind/trunk/src/bind-9.14.7/lib/isc/.libs ../../lib/isc/.libs/libisc.so -L/usr/lib -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ljson-c -llmdb -lGeoIP -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl -march=x86-64 -mtune=generic -O2 -pthread -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--export-dynamic -pthread -Wl,-soname -Wl,libdns.so.1310 -o .libs/libdns.so.1310.0.2
/usr/bin/ld: .libs/rpz.o:(.bss+0x0): multiple definition of `librpz_dnsrpzd_path'; .libs/dnsrps.o:(.bss+0x80): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:580: libdns.la] Error 1
make[2]: Leaving directory '/tmp/bind/trunk/src/bind-9.14.7/lib/dns'
make[1]: *** [Makefile:84: subdirs] Error 1
make[1]: Leaving directory '/tmp/bind/trunk/src/bind-9.14.7/lib'
make: *** [Makefile:91: subdirs] Error 1
```
### What is the expected *correct* behavior?
normal compile
### Relevant configuration files
```
└─> grep -iP 'rp(s|z)' config.log config.h
config.log: $ ./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin --localstatedir=/var --disable-static --enable-fixed-rrset --enable-full-report --enable-dnsrps --with-python=/usr/bin/python --with-geoip --with-openssl --with-libidn2 --with-libjson --with-libxml2 --with-lmdb --with-libtool --with-dlz-postgres
config.log:configure:17485: checking for librpz __attribute__s
config.log:config.status:1482: creating bin/tests/system/rpz/Makefile
config.log:BIND9_CONFIGARGS='CONFIGARGS='\''--prefix=/usr'\'' '\''--sysconfdir=/etc'\'' '\''--sbindir=/usr/bin'\'' '\''--localstatedir=/var'\'' '\''--disable-static'\'' '\''--enable-fixed-rrset'\'' '\''--enable-full-report'\'' '\''--enable-dnsrps'\'' '\''--with-python=/usr/bin/python'\'' '\''--with-geoip'\'' '\''--with-openssl'\'' '\''--with-libidn2'\'' '\''--with-libjson'\'' '\''--with-libxml2'\'' '\''--with-lmdb'\'' '\''--with-libtool'\'' '\''--with-dlz-postgres'\'' '\''CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE'\'' '\''LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'\'' '\''CPPFLAGS=-D_FORTIFY_SOURCE=0'\'''
config.log:#define LIBRPZ_HAVE_ATTR 1
config.log:#define DNSRPS_LIBRPZ_PATH "librpz.so"
config.log:#define DNSRPS_LIB_OPEN 2
config.log:#define USE_DNSRPS 1
config.h:/* dnsrps $librpz_name */
config.h:#define DNSRPS_LIBRPZ_PATH "librpz.so"
config.h:/* 0=no DNSRPS 1=static link 2=dlopen() */
config.h:#define DNSRPS_LIB_OPEN 2
config.h:/* have __attribute__s used in librpz.h */
config.h:#define LIBRPZ_HAVE_ATTR 1
config.h:#define USE_DNSRPS 1
```
### Relevant logs and/or screenshots
└─> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)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/2214forward zones aren't zones and shouldn't be configured as if they were2021-03-04T10:08:09ZBrian Conryforward zones aren't zones and shouldn't be configured as if they were"zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zone..."zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zones or `rndc addzone`.
The configuration block declaring them should be renamed to `forward` or something else unambiguous.
Alternatively, all of the things that operates on zones and can't handle a forward "zone" should be fixed so that they can.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/582Feature request: allow port numbers for server-names or server-addresses2021-03-04T09:56:41ZMichael McNallyFeature request: allow port numbers for server-names or server-addressesWe received this request from a support customer:
### Request
I have a zone set up like this:
```
zone "ednstest.example.com" {
type static-stub;
server-names {
"srvr1-foo02.example.com";
"srvr2-foo02.exam...We received this request from a support customer:
### Request
I have a zone set up like this:
```
zone "ednstest.example.com" {
type static-stub;
server-names {
"srvr1-foo02.example.com";
"srvr2-foo02.example.com";
};
};
```
The owner of the zone asked me to test with his development server on port 8600, but there does not seem to be a way to specify a port number with this construction.
BIND already allows port number specifications in the "masters" and "forwarders" clauses, can it be allowed here too?
### Links / references
From support ticket https://support.isc.org/Ticket/Display.html?id=13620https://gitlab.isc.org/isc-projects/bind9/-/issues/2408kasp: Purge deleted keys2021-03-03T11:53:26ZMatthijs Mekkingmatthijs@isc.orgkasp: Purge deleted keysAdd a configuration option for `dnssec-policy` to purge deleted keys.
`purge-keys duration` will purge deleted keys after the given duration. Set to `0` to never purge deleted keys. Default 90 days.Add a configuration option for `dnssec-policy` to purge deleted keys.
`purge-keys duration` will purge deleted keys after the given duration. Set to `0` to never purge deleted keys. Default 90 days.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/2546dnssec-validation to validate own authoritative zone2021-03-03T11:41:02Zadrianknorrdnssec-validation to validate own authoritative zone### Summary
I have an authoritative nameserver that serves a zone, let's say it is authoritative for example.com.
When I query example.com at any DNSSEC validating resolver, the ad flag is set.
But, when I query example.com at my author...### Summary
I have an authoritative nameserver that serves a zone, let's say it is authoritative for example.com.
When I query example.com at any DNSSEC validating resolver, the ad flag is set.
But, when I query example.com at my authoritative nameserver, the ad flag is not set.
Is this a bug or intended behavior?
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on FreeBSD amd64 12.2-STABLE FreeBSD 12.2-STABLE r369178
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--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-native-pkcs11' '--without-python' '--disable-querytrace' '--enable-tcp-fastopen' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--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'
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.1h-freebsd 22 Sep 2020
linked to OpenSSL version: OpenSSL 1.1.1i-freebsd 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.2
linked to protobuf-c version: 1.3.2
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/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Set up authoritative nameserver with `dnssec-validation auto;` or `dnssec-validation yes;`.
Sign zone with OpenDNSSEC. Let bind read the signed zone file:
```
zone "example.com" {
type master;
file "signed/example.com";
};
```
### What is the current *bug* behavior?
Using `dig` and/or `drill` to query the local nameserver.
I also queried denic.de as a reference.
`dig @localhost denic.de`
Ad Flag is set.
`dig @localhost example.com`
Ad Flag **is not set**.
versus:
`dig @8.8.8.8 denic.de`
Ad Flag is set.
`dig @8.8.8.8 example.com`
Ad Flag **is set**.
### What is the expected *correct* behavior?
When executing `dig @localhost example.com`, the Ad Flag should be set.https://gitlab.isc.org/isc-projects/bind9/-/issues/2310BIND 9.11.25 has wrong formatted man pages2021-03-03T10:57:44ZPetr MenšíkBIND 9.11.25 has wrong formatted man pages### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps...### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps to reproduce
```
tar xzf bind-9.11.25.tar.gz
man bind-9.11.25/bin/named/named.8
```
### What is the current *bug* behavior?
```
NAMED(8) BIND9 NAMED(8)
.SH "NAME" named - Internet domain name server
.SH "SYNOPSIS"
.HP 144u
```
All generated manual pages have spaces before .SH, .PP etc. sections of man. At least man from Fedora cannot cope with it and display those sections when
### What is the expected *correct* behavior?
The same output as done on v9_11 branch
```
NAMED(8) BIND9 NAMED(8)
NAME
named - Internet domain name server
SYNOPSIS
named [[-4] | [-6]] [-c config-file] [-d debug-level] [-D string] [-E engine-name] [-f] [-g] [-L logfile] [-M option] [-m flag] [-n #cpus] [-p port]
[-s] [-S #max-socks] [-t directory] [-U #listeners] [-u user] [-v] [-V] [-X lock-file] [-x cache-file]
```
All manual pages seems to have the same issue, not just named.8.
### Relevant configuration files
none
### Relevant logs and/or screenshots
none
### Possible fixes
regenerate all pages with proper indentationDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2312Lint generated manual pages2021-03-03T10:57:44ZMichal NowakLint generated manual pagesFor man page generation we rely on Sphinx and DocBook (`v9_11`) and although we don't control the manual page output, we may lint them with `mandoc -T lint` and thus try harder in CI to produce legible content.
On `main` and `v9_16` onl...For man page generation we rely on Sphinx and DocBook (`v9_11`) and although we don't control the manual page output, we may lint them with `mandoc -T lint` and thus try harder in CI to produce legible content.
On `main` and `v9_16` only three *types* of warnings and no errors are produced:
```
$ find doc/man/ -not -path '*/_build/*' -name "*.[0-9]" -exec mandoc -Tlint "{}" \;
WARNING: skipping paragraph macro: sp after SH
WARNING: unknown font, skipping request: ft C
WARNING: skipping paragraph macro: sp after SS
```
There are more types of warnings and one type of error on `v9_11`.
We could filter out these and rely on `mandoc -T lint` as a sanity check of generated man pages.
The case of https://gitlab.isc.org/isc-projects/bind9/-/issues/2310 seems to be covered (though probably only by a chance):
```
$ find /tmp/mozilla_newman0/bind-9.11.24 -name '*.[0-9]' -not -path '*/tests/*' -not -path '*/contrib/*' -exec mandoc -Tlint -Werror {} \;
$ find /tmp/mozilla_newman0/bind-9.11.25 -name '*.[0-9]' -not -path '*/tests/*' -not -path '*/contrib/*' -exec mandoc -Tlint -Werror {} \;
mandoc: /tmp/mozilla_newman0/bind-9.11.25/bin/named/named.8:189:2: ERROR: skipping unknown macro: .\}
mandoc: /tmp/mozilla_newman0/bind-9.11.25/bin/named/lwresd.8:194:2: ERROR: skipping unknown macro: .\}
```
The risk here is inherent from the fact that we don't control the generated output and `mandoc` may fail CI job, even-thought the content is legible by `man(1)` program "standards".March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2018could not get query source dispatcher error after reconfig2021-03-03T10:06:19ZLaurent Frigaultcould not get query source dispatcher error after reconfig### Summary
We are running an hidden master only bind server with about many zones , most signed with auto-dnssec maintain; inline-signing yes;
Every few days (7-8 days) we get the following error in the log :
```
Jul 9 11:32:37 nsmas...### Summary
We are running an hidden master only bind server with about many zones , most signed with auto-dnssec maintain; inline-signing yes;
Every few days (7-8 days) we get the following error in the log :
```
Jul 9 11:32:37 nsmaster named[68180]: general: info: received control channel command 'reconfig'
Jul 9 11:32:48 nsmaster named[68180]: general: error: could not get query source dispatcher (213.36.252.194#0)
Jul 9 11:32:48 nsmaster named[68180]: general: error: reloading configuration failed: out of memory
```
and the server must be restarted.
### BIND version used
```
# /usr/local/sbin/named -V
BIND 9.16.4 (Stable Release) <id:0849b42>
running on FreeBSD amd64 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=large' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.1' 'build_alias=amd64-portbld-freebsd12.1' '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'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581)
compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
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/pid
named lock file: /var/run/named/named.lock
```
It is the FreeBSD port compiled with --with-tuning=large
We had the same issue before with --with-tuning=default
We also had the same issue before with bind 9.11.20.
I try starting named with -U 20 but this does not change anything.
We have been running the same configuration WITHOUT DNSSEC signed zones for years on smaller servers without this issue.
### Steps to reproduce
We periodically regenerate our configuration to add/update/remove zones.
when needed, we use "rndc reconfig"
### What is the current *bug* behavior?
After some rndc reconfig the named server stop working with the errors:
```
Jul 9 11:32:48 nsmaster named[68180]: general: error: could not get query source dispatcher (213.36.252.194#0)
Jul 9 11:32:48 nsmaster named[68180]: general: error: reloading configuration failed: out of memory
```
and top reports:
```
last pid: 62441; load averages: 0.29, 0.57, 0.70 up 169+19:01:18 11:47:47
15 processes: 1 running, 14 sleeping
CPU: 1.4% user, 0.0% nice, 4.8% system, 0.0% interrupt, 93.8% idle
Mem: 7100M Active, 5153M Inact, 18G Laundry, 14G Wired, 582M Buf, 18G Free
ARC: 7506M Total, 4261M MFU, 1187M MRU, 30M Anon, 287M Header, 1742M Other
3994M Compressed, 17G Uncompressed, 4.45:1 Ratio
Swap: 64G Total, 422M Used, 64G Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
68180 bind 170 52 0 30G 26G sigwai 3 42.3H 0.00% named
```
When named is started, top reports :
```
last pid: 64008; load averages: 0.49, 0.68, 1.00 up 169+21:04:34 13:51:03
21 processes: 1 running, 20 sleeping
CPU: 1.4% user, 0.0% nice, 4.8% system, 0.0% interrupt, 93.8% idle
Mem: 8509M Active, 2467M Inact, 22M Laundry, 16G Wired, 582M Buf, 36G Free
ARC: 7491M Total, 4043M MFU, 1410M MRU, 11M Anon, 286M Header, 1740M Other
3990M Compressed, 18G Uncompressed, 4.52:1 Ratio
Swap: 64G Total, 98M Used, 64G Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
63924 bind 170 52 0 9180M 7033M sigwai 25 13:36 0.00% named
```
There must be some memory / resource leak issue.
The server has 64G RAM / 56 cores .
This should not be a memory issue.
When it happens, we need to stop and start the named server.
### What is the expected *correct* behavior?
There should not be any errors after the reconfig and the server should not stop working.
Its memory usage should not grow that much .
### Relevant configuration files
Too many zones (about 73000) to paste them all here
```
logging {
channel stdlog {
syslog local1;
print-category yes;
print-severity yes;
print-time no;
};
category default { stdlog; };
category queries { "null"; };
category query-errors { "null"; };
category update { "null"; };
category update-security { "null"; };
category security { "null"; };
};
options {
// All file and path names are relative to the chroot directory,
// if any, and should be fully qualified.
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 { 127.0.1.4; 213.36.252.194; };
listen-on-v6 { 2a01:e0d:1:2:58bf:f9c2:0:1; };
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
query-source address 213.36.252.194 port *;
query-source-v6 address 2a01:e0d:1:2:58bf:f9c2:0:1 port *;
allow-transfer {
127.0.1.4;
213.36.252.128/25;
2a01:e0b:1:e:0:0:0:0/64;
213.36.252.32/27;
62.210.98.15;
213.36.253.14;
};
startup-notify-rate 100;
notify-source 213.36.252.194;
recursion no;
notify no;
check-integrity no;
minimal-responses yes;
max-transfer-idle-out 5;
max-transfer-time-out 10;
tcp-clients 1000;
tcp-listen-queue 100;
transfers-out 1000;
dnssec-enable yes;
sig-validity-interval 60 30;
masterfile-format text;
request-ixfr no;
provide-ixfr no;
};
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
key "rndc-key" {
algorithm hmac-sha256;
secret "xxx";
};
controls {
inet 127.0.1.4
port 953
allow { any; } keys { "rndc-key"; };
};
// les zones
include "/usr/local/etc/namedb/named.conf.custom.inc";
include "/usr/local/etc/namedb/named.conf.custom-old.inc";
```
Most zones are signed like:
```
zone "bookmyname.be" {
type master;
file "custom/b/o/bookmyname.be/bookmyname.be";
notify explicit;
also-notify { 213.36.252.135; 62.210.98.15; 213.36.253.14; };
auto-dnssec maintain;
inline-signing yes;
key-directory "custom/b/o/bookmyname.be";
};
```
a few are not signed and have the following config:
```
zone "bookmyname.lu" {
type master;
file "custom/b/o/bookmyname.lu/bookmyname.lu";
notify explicit;
also-notify { 213.36.252.135; 62.210.98.15; 213.36.253.14; };
};
```
### Relevant logs and/or screenshots
```
# rndc status
version: BIND 9.16.4 (Stable Release) <id:0849b42>
running on nsmaster.free.org: FreeBSD amd64 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC
boot time: Thu, 09 Jul 2020 09:52:25 GMT
last configured: Thu, 09 Jul 2020 10:42:49 GMT
configuration file: /usr/local/etc/namedb/named-custom.conf
CPUs found: 56
worker threads: 56
UDP listeners per interface: 56
number of zones: 144025 (0 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/900/1000
tcp clients: 0/1000
TCP high-water: 17
server is up and running
```
### Possible fixes
No ideaMarch 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2238Fix back port issues: missing checks.2021-03-03T09:59:54ZMark AndrewsFix back port issues: missing checks.```
** CID 312923: Error handling issues (CHECKED_RETURN)
/lib/dns/zone.c: 11660 in create_query()
________________________________________________________________________________________________________
*** CID 312923: Error handli...```
** CID 312923: Error handling issues (CHECKED_RETURN)
/lib/dns/zone.c: 11660 in create_query()
________________________________________________________________________________________________________
*** CID 312923: Error handling issues (CHECKED_RETURN)
/lib/dns/zone.c: 11660 in create_query()
11654 dns_message_t **messagep) {
11655 dns_message_t *message = NULL;
11656 dns_name_t *qname = NULL;
11657 dns_rdataset_t *qrdataset = NULL;
11658 isc_result_t result;
11659
CID 312923: Error handling issues (CHECKED_RETURN)
Calling "dns_message_create" without checking return value (as is done elsewhere 17 out of 21 times).
11660 dns_message_create(zone->mctx, DNS_MESSAGE_INTENTRENDER, &message);
11661
11662 message->opcode = dns_opcode_query;
11663 message->rdclass = zone->rdclass;
11664
11665 result = dns_message_gettempname(message, &qname);
** CID 312922: Error handling issues (CHECKED_RETURN)
/lib/dns/zone.c: 11994 in stub_request_nameserver_address()
________________________________________________________________________________________________________
*** CID 312922: Error handling issues (CHECKED_RETURN)
/lib/dns/zone.c: 11994 in stub_request_nameserver_address()
11988 zone = args->stub->zone;
11989 request = isc_mem_get(zone->mctx, sizeof(*request));
11990 request->request = NULL;
11991 request->args = args;
11992 request->name = (dns_name_t)DNS_NAME_INITEMPTY;
11993 request->ipv4 = ipv4;
CID 312922: Error handling issues (CHECKED_RETURN)
Calling "dns_name_dup" without checking return value (as is done elsewhere 52 out of 60 times).
11994 dns_name_dup(name, zone->mctx, &request->name);
11995
11996 result = create_query(zone, ipv4 ? dns_rdatatype_a : dns_rdatatype_aaaa,
11997 &request->name, &message);
11998 INSIST(result == ISC_R_SUCCESS);
11999
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2443CID 316608: Memory - corruptions (OVERRUN)2021-03-03T09:57:01ZMichal NowakCID 316608: Memory - corruptions (OVERRUN)Coverity Scan identified this as of a "High" impact.
Recently committed as 49c40827f6b88b4c12751086aab529298587e265 by @dfronza:
```
*** CID 316608: Memory - corruptions (OVERRUN)
/lib/dns/resolver.c: 5017 in fctx_create()
5011 ...Coverity Scan identified this as of a "High" impact.
Recently committed as 49c40827f6b88b4c12751086aab529298587e265 by @dfronza:
```
*** CID 316608: Memory - corruptions (OVERRUN)
/lib/dns/resolver.c: 5017 in fctx_create()
5011 * Make fctx->info point to a copy of a formatted string
5012 * "name/type".
5013 */
5014 dns_name_format(name, buf, sizeof(buf));
5015 dns_rdatatype_format(type, typebuf, sizeof(typebuf));
5016 p = strlcat(buf, "/", sizeof(buf));
>>> CID 316608: Memory - corruptions (OVERRUN)
>>> Calling "strlcat" with "buf + p" and "1036UL" is suspicious because "buf" points into a buffer of 1036 bytes and the function call may access "(char *)(buf + p) + 1035UL". [Note: The source code implementation of the function has been overridden by a builtin model.]
5017 strlcat(buf + p, typebuf, sizeof(buf));
5018 fctx->info = isc_mem_strdup(mctx, buf);
5019
5020 FCTXTRACE("create");
5021 dns_name_init(&fctx->name, NULL);
5022 dns_name_dup(name, mctx, &fctx->name);
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/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/2507CID 320483: API usage errors (LOCK)2021-03-02T14:42:03ZMark AndrewsCID 320483: API usage errors (LOCK)```
** CID 320483: API usage errors (LOCK)
/bin/dig/dighost.c: 2133 in _new_query()
________________________________________________________________________________________________________
*** CID 320483: API usage errors (LOCK)
/b...```
** CID 320483: API usage errors (LOCK)
/bin/dig/dighost.c: 2133 in _new_query()
________________________________________________________________________________________________________
*** CID 320483: API usage errors (LOCK)
/bin/dig/dighost.c: 2133 in _new_query()
2127 _new_query(dig_lookup_t *lookup, char *servname, char *userarg,
2128 const char *file, unsigned int line) {
2129 dig_query_t *query = NULL;
2130
2131 query = isc_mem_allocate(mctx, sizeof(dig_query_t));
2132 debug("create query %p linked to lookup %p", query, lookup);
CID 320483: API usage errors (LOCK)
"isc__mempool_get" unlocks "commctx->lock" while it is unlocked.
2133 *query = (dig_query_t){ .sendbuf = lookup->renderbuf,
2134 .servname = servname,
2135 .userarg = userarg,
2136 .first_pass = true,
2137 .warn_id = true,
2138 .recvspace = isc_mempool_get(commctx),
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2519named won't start on Windows2021-03-02T14:41:07ZMichal Nowaknamed won't start on WindowsNearly all Windows [system tests fail](https://gitlab.isc.org/isc-projects/bind9/-/pipelines/64375) on `main` since February 19 like this:
```
S:acl:2021-02-22T20:20:39-0800
T:acl:1:A
A:acl:System test acl
I:acl:PORTS:5322,5323,5324,5325...Nearly all Windows [system tests fail](https://gitlab.isc.org/isc-projects/bind9/-/pipelines/64375) on `main` since February 19 like this:
```
S:acl:2021-02-22T20:20:39-0800
T:acl:1:A
A:acl:System test acl
I:acl:PORTS:5322,5323,5324,5325,5326,5327,5328,5329,5330,5331,5332,5333,5334
I:acl:starting servers
I:acl:Couldn't start server C:/builds/isc-projects/bind9/Build/Release/named.exe -D acl-ns2 -X named.lock -m record,size,mctx -c named.conf -d 99 -g -U 4 -T maxcachesize=2097152 >named.run 2>&1 & echo $! (pid=2678)
I:acl:failed
kill: 2678: No such process
I:acl:starting servers failed
R:acl:FAIL
E:acl:2021-02-22T20:20:56-0800
```
I'll investigate further.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michał KępieńMichał Kępień