ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-04-26T13:26:16Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3189Version numbers are printed inconsistently2022-04-26T13:26:16ZTony FinchVersion numbers are printed inconsistentlyMost of the BIND utilities report their version number to `stderr`. A few print to `stdout` instead: `named`, `named-checkconf`, `named-checkzone`. The utilities that print to `stderr` then `exit(0)`, so they disagree with themselves abo...Most of the BIND utilities report their version number to `stderr`. A few print to `stdout` instead: `named`, `named-checkconf`, `named-checkzone`. The utilities that print to `stderr` then `exit(0)`, so they disagree with themselves about whether reporting the version number is an error or not. Since the user asked for the version number it seems more logical to make it a non-error, i.e. print to `stdout` and `exit(0)`.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3193CID 350473: Null pointer dereferences (FORWARD_NULL) in bin/dig/dighost.c: 29...2022-04-26T13:25:39ZOndřej SurýCID 350473: Null pointer dereferences (FORWARD_NULL) in bin/dig/dighost.c: 2904 in udp_ready()```
/bin/dig/dighost.c: 2904 in udp_ready()
2898
2899 if (eresult == ISC_R_CANCELED || query->canceled) {
2900 dig_lookup_t *l = query->lookup;
2901
2902 debug("in cancel handler");
2903 query_detach(&que...```
/bin/dig/dighost.c: 2904 in udp_ready()
2898
2899 if (eresult == ISC_R_CANCELED || query->canceled) {
2900 dig_lookup_t *l = query->lookup;
2901
2902 debug("in cancel handler");
2903 query_detach(&query);
CID 350473: Null pointer dereferences (FORWARD_NULL)
Dereferencing null pointer "query".
2904 if (!query->canceled) {
2905 cancel_lookup(l);
2906 }
2907 lookup_detach(&l);
2908 return;
2909 } else if (eresult != ISC_R_SUCCESS) {
```April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3188`dig +noidn` should not complain about lack of IDN support2022-04-26T13:25:24ZTony Finch`dig +noidn` should not complain about lack of IDN support### Summary
`dig` reports an error if it is built without IDN support, and the `+noidnin` and/or `+noidnout` options are used.
This means the options are not useful for a script that wants consistent lack of IDN translation regardless o...### Summary
`dig` reports an error if it is built without IDN support, and the `+noidnin` and/or `+noidnout` options are used.
This means the options are not useful for a script that wants consistent lack of IDN translation regardless of how BIND is built.
### BIND version used
9.11 and later
### Steps to reproduce
* build BIND --without-libidn2
* run `dig +noidnout`
### What is the current *bug* behavior?
`dig` complains `;; IDN support not enabled`
### What is the expected *correct* behavior?
No noise on stderr.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3184query context management issues in dighost.c2022-04-26T13:25:07ZOndřej Surýquery context management issues in dighost.cFor the reference, the _cancel_lookup() function iterates through
the lookup's queries list and detaches them. In the ideal scenario,
that should be the last reference and the query will be destroyed
after that, but it is also possible t...For the reference, the _cancel_lookup() function iterates through
the lookup's queries list and detaches them. In the ideal scenario,
that should be the last reference and the query will be destroyed
after that, but it is also possible that we are still expecting a
callback, which also holds a reference (for example, _cancel_lookup()
could have been called from recv_done(), when send_done() was still
not executed).
The start_udp() and start_tcp() functions are currently designed in
slightly different ways: start_udp() creates a new query attachment
`connectquery`, to be called in the callback function, while
start_tcp() does not, which is a bug, but is hidden by the fact
that when the query is being erroneously destroyed prematurely (before
_cancel_lookup() is called) in the result of that, it also gets
de-listed from the lookup's queries' list, so _cancel_lookup() doesn't
even try to detach it.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/31179.18.0 nslookup debugging output2022-04-26T13:23:59ZJohn E. Krokes9.18.0 nslookup debugging output
### Summary
nslookup in interactive mode produces debugging output by default
### BIND version used
BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
built by make ...
### Summary
nslookup in interactive mode produces debugging output by default
### BIND version used
BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
built by make with '--sysconfdir=/etc' '--localstatedir=/var' '--disable-linux-caps' '--disable-doh'
compiled by GCC 10.2.1 20210110
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
### Steps to reproduce
run nslookup
attempt to look up literally anything
### What is the current *bug* behavior?
debugging output is produced alongside expected output
### What is the expected *correct* behavior?
normal output
### Possible fixes
in bin/dig/nslookup.c
Line 624 is "debugging = true;".
I suggest that this should be either "debugging = false;" or the line should be deleted.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1610dig: Incorrect encoding to punycode2022-04-26T13:22:14ZGhost Userdig: Incorrect encoding to punycode### Summary
Incorrect/invalid output when trying to encode the domain: ☺.unicode.
It appears the punycode encoder generates a domain label that includes a space. Several punycode generators do this, including dnspython and Python's ...### Summary
Incorrect/invalid output when trying to encode the domain: ☺.unicode.
It appears the punycode encoder generates a domain label that includes a space. Several punycode generators do this, including dnspython and Python's IDNA encoding built-in.
This came up while performing testing ahead of migrating towards a new system of handling DNS records which uses Python, however, we've subsequently identified that it affects dig as well.
### BIND version used
9.11.5-P4-5.1-Debian (From Debian Buster)
### Steps to reproduce
```
$ dig ☺.unicode
```
### What is the current *bug* behavior?
```
dig: 'xn--\032o-oia59s.unicode.' is not a legal IDNA2008 name (string contains a disallowed character), use +noidnout
```
### What is the expected *correct* behavior?
I'd expect dig to look up the A record for the correctly encoded domain.
I'm not sure what the correctly encoded domain is, although my suspicion is that it should be xn--xba3f15e.unicode.
### Relevant configuration files
Not sure that any config files are actually relevant - if there are, please let me know.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/2923Dig crashes with SIGABRT when parsing invalid DoH endpoint location2022-04-26T13:21:41ZfriedlhoDig crashes with SIGABRT when parsing invalid DoH endpoint location### Summary
Dig crashes with SIGABRT when providing an invalid DoH endpoint location.
### BIND version used
DiG 9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu
(Bind9-Dev Branch)
Tested on Ubuntu 20 & Fedora 34.
### Steps to reproduce
Call d...### Summary
Dig crashes with SIGABRT when providing an invalid DoH endpoint location.
### BIND version used
DiG 9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu
(Bind9-Dev Branch)
Tested on Ubuntu 20 & Fedora 34.
### Steps to reproduce
Call dig with a DoH URI and manually specify the DoH Endpoint location without a leading "/":
dig +https=doh/family-filter @doh.cleanbrowsing.org rub.de
The correct command would be:
dig +https=/doh/family-filter @doh.cleanbrowsing.org rub.de
### What is the current *bug* behavior?
Dig crashed with SIGABRT in isc_assertion_failed()
### What is the expected *correct* behavior?
Dig outputs an error message to tell the user that the endpoint location is invalid.
### Relevant logs and/or screenshots
```
dig +https=doh/family-filter @doh.cleanbrowsing.org google.de#
netmgr/http.c:3098: REQUIRE(isc_nm_http_path_isvalid(abs_path)) failed, back trace
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x31d93)[0x7f3798d69d93]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_assertion_failed+0x10)[0x7f3798d69cd0]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_nm_http_makeuri+0x2aa)[0x7f3798da924a]
dig(+0x13ff7)[0x558504aa0ff7]
dig(+0x1721a)[0x558504aa421a]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc_task_run+0x162)[0x7f3798d99572]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x19ead)[0x7f3798d51ead]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x204f1)[0x7f3798d584f1]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x20c15)[0x7f3798d58c15]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x213e7)[0x7f3798d593e7]
/lib/x86_64-linux-gnu/libuv.so.1(+0xfea8)[0x7f379885eea8]
/lib/x86_64-linux-gnu/libuv.so.1(uv__io_poll+0x360)[0x7f379886fb80]
/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x11c)[0x7f379885f84c]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(+0x20ca7)[0x7f3798d58ca7]
/lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so(isc__trampoline_run+0x1a)[0x7f3798da08ba]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609)[0x7f3798a7b609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f37989a2293]
Aborted (core dumped)
```
```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `dig +https doh/family-filter @doh.cleanbrowsing.org rub.de'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f2629900700 (LWP 52138))]
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f262c3de859 in __GI_abort () at abort.c:79
#2 0x00007f262c8a2cd5 in isc_assertion_failed () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#3 0x00007f262c8e224a in isc_nm_http_makeuri () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#4 0x0000564d70879ff7 in ?? ()
#5 0x0000564d7087d21a in ?? ()
#6 0x00007f262c8d2572 in isc_task_run () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#7 0x00007f262c88aead in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#8 0x00007f262c8914f1 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#9 0x00007f262c891c15 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#10 0x00007f262c8923e7 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#11 0x00007f262c397ea8 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x00007f262c3a8b80 in uv.io_poll () from /lib/x86_64-linux-gnu/libuv.so.1
#13 0x00007f262c39884c in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#14 0x00007f262c891ca7 in ?? () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#15 0x00007f262c8d98ba in isc.trampoline_run () from /lib/x86_64-linux-gnu/libisc-9.17.18-1+ubuntu20.04.1+isc+1-Ubuntu.so
#16 0x00007f262c5b4609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#17 0x00007f262c4db293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2785host does not parse options timeout and retries2022-04-26T13:21:13ZPetr Menšíkhost does not parse options timeout and retries### Summary
man host mentions on -W option default could be overiden in /etc/resolv.conf. Worked on 9.11, no longer on 9.16.
### BIND version used
```
BIND 9.16.16-RH (Stable Release) <id:0c314d8>
running on Linux x86_64 5.12.10-300.f...### Summary
man host mentions on -W option default could be overiden in /etc/resolv.conf. Worked on 9.11, no longer on 9.16.
### BIND version used
```
BIND 9.16.16-RH (Stable Release) <id:0c314d8>
running on Linux x86_64 5.12.10-300.fc34.x86_64 #1 SMP Thu Jun 10 14:21:36 UTC 2021
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' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 11.1.1 20210428 (Red Hat 11.1.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.14
linked to json-c version: 0.14
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
- echo "nameserver 127.0.0.255 > /etc/resolv.conf"
- echo "options timeout:1 attempts:1" >> /etc/resolv.conf
- time host localhost
### What is the current *bug* behavior?
(host on 9.16)
```# time host localhost
;; connection timed out; no servers could be reached
real 0m10.011s
user 0m0.005s
sys 0m0.006s
```
Obviously options are ignored.
### What is the expected *correct* behavior?
(host on 9.11)
```
# time host localhost
;; connection timed out; no servers could be reached
real 0m2,010s
user 0m0,003s
sys 0m0,006s
```
### Relevant configuration files
```
# resolv.conf
options timeout:1 attempts:1
nameserver 127.0.0.255
```
### Relevant logs and/or screenshots
none
### Possible fixes
It should parse more options in lib/irs/resconf.c, similar to lwres configuration parsing done in 9.11. Found when retesting ancient test case for [RHEL bug](https://bugzilla.redhat.com/show_bug.cgi?id=570851). Manual page for host mentions default from /etc/resolv.conf. It should read it or at least manual page should not mention it is related.
Because it still works on 9.11, it is a regression.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2592dig -u is extremely inaccurate, especially on machines with the kernel timer ...2022-04-26T13:18:31ZPatrick McLeandig -u is extremely inaccurate, especially on machines with the kernel timer tick set at 100HzThe current isc_time_now uses `CLOCK_REALTIME_COARSE` which only updates on a timer tick. This clock is generally fine for millisecond accuracy, but on servers with 100hz clocks, this clock is nowhere near accurate enough for microsecond...The current isc_time_now uses `CLOCK_REALTIME_COARSE` which only updates on a timer tick. This clock is generally fine for millisecond accuracy, but on servers with 100hz clocks, this clock is nowhere near accurate enough for microsecond accuracy.
This makes the `dig -u` command report very inaccurate timings. On a fast network with sub-ms responses, the reported time will oscillate between 0us and 10000us. I have created a patch to make this use `CLOCK_REALTIME` if the `-u` option is passed to dig.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/2564nslookup segfaults for SERVFAIL2022-04-26T13:18:18ZJohn Peronenslookup segfaults for SERVFAIL### Summary
nslookup (and host) segfault when the answer is SERVFAIL. dig works as expected.
### BIND version used
BIND 9.17.10 (Development Release) <id:5fbd5ff><br>
Tested also 9.17.9 with the same results
### Steps to reproduce
nsl...### Summary
nslookup (and host) segfault when the answer is SERVFAIL. dig works as expected.
### BIND version used
BIND 9.17.10 (Development Release) <id:5fbd5ff><br>
Tested also 9.17.9 with the same results
### Steps to reproduce
nslookup redpress.gr<br>
Segmentation fault
### What is the current *bug* behavior?
isc-net-0000[21534]: segfault at ffffffffffffffff ip 000000000040f661 sp 00007faad57a9820 error 4 in nslookup[400000+17000]
### What is the expected *correct* behavior?
nslookup redpress.gr<br>
Server: 127.0.0.1<br>
Address: 127.0.0.1#53<br>
<br>
** server can't find redpress.gr: SERVFAILMay 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/1641RFC8484, DOH support in DIG (and any other relevant utilities)2022-04-26T13:17:14ZVicky Riskvicky@isc.orgRFC8484, DOH support in DIG (and any other relevant utilities)Creating a separate issue for this.Creating a separate issue for this.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2403dig has a fit with option -multi (typo on +multi)2022-04-26T13:16:36ZJP Mensdig has a fit with option -multi (typo on +multi)### Summary
`dig` crashes when erroneously given option `-multi`
During a training, a student (Rob) erroneously specified `-multi` instead of `+multi` when using `dig` on an internal training domain. This was using `bind-utils-9.11.20-...### Summary
`dig` crashes when erroneously given option `-multi`
During a training, a student (Rob) erroneously specified `-multi` instead of `+multi` when using `dig` on an internal training domain. This was using `bind-utils-9.11.20-5.el8.x86_64` on CentOS 8.
I am able to reproduce this on a similar machine with an ISC COPR release.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19 17:20:08 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/scls/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/scls/isc-bind' '--sharedstatedir=/var/opt/isc/scls/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.11/sphinx/bin/sphinx-build'
compiled by GCC 8.3.1 20191121 (Red Hat 8.3.1-5)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/opt/isc/scls/isc-bind/named.conf
rndc configuration: /etc/opt/isc/scls/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/scls/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/scls/isc-bind/run/named/session.key
named PID file: /var/opt/isc/scls/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/scls/isc-bind/run/named/named.lock
```
### Steps to reproduce
```
/opt/isc/isc-bind/root/bin/dig isc.org -multi
```
### What is the current *bug* behavior?
```console
$ /opt/isc/isc-bind/root/bin/dig isc.org -multi
add 0x55a9501c2160 size 8528 file log.c line 257 mctx 0x55a9501b53e0
add 0x7fd9d72c6010 size 72 file log.c line 306 mctx 0x55a9501b53e0
add 0x7fd9d72c7010 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8018 size 23 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c7060 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8030 size 23 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c70b0 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8048 size 22 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c7100 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c9008 size 13 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c9010 size 32 file log.c line 996 mctx 0x55a9501b53e0
add 0x7fd9d72ca010 size 336 file log.c line 996 mctx 0x55a9501b53e0
del 0x7fd9d72c9010 size 32 file log.c line 1004 mctx 0x55a9501b53e0
add 0x7fd9d72c9010 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9030 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9050 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9070 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9090 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9090 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90b0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90d0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90f0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9110 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9130 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9150 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9170 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9190 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91b0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91d0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91f0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9210 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9230 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9250 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9270 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9290 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72cb010 size 288 file task.c line 1386 mctx 0x55a9501b53e0
add 0x7fd9d72cc010 size 144 file task.c line 1410 mctx 0x55a9501b53e0
add 0x7fd9d72cd010 size 216 file task.c line 286 mctx 0x55a9501b53e0
add 0x7fd9d72ce010 size 160 file timer.c line 697 mctx 0x55a9501b53e0
add 0x7fd9d72cf010 size 56 file heap.c line 87 mctx 0x55a9501b53e0
add 0x7fd9d72d0010 size 168 file socket.c line 3806 mctx 0x55a9501b53e0
add 0x7fd9d72c7150 size 80 file socket.c line 3827 mctx 0x55a9501b53e0
add 0x7fd9d729c010 size 168000 file socket.c line 3578 mctx 0x55a9501b53e0
add 0x55a9501c7ce0 size 84000 file socket.c line 3584 mctx 0x55a9501b53e0
add 0x55a9501dc550 size 40960 file socket.c line 3589 mctx 0x55a9501b53e0
add 0x55a9501e65a0 size 84000 file socket.c line 3631 mctx 0x55a9501b53e0
add 0x55a9501fae10 size 24576 file socket.c line 3638 mctx 0x55a9501b53e0
add 0x7fd9d72cefb0 size 96 file mem.c line 1607 mctx 0x55a9501b53e0
add 0x55a95021a170 size 2464 file resconf.c line 522 mctx 0x55a9501b53e0
add 0x7fd9d72d1010 size 152 file resconf.c line 239 mctx 0x55a9501b53e0
add 0x7fd9d72d10a8 size 152 file resconf.c line 239 mctx 0x55a9501b53e0
add 0x55a950220418 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
add 0x55a950220418 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
add 0x55a950220c38 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
del 0x7fd9d72d1010 size 152 file resconf.c line 652 mctx 0x55a9501b53e0
del 0x7fd9d72d10a8 size 152 file resconf.c line 652 mctx 0x55a9501b53e0
del 0x55a95021a170 size 2464 file resconf.c line 665 mctx 0x55a9501b53e0
add 0x55a950221458 size 5176 file dighost.c line 618 mctx 0x55a9501b53e0
add 0x55a950222898 size 5176 file dighost.c line 618 mctx 0x55a9501b53e0
Invalid option: -lti
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Use "dig -h" (or "dig -h | more") for complete list of options
```
### What is the expected *correct* behavior?
```
Invalid option: -lti
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Use "dig -h" (or "dig -h | more") for complete list of options
```
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixesFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2319Add the ability to display the BADCOOKIE message to dig when +badcookie is ac...2022-04-26T13:16:07ZMark AndrewsAdd the ability to display the BADCOOKIE message to dig when +badcookie is activeSeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2288"dig" crashes when interrupted while waiting for a TCP connection2022-04-26T13:15:52ZMichał Kępień"dig" crashes when interrupted while waiting for a TCP connectionTo reproduce, fire up a `dig` query that will not connect over TCP
before it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10 +vc
and then hit CTRL+C:
dighost.c:3232: REQUIRE((__builtin_expect(!!(((query)) != ((void *)0)), ...To reproduce, fire up a `dig` query that will not connect over TCP
before it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10 +vc
and then hit CTRL+C:
dighost.c:3232: REQUIRE((__builtin_expect(!!(((query)) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)((query)))->magic == ((('D') << 24 | ('i') << 16 | ('g') << 8 | ('q')))), 1))) failed, back trace
Looks like `arg` (which gets cast to `dig_query_t *query`) passed to
`tcp_connected()` is broken in this case.
See #2287 for the UDP counterpart of this problem.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2190dig: "-u" (microsecond timestamp precision) does not work in YAML output mode2022-04-26T13:14:41Zchampiondotdig: "-u" (microsecond timestamp precision) does not work in YAML output modeHI,ALL:
The version BIND-9.16.7 of the software I'm using
dig www.google.com +yaml
When using the above command to query, there is no query time like option('-u') in the output result
dig www.google.com -u
**;; Query time: 6999 u...HI,ALL:
The version BIND-9.16.7 of the software I'm using
dig www.google.com +yaml
When using the above command to query, there is no query time like option('-u') in the output result
dig www.google.com -u
**;; Query time: 6999 usec**
Combined with the output
dig www.google.com -u +yamlOctober 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/2183DNS Flag Day 20202022-04-26T13:13:00ZOndřej SurýDNS Flag Day 2020This is a issue to make the necessary changes for DNS Flag Day 2020.This is a issue to make the necessary changes for DNS Flag Day 2020.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2140convert dig and friends to use the netmgr2022-04-26T13:12:40ZEvan Huntconvert dig and friends to use the netmgrConvert `dig`, `host` and `nslookup` to use the network manager instead of the isc_socket API.Convert `dig`, `host` and `nslookup` to use the network manager instead of the isc_socket API.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2054dig +bufsize=0 sets bufsize to 40962022-04-26T13:12:08ZAnand Buddhdevdig +bufsize=0 sets bufsize to 4096### Summary
When I send a query with dig, and set bufsize to 0, dig appears to ignore this and sets the bufsize to 4096.
### BIND version used
9.16.5
### Steps to reproduce
Use dig to send such a query:
`dig +norec +bufsize=0 ke so...### Summary
When I send a query with dig, and set bufsize to 0, dig appears to ignore this and sets the bufsize to 4096.
### BIND version used
9.16.5
### Steps to reproduce
Use dig to send such a query:
`dig +norec +bufsize=0 ke soa @kenic.anycastdns.cz`
### What is the current *bug* behavior?
dig sends an EDNS query with the bufsize set to 4096.
### What is the expected *correct* behavior?
dig should send a non-EDNS query, as described in the man page. Even better, dig should send an EDNS query but with bufsize set to 0, as instructed by the user.
### Relevant configuration files
No relevant configuration files.
### Relevant logs and/or screenshots
Here is a tcpdump showing how dig has ignored my `+bufsize=0` setting, and set the buffer to 4096:
```
12:48:39.756643 IP (tos 0x0, ttl 64, id 15958, offset 0, flags [none], proto UDP (17), length 59)
192.168.178.34.51981 > 185.28.194.194.53: [udp sum ok] 8443 [1au] SOA? ke. ar: . OPT UDPsize=4096 (31)
```
### Possible fixes
I don't have enough knowledge of the code to suggest a fix.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/1851single-query trace logging2022-04-26T13:10:59ZEvan Huntsingle-query trace logging@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1840Add TLS support to BIND2022-04-26T13:10:29ZWitold KrecickiAdd TLS support to BINDNovember 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Witold KrecickiWitold Krecicki