BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-01-11T15:15:06Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2885Pylint "no-member" check fails on Bullseye2022-01-11T15:15:06ZMichal NowakPylint "no-member" check fails on BullseyeJob [#1947023](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947023) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with:
```
$ PYTHONPATH="$PYTHONPATH:$CI_PROJECT_DIR/bin/python"
$ pylint --rcfile $CI_PROJ...Job [#1947023](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947023) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with:
```
$ PYTHONPATH="$PYTHONPATH:$CI_PROJECT_DIR/bin/python"
$ pylint --rcfile $CI_PROJECT_DIR/.pylintrc $(git ls-files '*.py' | grep -vE '(ans\.py|dangerfile\.py)')
************* Module tests-checkds
bin/tests/system/checkds/tests-checkds.py:98:27: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/checkds/tests-checkds.py:101:50: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/checkds/tests-checkds.py:102:24: E1101: Module 'dns.rdatatype' has no 'DS' member (no-member)
bin/tests/system/checkds/tests-checkds.py:102:42: E1101: Module 'dns.rdatatype' has no 'NONE' member (no-member)
bin/tests/system/checkds/tests-checkds.py:143:33: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/checkds/tests-checkds.py:161:29: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
************* Module helper
bin/tests/system/statschannel/helper.py:98:26: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/statschannel/helper.py:106:26: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
************* Module tests-tcp
bin/tests/system/timeouts/tests-tcp.py:149:33: E1101: Module 'dns.message' has no 'ANSWER' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:150:33: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:150:52: E1101: Module 'dns.rdatatype' has no 'SOA' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:157:37: E1101: Module 'dns.message' has no 'ANSWER' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:158:37: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:158:56: E1101: Module 'dns.rdatatype' has no 'SOA' member (no-member)
-----------------------------------
Your code has been rated at 9.40/10
```
This needs to be fixed for the base image being switched to Bullseye.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2884Sometimes dig aborts on an AXFR query over TLS2021-11-04T13:43:09ZCesar KuroiwaSometimes dig aborts on an AXFR query over TLS<!--
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
Sometimes (not always) `dig` crashes with a core dump on a AXFR query over TLS
### BIND version used
DiG 9.17.17
### Steps to reproduce
Using dig to make successive AXFR requests over TLS, using a HMAC-SHA256 TSIG key
```
% dig @<server> -p 853 +tls bom axfr -y hmac-sha256:<tsig-key>:<secret>
```
### Relevant logs and/or screenshots
```
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
bom. 21600 IN DNSKEY 256 3 13 fBrEkmLy0X3ANfdXKdkj8fNPAUbwhpC5VvlBaQMzi+8h63iePUcM/dcT aJVVpWgas+HgkKlA3wCTAAFuJJ1uCA==
bom. 21600 IN DNSKEY 257 3 13 jBWA/GVSitmW8erjfZc6plKFXq2j8OOR5FR+3qgAz8nM8yW4+8egKfNO fV1ynbGKAzOzyiC3xuGm7x3RfPXmNg==
bom. 172800 IN NSEC3PARAM 1 0 10 D5193D4EFD6031FF646F
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 xcJBeqP007hmCBgx9MXXGbN1m6MieWJJUJzQOGhPhrE= 9519 NOERROR 0
nic.bom. 3600 IN NS ns.dns.br.
nic.bom. 3600 IN NS ns2.dns.br.
nic.bom. 3600 IN DS 40126 13 2 2B666C945F28C2ADA55279798382CC1BCA19DED7A32E3E0B1680FE84 4B1C154F
nic.bom. 3600 IN RRSIG DS 13 2 3600 20210903143501 20210819133501 16861 bom. az4R7y6/rjAQia9lTlcjcISj182zosM35mIlSlub108MrMXVbOZUsrzZ 3rHNKGch4j23G0ljP8ELgo5+L3AGNw==
bom. 172800 IN NS a.dns.br.
bom. 172800 IN NS b.dns.br.
bom. 172800 IN NS c.dns.br.
bom. 172800 IN NS d.dns.br.
bom. 172800 IN NS e.dns.br.
bom. 172800 IN NS f.dns.br.
bom. 21600 IN RRSIG DNSKEY 13 1 21600 20210915000000 20210611000000 14600 bom. a8Tag5dWGGgKNF0nbZfIO+ODDnaDstPjrE7BG7rRojU+KUw8uewTN/Yd 5PrgjC4wUBVbaDTNkG0evhO9dGmVXA==
bom. 172800 IN RRSIG SOA 13 1 172800 20210910221001 20210826211001 16861 bom. 23yXB1pgr7N+SdI1MtDKELA7Vrjt7/rWT1wx5AXPbNXNBFiEPBRE30Fo vJE4fBT0l5ZLbffEfJKm65XmBGBtjw==
bom. 172800 IN RRSIG NSEC3PARAM 13 1 172800 20210910221001 20210826211001 16861 bom. LzCugkc0fnBsssqz7zkj/gasbnjKy5zkSWRrfgFI2c5HW6KpQ2ImXfSG xFtJgaVWl5+QjDWNzaMVublFHe/A5A==
bom. 172800 IN RRSIG NS 13 1 172800 20210910221001 20210826211001 16861 bom. kMcSAe8somkybKerjoCV8WG0WfnUXLAO88b0sutOrAVFJR1X4655hw9R CQZKqsC3RpqnDPcbN2QSVT91wcU5jg==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN RRSIG NSEC3 13 2 900 20210903143501 20210819133501 16861 bom. zSfR9WRP+xHbBflvdOpTQDleukg+sTaTB62FvPNC15pxroPkRdTlIOLW jg54yxwye+bBcnHH+HWRtzF0QbfxOA==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F SD3KLP44SLP2IB3IRND61I31V6ROG2PE NS DS RRSIG
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN RRSIG NSEC3 13 2 900 20210910221001 20210826211001 16861 bom. NL2n5iahzZF59faktxT+x22UA8548NwIoDZc/WHub8wdQ02F134kq0Uo 8NbEzvKJdB0/FQNWf222+l5HWYJzOw==
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F 6MOM8BVSN8OG38K5J20NUBCLK3L258VI NS SOA RRSIG DNSKEY NSEC3PARAM
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 Y1j1OjfZqqmzPHeTvNvVrEIfiK4UbMLiWntNw/Vo5A4= 9519 NOERROR 0
;; Query time: 1 msec
;; WHEN: Thu Aug 26 19:11:27 -03 2021
;; XFR size: 23 records (messages 2, bytes 1777)
netmgr/netmgr.c:1703: REQUIRE(((__builtin_expect(!!((handle) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)) && __c11_atomic_load(&(handle)->references, memory_order_seq_cst) > 0)) failed, back trace
0x8002ba7a0 <isc_assertion_setcallback+0x50> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ba74a <isc_assertion_failed+0xa> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002aae6b <isc__nm_get_read_req+0x11b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5295 <isc__nm_tlsdns_processbuffer+0x95> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ab338 <isc__nm_process_sock_buffer+0x48> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b4926 <isc__nm_async_tlsdnsshutdown+0x366> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5565 <isc__nm_tlsdns_read_cb+0xb5> at /home/cesar/named/lib/libisc-9.17.17.so
0x8007c5590 <uv__stream_init+0x500> at /usr/local/lib/libuv.so.1
0x8007cc12b <uv__io_poll+0x82b> at /usr/local/lib/libuv.so.1
0x8007bb551 <uv_run+0x1b1> at /usr/local/lib/libuv.so.1
0x8002a4deb <isc__netmgr_create+0x71b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002e9914 <isc__trampoline_run+0x54> at /home/cesar/named/lib/libisc-9.17.17.so
Abort (core dumped)
```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/2882Remove the "map" zone file format from 9.17+2022-01-19T11:20:48ZPetr Špačekpspacek@isc.orgRemove the "map" zone file format from 9.17+Configuration option `masterfile-format map` is complex and thus fragile (e.g. #2872, #2878).
Currently benchmarks do not show significant benefit when compared to `masterfile-format raw`.
Tests on real `net.` zone
--------------------...Configuration option `masterfile-format map` is complex and thus fragile (e.g. #2872, #2878).
Currently benchmarks do not show significant benefit when compared to `masterfile-format raw`.
Tests on real `net.` zone
-------------------------
Zone serial 1629331223, obtained from czds.icann.org.
| format | load time [s] | % of text time |
|--------|---------------|----------------|
| map | 17,4 | 25 % |
| raw | 28,4 | 40 % |
| text | 70,8 | 100 % |
File size comparison:
| format | size | N- of text size |
|--------|------------|-----------------|
| map | 4880695376 | 5,1 |
| raw | 1509720581 | 1,6 |
| text | 960525608 | 1,0 |
Tests on an artificial flat zone
---------------------------------
Zone generated by:
```bash
perl bin/tests/startperf/mkzonefile.pl test 34674952 > /tmp/text
```
| format | load time [s] | % of text time |
|--------|---------------|----------------|
| map | 36 | 25 % |
| raw | 48 | 34 % |
| text | 144 | 100 % |
File size comparison:
| format | size | N- of text size |
|--------|------------|-----------------|
| map | 9430522392 | 9,8 |
| raw | 1386860577 | 1,4 |
| text | 960521110 | 1,0 |
Summary
-------
Speedup provided by the `map` format does not seem significant enough to warrant the complexity of map format, especially when we take into account that the difference measured in terms of "real time" is in order of 10s of seconds.
Maybe we should mark it as deprecated in ~v9.17 & ~v9.18 and remove remove it in v9.19 timeframe.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2881bind 9 can not balance load with mode order cyclic2021-08-26T07:07:39Zqimangebind 9 can not balance load with mode order cyclicI configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
...I configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
@ IN NS master.test.com.
@ IN NS slave.test.com.
slave IN A 100.100.5.21
master IN A 100.100.5.22
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.10.245
www IN A 101.101.10.246
www IN A 101.101.10.247
www IN A 101.101.10.248
www IN A 101.101.10.249
```
the Subnet Mask of ip in resource records above is all 16 bits,when i ping www.test.com from client for 10 times,the ip it allocates is 101.101.5.21 for 6 times and 101.101.5.22~25,it can not allocate the ip of 101.101.10.x,is it any limit for the ip in resource records?
and then I modified the resource records in zone file as follow:
```
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.5.26
www IN A 101.101.5.27
www IN A 101.101.5.28
www IN A 101.101.5.29
www IN A 101.101.5.30
```
and I also ping www.test.com from client for 10 times,when the clients' operarte system is centos 8,it can Poll all the ip(101.101.5.21~30) correctly,but when the clients' operarte system is centos 7,the ip it allocates is 101.101.5.21 for 5 times and 101.101.5.22~26,why does it happen?https://gitlab.isc.org/isc-projects/bind9/-/issues/2880timing issues with rndc system test2021-08-31T13:34:11ZMark Andrewstiming issues with rndc system testJob [#1940981](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1940981) failed for aae53e215678690df2fc857f05c9d409b6276104:
The test does not wait for the post freeze zone writes to complete.
```
I:rndc:checking update (68)
I:rndc:rn...Job [#1940981](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1940981) failed for aae53e215678690df2fc857f05c9d409b6276104:
The test does not wait for the post freeze zone writes to complete.
```
I:rndc:checking update (68)
I:rndc:rndc freeze
I:rndc:edit zone files
I:rndc:rndc thaw
I:rndc:rndc reload
I:rndc:ns7 server reload successful
I:rndc:checking zone file edits are loaded (69)
I:rndc:failed
I:rndc:exit status: 1
```
```
grep '\(test/IN\|'"'"'\(reload\|freeze\|thaw\)'"'"'\|all zones loaded\)' ns7/named.run
...
25-Aug-2021 00:27:36.398 received control channel command 'freeze'
25-Aug-2021 00:27:36.398 zone_dump: zone test/IN/internal: enter
25-Aug-2021 00:27:36.398 freezing zone 'test/IN' internal: success
25-Aug-2021 00:27:36.398 zone_gotwritehandle: zone test/IN/internal: enter
25-Aug-2021 00:27:36.430 received control channel command 'thaw'
25-Aug-2021 00:27:36.434 zone test/IN/internal: starting load
25-Aug-2021 00:27:36.434 zone_startload: zone test/IN/internal: enter
25-Aug-2021 00:27:36.434 thawing zone 'test/IN' internal: success
25-Aug-2021 00:27:36.442 dump_done: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone_journal_compact: zone test/IN/internal: target journal size 336
25-Aug-2021 00:27:36.442 zone test/IN/internal: dns_journal_compact: success
25-Aug-2021 00:27:36.442 zone_loaddone: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone test/IN/internal: number of nodes in database: 4
25-Aug-2021 00:27:36.442 zone test/IN/internal: loaded; checking validity
25-Aug-2021 00:27:36.442 dns_zone_verifydb: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone test/IN/internal: ixfr-from-differences: unchanged
25-Aug-2021 00:27:36.442 zone_postload: zone test/IN/internal: done
25-Aug-2021 00:27:36.466 received control channel command 'reload'
...
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2878zonefiles in map format larger than 2 GiB cannot be read but can be written (...2021-09-15T21:06:34ZPetr Špačekpspacek@isc.orgzonefiles in map format larger than 2 GiB cannot be read but can be written (data loss)### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_1...### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_16 713ded2cc37037a5c63b61c00cc41b7de0328996
- v9_11 0480e212bf4b70f52e5a24e8ef3849a94c627a84
### Steps to reproduce
1. Generate a zone file which results in map file larger than 2 GiB:
```bash
perl bin/tests/startperf/mkzonefile.pl test 8000000 > /tmp/text
```
2. Convert text zone file into `map` format:
```bash
named-compilezone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f text -F map -o /tmp/map test /tmp/text
```
3. Attempt to read the zone:
```bash
named-checkzone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f map test /tmp/map
```
### What is the current *bug* behavior?
```
zone test/IN: loading from master file /tmp/map failed: invalid file
zone test/IN: not loaded due to errors.
```
### What is the expected *correct* behavior?
Zone can be read and the data are intact, obviously.
### Possible fixes
The main question is how much we want to invest into the `map` format. If we decide to remove RBTDB map format in favor of a different data structure, we might consider a low-cost option: Limit file size to make it "safe" and remove the format a bit later.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2877v9.17 cannot be compiled on a system without libnghttp2 library2021-09-01T10:37:04ZPetr Špačekpspacek@isc.orgv9.17 cannot be compiled on a system without libnghttp2 library### Summary
main branch cannot be compiled on a system without libnghttp2 library.
### BIND version used
00c376f34d6e4732e5bb68638db7fca488ae26d1
### Steps to reproduce
1. Start with a system without libnghttp2
2. Run ./configure '-...### Summary
main branch cannot be compiled on a system without libnghttp2 library.
### BIND version used
00c376f34d6e4732e5bb68638db7fca488ae26d1
### Steps to reproduce
1. Start with a system without libnghttp2
2. Run ./configure '--disable-doh'
3. Run make
### What is the current *bug* behavior?
Compilation fails:
```
main.c:104:10: fatal error: nghttp2/nghttp2.h: No such file or directory
104 | #include <nghttp2/nghttp2.h>
```
Also, it seems that `--with-libnghttp2=no` is not implied by `--disable-doh`, but using both switches at the same time does not fix the build.
### What is the expected *correct* behavior?
Compiles and works.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2875DoH code relies on HTTP headers processing order2021-08-25T08:02:29ZArtem BoldarievDoH code relies on HTTP headers processing orderDoH code makes assumptions regarding the HTTP (pseudo)header processing order. In particular, it assumes that `:method:` pseudo-header will be processed one of the first, which might not be true. In this case, the request will be treated...DoH code makes assumptions regarding the HTTP (pseudo)header processing order. In particular, it assumes that `:method:` pseudo-header will be processed one of the first, which might not be true. In this case, the request will be treated as a bad one.
The problem was found when testing the DoH code with `h2load`, an `HTTP/2` and `HTTP 1.1` benchmarking tool being developed by `libnghttp2` authors. The problem revealed itself only when testing `POST` requests (`GET` requests were fine).
```
h2load -t 8 -c 300 -m 100 -n 1000000 -d ~/projects/isc/request_data.bin -H "content-type:application/dns-message" https://doh.example.com/dns-query
```
In order to resolve the problem we need to move the checks which require certain headers to be processed first into `server_on_request_recv()`, which knows all the required context.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2874CPPFLAGS never passed down to compiler invocation2022-08-10T07:59:30ZMichael OsipovCPPFLAGS never passed down to compiler invocation### Summary
Compiler fails to find header files for libreadline because include directory is not passed:
```
/opt/aCC/bin/aCC -Ae -Ae -z -I/var/tmp/ports/work/bind-9.11.35 -I../.. -I./include -I/var/tmp/ports/work/bind-9.11.35/lib/dns/...### Summary
Compiler fails to find header files for libreadline because include directory is not passed:
```
/opt/aCC/bin/aCC -Ae -Ae -z -I/var/tmp/ports/work/bind-9.11.35 -I../.. -I./include -I/var/tmp/ports/work/bind-9.11.35/lib/dns/include -I../../lib/dns/include -I/var/tmp/ports/work/bind-9.11.35/lib/bind9/include -I../../lib/bind9/include -I/var/tmp/ports/work/bind-9.11.35/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/nothreads/include -I../../lib/isc/noatomic/include -I/var/tmp/ports/work/bind-9.11.35/lib/lwres/include -I../../lib/lwres/unix/include -I../../lib/lwres/include -I/var/tmp/ports/work/bind-9.11.35/lib/isccfg/include -I../../lib/isccfg/include -DVERSION=\"9.11.35\" -D_XOPEN_SOURCE_EXTENDED -g -Wl,+vnocompatwarnings +z +w1 +W 474,530,2193,2236 -c nslookup.c
...
"nslookup.c", line 56: error #3696-D: cannot open source file
"readline/readline.h"
#include <readline/readline.h>
^
"nslookup.c", line 58: error #3696-D: cannot open source file
"readline/history.h"
#include <readline/history.h>
...
2 errors detected in the compilation of "nslookup.c".
gmake[2]: *** [Makefile:245: nslookup.o] Error 2
gmake[2]: Leaving directory '/var/tmp/ports/work/bind-9.11.35/bin/dig'
gmake[1]: *** [Makefile:79: subdirs] Error 1
gmake[1]: Leaving directory '/var/tmp/ports/work/bind-9.11.35/bin'
gmake: *** [Makefile:88: subdirs] Error 1
```
### BIND version used
9.11.35
### Steps to reproduce
Have readline in a non-standard location, provide `-I...` with the path to readline header files in `CPPFLAGS`. `configure` properly detects it, but the variable is never actually passed to compiler invocation.
```
export PREFIX=/opt/ports
export LIBDIR=$PREFIX/lib/hpux32
export SYSCONFDIR=/etc/opt/ports
export CC=/opt/aCC/bin/aCC
export CXX=/opt/aCC/bin/aCC
export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
export CPPFLAGS="-I$PREFIX/include"
export LDFLAGS="-L$LIBDIR"
$CONFIGURE --sysconfdir=$SYSCONFDIR --localstatedir=/var --disable-threads \
--with-gssapi=$PREFIX/bin/krb5-config \
--with-libxml2=no --with-readline --with-eddsa=no --with-zlib=no --with-python=no \
--disable-rpz-nsip --disable-rpz-nsdname --with-openssl=no --with-libxml2=no
```
So readline is available from `CPPFLAGS` and `LDFLAGS`.
`configure` then says:
```
configure: checking for readline with -ledit
checking for readline... no
configure: checking for readline with -ledit -lterminfo
checking for readline... no
configure: checking for readline with -ledit -ltermcap
checking for readline... no
configure: checking for readline with -ledit -lncurses
checking for readline... no
configure: checking for readline with -ledit -lcurses
checking for readline... no
configure: checking for readline with -lreadline
checking for readline... (cached) no
configure: checking for readline with -lreadline -lterminfo
checking for readline... no
configure: checking for readline with -lreadline -ltermcap
checking for readline... no
configure: checking for readline with -lreadline -lncurses
checking for readline... no
configure: checking for readline with -lreadline -lcurses
checking for readline... yes
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes
```
### What is the current *bug* behavior?
`nslookup.c` cannot find readline headers.
### What is the expected *correct* behavior?
Pass `CPPFLAGS` down the line.
### Possible fixes
Naive fix:
```
# diff -u ./bin/dig/Makefile.orig ./bin/dig/Makefile
--- ./bin/dig/Makefile.orig 2021-08-20 00:03:59 +0000
+++ ./bin/dig/Makefile 2021-08-20 08:05:36 +0000
@@ -236,7 +236,7 @@
ALL_CPPFLAGS = \
${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
- ${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES}
+ ${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES} ${BUILD_CPPFLAGS}
ALL_CFLAGS = ${EXT_CFLAGS} ${ALL_CPPFLAGS} ${CFLAGS} \
${ALWAYS_WARNINGS} ${STD_CWARNINGS} ${CWARNINGS}
```
After I have applied the fix:
```
root@deblndw024v:/var/tmp/ports/work/bind-9.11.35
# ldd ./bin/dig/nslookup
./bin/dig/nslookup:
libreadline.so.8 => /opt/ports/lib/hpux32/libreadline.so.8
libxcurses.so.1 => /usr/lib/hpux32/libxcurses.so.1
libgssapi_krb5.2 => /opt/ports/lib/hpux32/libgssapi_krb5.2
libkrb5.3 => /opt/ports/lib/hpux32/libkrb5.3
libk5crypto.3 => /opt/ports/lib/hpux32/libk5crypto.3
libcom_err.3 => /opt/ports/lib/hpux32/libcom_err.3
libnsl.so.1 => /usr/lib/hpux32/libnsl.so.1
libxnet.so.1 => /usr/lib/hpux32/libxnet.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1
libkrb5support.0 => /opt/ports/lib/hpux32/libkrb5support.0
libintl.so.10 => /opt/ports/lib/hpux32/libintl.so.10
libc.so.1 => /usr/lib/hpux32/libc.so.1
libxti.so.1 => /usr/lib/hpux32/libxti.so.1
libxti.so.1 => /usr/lib/hpux32/libxti.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libiconv.so.8 => /opt/ports/lib/hpux32/libiconv.so.8
libc.so.1 => /usr/lib/hpux32/libc.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2873configure.ac in 9.11.35 contains a syntactically invalid test2021-10-18T13:27:54ZMichael Osipovconfigure.ac in 9.11.35 contains a syntactically invalid test### Summary
My shell tells me:
```
Compiler: /opt/aCC/bin/aCC -Ae -Ae -z
./configure[136]: ==: A test command parameter is not valid.
aCC: HP C/aC++ B3910B A.06.29 [Oct 18 2016]
```
### BIND version used
9.11.35
### Steps to repr...### Summary
My shell tells me:
```
Compiler: /opt/aCC/bin/aCC -Ae -Ae -z
./configure[136]: ==: A test command parameter is not valid.
aCC: HP C/aC++ B3910B A.06.29 [Oct 18 2016]
```
### BIND version used
9.11.35
### Steps to reproduce
Run `configure` with a non-GCC compiler
### What is the current *bug* behavior?
Test is not executed.
### What is the expected *correct* behavior?
Test is not executed.
### Relevant configuration files
I have reported the same issue with MIT Kerberos seven years ago: https://github.com/krb5/krb5/commit/fefd465614f11f374f5ff183e6eb6cbc1b550de5
### Possible fixes
```patch
# diff -u configure.ac.orig configure.ac
--- configure.ac.orig 2021-08-19 22:44:23 +0000
+++ configure.ac 2021-08-19 22:45:46 +0000
@@ -5257,7 +5257,7 @@
[
SO_CFLAGS="-fPIC"
])
- AS_IF([test "$GCC" = "yes"],[
+ AS_IF([test "X$GCC" = "Xyes"],[
SO_CFLAGS="-fPIC"
AS_IF([test -z "$SO_LD"],
[AS_IF([test "$use_libtool" = "yes"],[
@@ -5769,7 +5769,7 @@
echo " localstatedir: $localstatedir"
echo "-------------------------------------------------------------------------------"
echo "Compiler: $CC"
- if test "yes" == "$GCC"; then
+ if test "X$GCC" = "Xyes" ; then
$CC --version 2>&1 | sed 's/^/ /'
else
case "$host_os" in
```
I have also applied the same pattern done by other `$GCC` checks.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2872map file format incompatibility causes crash (v9.16.19 -> v9.16.20)2024-01-03T22:26:59ZPetr Menšíkmap file format incompatibility causes crash (v9.16.19 -> v9.16.20)<!--
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
After update from 9.16.19 to 9.16.20 named service crashes on (re)start
``lib/isc/rwlock.c:451: REQUIRE((__builtin_expect(!!((rwl) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(rwl))->magic == ((('R') << 24 | ('W') << 16 | ('L') << 8 | ('k')))), 1))) failed``
Seems to be related to slave download of root-servers.net, when it uses ``masterfile-format map;``
### BIND version used
```
BIND 9.16.20-RH (Extended Support Version) <id:26db37f>
running on Linux x86_64 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul 20 20:27:29 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.2.1 20210728 (Red Hat 11.2.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
- systemctl restart named
### What is the current *bug* behavior?
```
srp 19 13:43:03 menpad named[1307081]: starting BIND 9.16.20-RH (Extended Support Version) <id:26db37f>
srp 19 13:43:03 menpad named[1307081]: running on Linux x86_64 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul 20 20:27:29 UTC 20>
srp 19 13:43:03 menpad named[1307081]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '->
srp 19 13:43:03 menpad named[1307081]: running as: named -u named -c /etc/named.conf
srp 19 13:43:03 menpad named[1307081]: compiled by GCC 11.2.1 20210728 (Red Hat 11.2.1-1)
srp 19 13:43:03 menpad named[1307081]: compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
srp 19 13:43:03 menpad named[1307081]: linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
srp 19 13:43:03 menpad named[1307081]: compiled with libxml2 version: 2.9.12
srp 19 13:43:03 menpad named[1307081]: linked to libxml2 version: 20912
srp 19 13:43:03 menpad named[1307081]: compiled with json-c version: 0.14
srp 19 13:43:03 menpad named[1307081]: linked to json-c version: 0.14
srp 19 13:43:03 menpad named[1307081]: compiled with zlib version: 1.2.11
srp 19 13:43:03 menpad named[1307081]: linked to zlib version: 1.2.11
srp 19 13:43:03 menpad named[1307081]: ----------------------------------------------------
srp 19 13:43:03 menpad named[1307081]: BIND 9 is maintained by Internet Systems Consortium,
srp 19 13:43:03 menpad named[1307081]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
srp 19 13:43:03 menpad named[1307081]: corporation. Support and training for BIND 9 are
srp 19 13:43:03 menpad named[1307081]: available at https://www.isc.org/support
srp 19 13:43:03 menpad named[1307081]: ----------------------------------------------------
srp 19 13:43:03 menpad named[1307081]: adjusted limit on open files from 1073741816 to 1048576
srp 19 13:43:03 menpad named[1307081]: found 4 CPUs, using 4 worker threads
srp 19 13:43:03 menpad named[1307081]: using 4 UDP listeners per interface
srp 19 13:43:03 menpad named[1307081]: using up to 21000 sockets
srp 19 13:43:03 menpad named[1307081]: loading configuration from '/etc/named.conf'
srp 19 13:43:03 menpad named[1307081]: reading built-in trust anchors from file '/etc/named.root.key'
srp 19 13:43:03 menpad named[1307081]: looking for GeoIP2 databases in '/usr/share/GeoIP'
srp 19 13:43:03 menpad named[1307081]: opened GeoIP2 database '/usr/share/GeoIP/GeoLite2-Country.mmdb'
srp 19 13:43:03 menpad named[1307081]: opened GeoIP2 database '/usr/share/GeoIP/GeoLite2-City.mmdb'
srp 19 13:43:03 menpad named[1307081]: opened GeoIP2 database '/usr/share/GeoIP/GeoLite2-ASN.mmdb'
srp 19 13:43:03 menpad named[1307081]: statistics channel listening on 127.0.0.1#80
srp 19 13:43:03 menpad named[1307081]: using default UDP/IPv4 port range: [32768, 60999]
srp 19 13:43:03 menpad named[1307081]: using default UDP/IPv6 port range: [32768, 60999]
srp 19 13:43:03 menpad named[1307081]: listening on IPv4 interface lo, 127.0.0.1#8053
srp 19 13:43:03 menpad named[1307081]: listening on IPv4 interface virbr0, 192.168.122.1#8053
srp 19 13:43:03 menpad named[1307081]: listening on IPv4 interface virbr0, 192.168.122.2#53
srp 19 13:43:03 menpad named[1307081]: listening on IPv6 interface lo, ::1#53
srp 19 13:43:03 menpad named[1307081]: generating session key for dynamic DNS
srp 19 13:43:03 menpad named[1307081]: Migrating zones from NZF file '3e8286044388886e.nzf' to NZD database 'v6.nzd'
srp 19 13:43:03 menpad named[1307081]: loading NZD zone count from 'libvirt.nzd' for view 'libvirt'
srp 19 13:43:03 menpad named[1307081]: NZD database 'libvirt.nzd' contains 0 zones
srp 19 13:43:03 menpad named[1307081]: loading NZD zone count from 'default.nzd' for view 'default'
srp 19 13:43:03 menpad named[1307081]: NZD database 'default.nzd' contains 0 zones
srp 19 13:43:03 menpad named[1307081]: sizing zone task pool based on 80 zones
srp 19 13:43:03 menpad named[1307081]: zone 'example.com.' allows unsigned updates from remote hosts, which is insecure
srp 19 13:43:03 menpad named[1307081]: loading NZD configs from 'v6.nzd' for view 'v6'
srp 19 13:43:03 menpad named[1307081]: none:102: 'max-cache-size 90%' - setting to 17465MB (out of 19406MB)
srp 19 13:43:03 menpad named[1307081]: set up managed keys zone for view v6, file '/var/named/dynamic/v6.mkeys'
srp 19 13:43:03 menpad named[1307081]: automatic empty zone: view v6: 16.172.IN-ADDR.ARPA
...
srp 19 13:43:04 menpad named[1307081]: zone cname/IN/v6: loaded serial 0
srp 19 13:43:04 menpad named[1307081]: ../../../lib/isc/rwlock.c:451: REQUIRE((__builtin_expect(!!((rwl) != ((void *)0)>
srp 19 13:43:04 menpad named[1307081]: #0 0x56251f0e3701 in ??
srp 19 13:43:04 menpad named[1307081]: #1 0x7f352cb973c0 in ??
srp 19 13:43:04 menpad named[1307081]: #2 0x7f352cbc172a in ??
srp 19 13:43:04 menpad named[1307081]: #3 0x7f352cbc184d in ??
srp 19 13:43:04 menpad named[1307081]: #4 0x7f352cd27774 in ??
srp 19 13:43:04 menpad named[1307081]: #5 0x7f352cd2546e in ??
srp 19 13:43:04 menpad named[1307081]: #6 0x7f352cd31130 in ??
srp 19 13:43:04 menpad named[1307081]: #7 0x7f352cdbc40f in ??
srp 19 13:43:04 menpad named[1307081]: #8 0x7f352cdbc5d5 in ??
srp 19 13:43:04 menpad named[1307081]: #9 0x7f352cbd1e9d in ??
srp 19 13:43:04 menpad named[1307081]: #10 0x7f352cbbd229 in ??
srp 19 13:43:04 menpad named[1307081]: #11 0x7f352cbbd3a5 in ??
srp 19 13:43:04 menpad named[1307081]: #12 0x7f352cbbdb97 in ??
srp 19 13:43:04 menpad named[1307081]: #13 0x7f352c95891d in ??
srp 19 13:43:04 menpad named[1307081]: #14 0x7f352c971ced in ??
srp 19 13:43:04 menpad named[1307081]: #15 0x7f352c9618e4 in ??
srp 19 13:43:04 menpad named[1307081]: #16 0x7f352cbbd45b in ??
srp 19 13:43:04 menpad named[1307081]: #17 0x7f352cbcfb23 in ??
srp 19 13:43:04 menpad named[1307081]: #18 0x7f352c63e299 in ??
srp 19 13:43:04 menpad named[1307081]: #19 0x7f352c564353 in ??
srp 19 13:43:04 menpad named[1307081]: exiting (due to assertion failure)
srp 19 13:43:05 menpad systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE
```
### What is the expected *correct* behavior?
Should just start as usual
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x00007f352c48a8a4 in __GI_abort () at abort.c:79
#2 0x000056251f0e0695 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>,
cond=<optimized out>) at ../../../bin/named/main.c:270
#3 0x00007f352cb973c0 in isc_assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>,
cond=<optimized out>) at ../../../lib/isc/assertions.c:46
#4 0x00007f352cbc172a in isc_rwlock_trylock (rwl=rwl@entry=0x7f35100037c0, type=type@entry=isc_rwlocktype_read)
at ../../../lib/isc/rwlock.c:451
#5 0x00007f352cbc184d in isc_rwlock_lock (rwl=0x7f35100037c0, type=type@entry=isc_rwlocktype_read)
at ../../../lib/isc/rwlock.c:440
#6 0x00007f352cd27774 in zone_findrdataset (db=0x7f35255e7600, node=0x7f352cee8818, version=<optimized out>,
type=<optimized out>, covers=<optimized out>, now=0, rdataset=0x7f352a3d42e0, sigrdataset=0x0)
at ../../../lib/dns/rbtdb.c:5754
#7 0x00007f352cd2546e in iszonesecure (db=0x7f35255e7600, version=0x7f35255e9640, origin=0x7f352cee8818)
at ../../../lib/dns/rbtdb.c:2334
#8 0x00007f352cd31130 in endload (db=0x7f35255e7600, callbacks=0x7f352a3d4420) at ../../../lib/dns/rbtdb.c:7754
#9 0x00007f352cdbc40f in zone_startload (loadtime=..., zone=0x7f35206487a0, db=0x7f35255e7600)
at ../../../lib/dns/zone.c:2727
#10 zone_load (zone=0x7f35206487a0, flags=0, locked=locked@entry=true) at ../../../lib/dns/zone.c:2285
#11 0x00007f352cdbc5d5 in zone_asyncload (task=0x7f35269deb50, event=<optimized out>) at ../../../lib/dns/zone.c:2346
#12 0x00007f352cbd1e9d in task_run (task=0x7f35269deb50) at ../../../lib/isc/task.c:857
#13 isc_task_run (task=0x7f35269deb50) at ../../../lib/isc/task.c:950
#14 0x00007f352cbbd229 in isc__nm_async_task (worker=0x56251fbf1d20, ev0=0x7f35269e7a38)
at netmgr/../../../../lib/isc/netmgr/netmgr.c:873
#15 process_netievent (worker=worker@entry=0x56251fbf1d20, ievent=0x7f35269e7a38)
at netmgr/../../../../lib/isc/netmgr/netmgr.c:958
#16 0x00007f352cbbd3a5 in process_queue (worker=worker@entry=0x56251fbf1d20, type=type@entry=NETIEVENT_TASK)
at netmgr/../../../../lib/isc/netmgr/netmgr.c:1027
#17 0x00007f352cbbdb97 in process_all_queues (worker=0x56251fbf1d20) at netmgr/../../../../lib/isc/netmgr/netmgr.c:798
#18 async_cb (handle=0x56251fbf2080) at netmgr/../../../../lib/isc/netmgr/netmgr.c:827
#19 0x00007f352c95891d in uv__async_io (loop=0x56251fbf1d30, w=<optimized out>, events=<optimized out>)
at src/unix/async.c:163
#20 0x00007f352c971ced in uv__io_poll (loop=0x56251fbf1d30, timeout=<optimized out>) at src/unix/linux-core.c:462
#21 0x00007f352c9618e4 in uv_run (loop=loop@entry=0x56251fbf1d30, mode=mode@entry=UV_RUN_DEFAULT)
at src/unix/core.c:385
#22 0x00007f352cbbd45b in nm_thread (worker0=0x56251fbf1d20) at netmgr/../../../../lib/isc/netmgr/netmgr.c:733
#23 0x00007f352cbcfb23 in isc__trampoline_run (arg=0x56251fbdf750) at ../../../lib/isc/trampoline.c:191
#24 0x00007f352c63e299 in start_thread (arg=0x7f352a3d8640) at pthread_create.c:481
--Type <RET> for more, q to quit, c to continue without paging--
#25 0x00007f352c564353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
### Possible fixes
Not yet knownSeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2871dnssec-cds uses SHA-1 CDS records when generating DS records2021-09-03T13:35:16ZMichał Kępieńdnssec-cds uses SHA-1 CDS records when generating DS recordsWhen `dnssec-cds` copies CDS records to make DS records, its `-a
algorithm` option does not have any effect. This means that if the child
zone is signed with older software that generates SHA-1 CDS records,
`dnssec-cds` (by default) crea...When `dnssec-cds` copies CDS records to make DS records, its `-a
algorithm` option does not have any effect. This means that if the child
zone is signed with older software that generates SHA-1 CDS records,
`dnssec-cds` (by default) creates SHA-1 DS records, in violation of [RFC
8624][1].
The implementation of the `-a algorithm` option should be changed so
that it also affects the process of creating DS records from CDS
records. `dnssec-cds` should also not create SHA-1 DS records by
default.
[1]: https://datatracker.ietf.org/doc/html/rfc8624September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2870Address test timing false positive in rndc system test.2021-08-31T13:07:22ZMark AndrewsAddress test timing false positive in rndc system test.Job [#1931097](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1931097) failed for fa52a4c82e0e61c2386edaf797371b5ccbb7d608:
```
8738I:rndc:checking update (68)
8739I:rndc:rndc freeze
8740I:rndc:edit zone files
8741I:rndc:rndc thaw
874...Job [#1931097](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1931097) failed for fa52a4c82e0e61c2386edaf797371b5ccbb7d608:
```
8738I:rndc:checking update (68)
8739I:rndc:rndc freeze
8740I:rndc:edit zone files
8741I:rndc:rndc thaw
8742I:rndc:rndc reload
8743I:rndc:ns7 server reload successful
8744I:rndc:checking zone file edits are loaded (69)
8745I:rndc:failed
```
The test digs where executed before the zone loading was complete.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2868SVCB fromwire should reject zero length ALPN elements2021-08-19T09:09:43ZMark AndrewsSVCB fromwire should reject zero length ALPN elementsFromtext already prevents these.
```
(lldb) parray 12 rdata->data
(unsigned char *) $5 = 0x0000000104009201 " " {
(unsigned char) [0] = ' '
(unsigned char) [1] = ' '
(unsigned char) [2] = '\0'
(unsigned char) [3] = '\0'
(unsi...Fromtext already prevents these.
```
(lldb) parray 12 rdata->data
(unsigned char *) $5 = 0x0000000104009201 " " {
(unsigned char) [0] = ' '
(unsigned char) [1] = ' '
(unsigned char) [2] = '\0'
(unsigned char) [3] = '\0'
(unsigned char) [4] = '\x01'
(unsigned char) [5] = '\0'
(unsigned char) [6] = '\x05'
(unsigned char) [7] = '\0'
(unsigned char) [8] = '\0'
(unsigned char) [9] = '\0'
(unsigned char) [10] = '\0'
(unsigned char) [11] = '\0'
}
(lldb)
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2867SVCB fromwire needs to check that alpn is present when no-default-alpn is pre...2021-08-19T09:05:24ZMark AndrewsSVCB fromwire needs to check that alpn is present when no-default-alpn is presentA similar check already exists in from text.A similar check already exists in from text.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/28666b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 breaks using with MIT Kerberos2021-10-04T09:27:12ZMichael Osipov6b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 breaks using with MIT Kerberos### Summary
Change in 6b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 passes incorrect args to `krb5-config`.
### BIND version used
bind-9.16.19
### Steps to reproduce
Try compile with Kerberos 5 release 1.19.2 and pass to `./configure` `-...### Summary
Change in 6b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 passes incorrect args to `krb5-config`.
### BIND version used
bind-9.16.19
### Steps to reproduce
Try compile with Kerberos 5 release 1.19.2 and pass to `./configure` `--with-gssapi=$PREFIX/bin/krb5-config`.
### What is the current *bug* behavior?
The linker test fails:
```
configure:17572: checking krb5-config linking as -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err
configure:17585: /opt/aCC/bin/aCC -Ae -o conftest -g -mt -I/opt/ports/include -L/opt/ports/lib/hpux32 conftest.c -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err >&5
"conftest.c", line 112: warning #2223-D: function "gss_acquire_cred" declared implicitly
gss_acquire_cred();krb5_init_context()
^
"conftest.c", line 112: warning #2223-D: function "krb5_init_context" declared implicitly
gss_acquire_cred();krb5_init_context()
^
ld: Unsatisfied symbol "gss_acquire_cred" in file conftest.o
1 error.
configure:17585: $? = 1
```
### What is the expected *correct* behavior?
Linker test to pass
### Possible fixes
The problem is incorrect understanding of `krb5-config`. It does *not* accept more than one `library` request and if more than one is passed, the latter always overrides the former:
```
# krb5-config --libs gssapi krb5
-L/opt/ports/lib/hpux32 -Wl,+b,/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err
# # extracted test
# /opt/aCC/bin/aCC -Ae -o conftest -g -mt -I/opt/ports/include -L/opt/ports/lib/hpux32 conftest.c -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err
"conftest.c", line 4: warning #2223-D: function "gss_acquire_cred" declared
implicitly
gss_acquire_cred();krb5_init_context()
^
"conftest.c", line 4: warning #2223-D: function "krb5_init_context" declared
implicitly
gss_acquire_cred();krb5_init_context()
^
ld: Unsatisfied symbol "gss_acquire_cred" in file conftest.o
1 error.
```
Correct is to pass `gssapi` *only*, it internally depends on `krb5` and will add all required libraries, name for GSS-API `gss_` AND KRB5 `krb5_`:
```
# krb5-config --libs gssapi
-L/opt/ports/lib/hpux32 -Wl,+b,/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
```
thus
```
/opt/aCC/bin/aCC -Ae -o conftest -g -mt -I/opt/ports/include -L/opt/ports/lib/hpux32 conftest.c -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
"conftest.c", line 4: warning #2223-D: function "gss_acquire_cred" declared
implicitly
gss_acquire_cred();krb5_init_context()
^
"conftest.c", line 4: warning #2223-D: function "krb5_init_context" declared
implicitly
gss_acquire_cred();krb5_init_context()
# file ./conftest
./conftest: ELF-32 executable object file - IA64
# ldd ./conftest
./conftest:
libgssapi_krb5.2 => /opt/ports/lib/hpux32/libgssapi_krb5.2
libkrb5.3 => /opt/ports/lib/hpux32/libkrb5.3
libk5crypto.3 => /opt/ports/lib/hpux32/libk5crypto.3
libcom_err.3 => /opt/ports/lib/hpux32/libcom_err.3
libpthread.so.1 => /usr/lib/hpux32/libpthread.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1
libkrb5support.0 => /opt/ports/lib/hpux32/libkrb5support.0
libintl.so.10 => /opt/ports/lib/hpux32/libintl.so.10
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libiconv.so.8 => /opt/ports/lib/hpux32/libiconv.so.8
libc.so.1 => /usr/lib/hpux32/libc.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1
```
fix:
```
# sed -i"" "s#--libs gssapi krb5#--libs gssapi#g" configure
....
checking for GSSAPI library... trying /opt/ports/bin/krb5-config
checking gssapi.h usability... yes
checking gssapi.h presence... yes
checking for gssapi.h... yes
checking gssapi/gssapi.h usability... yes
checking gssapi/gssapi.h presence... yes
checking for gssapi/gssapi.h... yes
checking krb5/krb5.h usability... yes
checking krb5/krb5.h presence... yes
checking for krb5/krb5.h... yes
checking krb5.h usability... yes
checking krb5.h presence... yes
checking for krb5.h... yes
checking krb5-config linking as -L/opt/ports/lib/hpux32 -Wl,+b,/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err... krb5-config: linked
...
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2864BIND-9.16.19: Resolver fetch process hang2021-08-17T06:55:31Znanwn147929@alibaba-inc.comBIND-9.16.19: Resolver fetch process hang<!--
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
Sending outgoing resquery process could be hang for seconds, which is abnormal.
### BIND version used
BIND 9.16.19-RedHat-9.16.19-20210816135007.alios7 (Stable Release) <id:df0e751>
running on Linux x86_64 3.10.0-327.ali2012.alios7.x86_64 #1 SMP Mon Oct 9 14:09:14 CST 2017
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-libtool' '--localstatedir=/var' '--enable-epoll' '--with-pic' '--with-python=/home/tops/bin/python2.7' '--with-python-install-dir=/home/tops' '--disable-geoip' '--with-tuning=large' '--enable-querytrace' '--enable-auto-validation=no' '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 ' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig:/usr/lib64/pkgconfig/:/home/admin/246_20210813142442272_220712980_code/rpm_workspace/rpm/.dep_create/lib/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-4)
compiled with OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libuv version: 1.35.0
linked to libuv version: 1.35.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
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
Not sure, supposing some specific flow would cause the issue.
### What is the current *bug* behavior?
Sending outgoing resquery process could be hang for seconds, which can be detected by querytrace(enabled by compiling):
```
17-Aug-2021 00:41:27.982 fetch: game-redis-1159.knight.game.12406.270199.-100/CNAME
17-Aug-2021 00:41:27.982 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): create
17-Aug-2021 00:41:27.982 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): join
17-Aug-2021 00:41:27.982 fetch 0x7fa699adedf0 (fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME)): created
17-Aug-2021 00:41:27.982 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): start
17-Aug-2021 00:41:27.982 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): try fctx->qc=0
17-Aug-2021 00:41:27.982 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): cancelqueries
17-Aug-2021 00:41:27.982 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): getaddresses fctx->depth=0
17-Aug-2021 00:41:27.982 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): query
17-Aug-2021 00:41:27.982 resquery 0x7fa604d05360 (fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME)): send
17-Aug-2021 00:41:29.122 resquery 0x7fa604d05360 (fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME)): sent
17-Aug-2021 00:41:29.123 resquery 0x7fa604d05360 (fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME)): udpconnected
17-Aug-2021 00:41:29.123 resquery 0x7fa604d05360 (fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME)): senddone
17-Aug-2021 00:41:29.152 resquery 0x7fa604d05360 (fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME)): response
17-Aug-2021 00:41:29.152 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): rctx_answer
17-Aug-2021 00:41:29.152 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): cache_message
17-Aug-2021 00:41:29.152 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): cache_name
17-Aug-2021 00:41:29.152 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): findnoqname
17-Aug-2021 00:41:29.153 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): clone_results
17-Aug-2021 00:41:29.153 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): [result: success] query canceled in response(); responding
17-Aug-2021 00:41:29.153 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): cancelquery
17-Aug-2021 00:41:29.153 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): done
17-Aug-2021 00:41:29.153 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): stopqueries
17-Aug-2021 00:41:29.153 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): cancelqueries
17-Aug-2021 00:41:29.153 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): sendevents
17-Aug-2021 00:41:29.158 fetch 0x7fa699adedf0 (fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME)): destroyfetch
17-Aug-2021 00:41:29.158 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): shutdown
17-Aug-2021 00:41:29.187 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): doshutdown
17-Aug-2021 00:41:29.187 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): stopqueries
17-Aug-2021 00:41:29.187 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): cancelqueries
17-Aug-2021 00:41:29.187 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): unlink
17-Aug-2021 00:41:29.187 fctx 0x7fa60be39de0(game-redis-1159.knight.game.12406.270199.-100/CNAME): destroy
```
It take more than 1 second between resquery "send" and be "sent". Meanwhile, all working threads are in D(uninterruptible sleep) state:
![7CD8A3A0-FB10-495D-837A-3A07E0401566](/uploads/287ff5842bdd12f38a2542c0bd6c8d1c/7CD8A3A0-FB10-495D-837A-3A07E0401566.png)
### What is the expected *correct* behavior?
Not hang.
(What you should see instead.)
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2863WSL crash with Dig when querying DoH server2021-08-16T11:29:58ZtriaticWSL crash with Dig when querying DoH server<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Following the decision to remove the native Windows binaries I would like to use Dig under Windows Subsystem for Linux (WSL, Ubuntu on Windows). Specifically I would like to use Dig to query DNS-over-HTTPS, so have installed the dev PPA. However a crash is observed when running DoH queries on WSL, but no such crash for non-DoH queries.
### BIND version used
```
C:\>wsl dig -v
DiG 9.17.16-1+ubuntu20.04.1+isc+1-Ubuntu
```
### Steps to reproduce
Install Ubuntu on Windows, add the dev PPA, and run the following command:
`wsl dig +https @dns.google isc.org A`
### What is the current *bug* behavior?
Error output:
`netmgr/tcp.c:135: fatal error: RUNTIME_CHECK(result == 0) failed`
### What is the expected *correct* behavior?
The A record for isc.org.
This is the output for non DoH:
```
C:\>wsl dig @dns.google isc.org A
; <<>> DiG 9.17.16-1+ubuntu20.04.1+isc+1-Ubuntu <<>> @dns.google isc.org A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40794
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;isc.org. IN A
;; ANSWER SECTION:
isc.org. 59 IN A 149.20.1.66
;; Query time: 27 msec
;; SERVER: 8.8.8.8#53(dns.google) (UDP)
;; WHEN: Mon Aug 16 11:19:05 BST 2021
;; MSG SIZE rcvd: 52
```
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
N/ASeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2861Extend the doth system test with dig invocations doing name resolution agains...2021-09-01T10:43:40ZArtem BoldarievExtend the doth system test with dig invocations doing name resolution against an IPv6 addressCurrently the `doth` system test uses IPv4 addresses exclusively. We might want to extend it with `dig` invocations against a server listening on an IPv6 address. That should help preventing issues like #2858, #2860.Currently the `doth` system test uses IPv4 addresses exclusively. We might want to extend it with `dig` invocations against a server listening on an IPv6 address. That should help preventing issues like #2858, #2860.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2860The DoH endpoint URL in dig might get prepared in wrong format2021-08-31T13:41:21ZArtem BoldarievThe DoH endpoint URL in dig might get prepared in wrong formatOne of the causes why the problem #2858 appeared is that the URL in the DoH code might get generated in wrong format at least when IPv6 is used. In particular, in the issue `dig` was trying to connect to `https://::1:444/dns-query` inste...One of the causes why the problem #2858 appeared is that the URL in the DoH code might get generated in wrong format at least when IPv6 is used. In particular, in the issue `dig` was trying to connect to `https://::1:444/dns-query` instead of `https://[::1]:444/dns-query`. Obviously, this issue prevents `dig` from querying servers via its IPv6 addresses (querying hostnames available via IPv6 works fine).
Also, it will always generate a URL starting with `https://` regardless of the fact if we use HTTP with encryption or not.
So, while the fix for the problem reported is already prepared (!5319), this issue needs to be taken care of as well. The code which prepared the URL needs to be revisited.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldariev