BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-07T21:26:35Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4568isc_ht case insensitive matching is broken2024-03-07T21:26:35ZOndřej Surýisc_ht case insensitive matching is brokenThe `isc__ht_node_match()` ignores the case_sensitivity setting and always uses `memcmp()` that is case sensitive.The `isc__ht_node_match()` ignores the case_sensitivity setting and always uses `memcmp()` that is case sensitive.February 2024 (9.16.47/9.16.48, 9.16.47/9.16.48-S1, 9.18.23/9.18.24, 9.18.23/9.18.24-S1, 9.19.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/4566slow zone transfer takes longer than expected in statschannel test2024-02-21T23:36:33ZTom Krizekslow zone transfer takes longer than expected in statschannel test`statschannel` system test recently became more unstable, [failing](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4006014) on the following check:
```
2024-02-08 00:32:57 INFO:statschannel I:statschannel_tmp_0gqlueys:Wait for slo...`statschannel` system test recently became more unstable, [failing](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4006014) on the following check:
```
2024-02-08 00:32:57 INFO:statschannel I:statschannel_tmp_0gqlueys:Wait for slow zone transfer to complete (29)
2024-02-08 00:33:16 INFO:statschannel I:statschannel_tmp_0gqlueys:exceeded time limit waiting for literal 'zone example/IN: zone transfer finished: success' in ns3/named.run
2024-02-08 00:33:16 INFO:statschannel I:statschannel_tmp_0gqlueys:failed
```
The check in question uses `-T transferslowly` option which makes the code use `select()` with a one second timeout to delay the individual packets. `ns1` uses the `transfer-format one-answer;` for the transfer to `ns3`. The `example.db` zone has 8 records and the check allows 20 second timeout, which should be more than sufficient. However, the records are delayed more than expected on the sending side:
```
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': AXFR question section OK
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': AXFR authority section OK
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': AXFR started (serial 1)
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': starting maxtime timer 7200000 ms
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 77 bytes
08-Feb-2024 00:32:58.120 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 00:32:59.124 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 00:33:02.140 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 53 bytes
08-Feb-2024 00:33:05.152 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 785 bytes
08-Feb-2024 00:33:08.165 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 51 bytes
08-Feb-2024 00:33:11.177 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 50 bytes
08-Feb-2024 00:33:14.189 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 59 bytes
08-Feb-2024 00:33:17.201 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 71 bytes
08-Feb-2024 00:33:19.209 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': send: operation canceled
```
After the first three record are transmitted, each following record is delayed by just over 3 seconds (rather than 1 second). It could be caused by the load in the CI due to parallelization, but the fact this pattern (first 3 records have 1s delay, remaining record have 3s delay) repeats in another [job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4007776) makes this a bit suspicious:
```
08-Feb-2024 09:55:12.719 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 77 bytes
08-Feb-2024 09:55:13.719 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 09:55:14.724 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 09:55:17.728 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 53 bytes
08-Feb-2024 09:55:21.740 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 785 bytes
08-Feb-2024 09:55:24.748 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 51 bytes
08-Feb-2024 09:55:28.756 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 50 bytes
08-Feb-2024 09:55:31.765 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 59 bytes
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4565Come up with ideas how to align rwlock and cds_wfcq_head+cds_wfcq_tail2024-02-08T11:17:37ZOndřej SurýCome up with ideas how to align rwlock and cds_wfcq_head+cds_wfcq_tailThe rwlock struct and cds_wfcq_head+cds_wfcq_tail are not aligned just padded now.
Let's record this in an issue, so perhaps someone will have smart idea about the alignment.The rwlock struct and cds_wfcq_head+cds_wfcq_tail are not aligned just padded now.
Let's record this in an issue, so perhaps someone will have smart idea about the alignment.https://gitlab.isc.org/isc-projects/bind9/-/issues/4564slightly worse cold cache performance after the KeyTrap fix2024-02-24T07:52:45ZTom Krizekslightly worse cold cache performance after the KeyTrap fixThe keytrap fix (merged in isc-private/bind9!628) has a significant impact on client query latency during startup (cold cache) as well as increased memory consumption. Using `recursive-clients 1000;` yielded quite similar results to `100...The keytrap fix (merged in isc-private/bind9!628) has a significant impact on client query latency during startup (cold cache) as well as increased memory consumption. Using `recursive-clients 1000;` yielded quite similar results to `10000` (which was used for most charts in here).
## Cold cache latency
### :question: 9.18 cold cache UDP
![keytrap-cold-cache-latency-9.18](/uploads/9953460d5a50fb571f18c21ece5f7415/keytrap-cold-cache-latency-9.18.png)
#### load 15x
| | before | after |
| ------ | ------ | ----- |
| responses <2.0s | 91 % | 79 % |
| responses <100ms | 88 % | 75 % |
#### load 10x
| | before | after |
| ------ | ------ | ----- |
| responses <2.0s | 96 % | 89 % |
| responses <100ms | 92 % | 85 % |
#### load 5x
| | before | after |
| ------ | ------ | ----- |
| responses <2.0s | 99 % | 98 % |
| responses <100ms | 93 % | 92 % |
### :question: 9.16 cold cache UDP
![keytrap-cold-cache-latency-9.16](/uploads/795943f2c6c6959c15f30c9f41597976/keytrap-cold-cache-latency-9.16.png)
### :white_check_mark: 9.19 cold cache UDP
the impact for ~"v9.19" is quite minimal and I don't consider it an issue
![keytrap-cold-cache-latency-9.19](/uploads/d86be8aeb8170b8e596bd85666937a81/keytrap-cold-cache-latency-9.19.png)
### :question: 9.18 cold cache TCP
The performance drop can also be observed with TCP with much lower overall throughput.
![keytrap-hot-cache-latency-tcp-9.18](/uploads/b581e94d77c5c1cdc9e143fdfff3bac2/keytrap-hot-cache-latency-tcp-9.18.png)
## :white_check_mark: Hot cache latency
The good news is that it doesn't really affect performance with hot cache.
![keytrap-hot-cache-latency-9.18](/uploads/e1704c0c853dc5b6ab798e1821b4a7db/keytrap-hot-cache-latency-9.18.png)
## Memory consumption
### :question: 9.18 memory consumption UDP
The initial memory consumption also gets slightly higher:
![keytrap-memory-9.18](/uploads/7d89b5dbc594c64c57802e11418c03b6/keytrap-memory-9.18.png)
### :white_check_mark: 9.18 memory consumption TCP
While the memory consumption is slightly higher for TCP under load, I think this can be explained by the fact that some queries take longer time to resolve -> some connections might be open for a longer time, thus consume more resources than before.
![keytrap-memory-tcp-9.18](/uploads/88be13f12e69bb69fc7f6d917dc21e6f/keytrap-memory-tcp-9.18.png)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4563Dynamic ipsets updates following named requests2024-03-19T16:19:58ZBenoit AnquetinDynamic ipsets updates following named requests### Description
I propose a plugin that is able to update netfilter ipsets when some specific requests are received by `named`. This may be useful in a situation where:
* `named` is running on a LAN
* the same server is forwarding pack...### Description
I propose a plugin that is able to update netfilter ipsets when some specific requests are received by `named`. This may be useful in a situation where:
* `named` is running on a LAN
* the same server is forwarding packets to the internet and handles firewall rules
The use case can be:
* we block all outgoing traffic (all internet request must use a secured proxy)
* but for some internet servers we want to allow traffic based on the IPs that where securely given by `named`. The idea is if the request name matches a wildcard, it then adds the address to an A or AAAA ipset.
* this is useful for some 'approved' domains that have many public addresses and would more reliable than looping on the name.
### Request
I already have a working plugin that has the following features:
* independent plugin
* can be linked with libipset or libnftnl libraries (ipset or nft sets)
* reacts when an A or AAAA answer will be given to the client, and if the wildcards matches something in the set, it adds the address to it before answering to the client (in this case the answer will be a few ms longer, but this will allow success of the tcp connection afterwards)
* when there is no match the timings overhead is negligible
The configuration is as follows, for updating 'entertainment' ipset of filter nft table with all IP address that we got from \*.example.com :
```plaintext
plugin query "update-ipset.so" {
ipset entertainment {
sites {
*.example.com.;
*.other-example.com.;
};
ttl 3600;
nftable filter; family inet;
};
};
```
I made a patch that is working on my systems, however:
* I didn't made unit tests yet. I would like to see the community first feedbacks first
* I tried to follow the coding rules, and checked for memory leaks in different situations
### Links / references
[0001-Plugin-for-updating-ipsets-during-name-resolution.patch](/uploads/f5dbc3ceae31999eefcd4c8e23495e53/0001-Plugin-for-updating-ipsets-during-name-resolution.patch)https://gitlab.isc.org/isc-projects/bind9/-/issues/4562dispatch test needs to ignore unexpected sources2024-03-07T22:42:57ZMark Andrewsdispatch test needs to ignore unexpected sourcesJob [#3999076](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999076) failed for 30026fb052bbbefdb2416e4538c9dc973b000541:
```
FAILED dispatch/tests_connreset.py::test_connreset - dns.query.UnexpectedSource: got a response from ('10....Job [#3999076](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999076) failed for 30026fb052bbbefdb2416e4538c9dc973b000541:
```
FAILED dispatch/tests_connreset.py::test_connreset - dns.query.UnexpectedSource: got a response from ('10.53.0.3', 25547) instead of ('10.53.0.2', 25227)
```
dnspython supports ignoring unexpected responses
```
*ignore_unexpected*, a ``bool``. If ``True``, ignore responses from unexpected sources.
```
This will most probably need to be applied to most dns.query.udp calls.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4561Shutdown test doesn't log everything to named.run2024-03-07T22:43:03ZMark AndrewsShutdown test doesn't log everything to named.runThe rest of the system tests log everything to stderr using `-d 99 -g`. The named instances started by the shutdown test do not do this which causes logging to be lost at the start and at the end after logging has been shutdown, i.e. me...The rest of the system tests log everything to stderr using `-d 99 -g`. The named instances started by the shutdown test do not do this which causes logging to be lost at the start and at the end after logging has been shutdown, i.e. memory issues being reported. They use the logging clause.
This will also cause the system's log to be spammed with messages from the test system.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4560All tests for "make test" returning "ERROR" even though logs show most tests ...2024-03-26T10:30:37ZEric SchultzAll tests for "make test" returning "ERROR" even though logs show most tests passed### Summary
When I run "make test" after a successful configure/make, all of the tests throw "ERROR", but if you look at the log for each test or the xml output, it will show as passed.
### BIND version affected
bind-9.18.21
### St...### Summary
When I run "make test" after a successful configure/make, all of the tests throw "ERROR", but if you look at the log for each test or the xml output, it will show as passed.
### BIND version affected
bind-9.18.21
### Steps to reproduce
```
% cat /etc/redhat-release
Red Hat Enterprise Linux release 8.9 (Ootpa)
% cat /etc/oracle-release
Oracle Linux Server release 8.9
# Install required packages (though many of these are not listed as required on the BIND site! Namely the python RPMs.)
sudo yum install automake autoconf libtool libcap-devel python3-pytest python3 perl-Net-DNS python3-dns
# Download and install jemalloc RPMs from EPEL:
wget https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/j/jemalloc-5.2.1-2.el8.x86_64.rpm
wget https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/j/jemalloc-devel-5.2.1-2.el8.x86_64.rpm
sudo yum install jemalloc-5.2.1-2.el8.x86_64.rpm jemalloc-devel-5.2.1-2.el8.x86_64.rpm
```
Build accessory software as needed:
```
wget https://www.zlib.net/zlib-1.3.1.tar.gz
tar xzf zlib-1.3.1.tar.gz
cd zlib-1.3.1
./configure --prefix=/usr/local/zlib-1.3.1
make
make test
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# add /usr/local/zlib-1.3.1/lib
sudo ldconfig
wget https://www.openssl.org/source/openssl-3.0.13.tar.gz
tar xzf openssl-3.0.13.tar.gz
cd openssl-3.0.13
./config --prefix=/usr/local/openssl-3.0.13 --with-zlib-lib=/usr/local/zlib-1.3.1/lib
make
make test
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# update to /usr/local/openssl-3.0.13/lib64
sudo ldconfig
# Probably could use libuv RPM here but chose to get newest source
wget --no-check-certificate https://dist.libuv.org/dist/v1.47.0/libuv-v1.47.0.tar.gz
tar xzf libuv-v1.47.0.tar.gz
cd libuv-v1.47.0
sh autogen.sh
./configure --prefix=/usr/local/libuv-1.47.0
make
make check
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# add: /usr/local/libuv-1.47.0/lib
sudo ldconfig
# Now build BIND itself
wget https://downloads.isc.org/isc/bind9/9.18.21/bind-9.18.21.tar.xz
tar xJf bind-9.18.21.tar.xz
cd bind-9.18.21
export PKG_CONFIG_PATH=/usr/local/openssl-3.0.13/lib64/pkgconfig:/usr/local/zlib-1.3.1/lib/pkgconfig:/usr/local/libuv-1.47.0/lib/pkgconfig
./configure --prefix=/usr/local/bind-9.18.21 --mandir=/usr/local/bind-9.18.21/man --with-openssl=/usr/local/openssl-3.0.13 --with-jemalloc --with-gnu-ld --with-libxml2=no --with-gssapi=no --disable-auto-validation --disable-doh
make
sudo bin/tests/system/ifconfig.sh up
make test
```
### What is the current *bug* behavior?
"make test" will start generating ERROR for each test:
<snip>
make check-TESTS
make[6]: Entering directory '/tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system'
make[7]: Entering directory '/tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system'
ERROR: rpz
ERROR: rpzrecurse
ERROR: serve-stale
ERROR: timeouts
ERROR: upforwd
<snip>
But the log itself (and .xml) shows 100% PASSED:
```
% tail bin/tests/system/rpz.log
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:checking that rewriting CD=1 queries handles pending data correctly (29)
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:status (native RPZ sub-test): 0 (pass)
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:attempting to configure servers with DNSRPS...
2024-02-05 08:11:32 INFO:rpz I:rpz_tmp_mrhdwc8_:DNSRPS disabled at compile time
2024-02-05 08:11:32 INFO:rpz I:rpz_tmp_mrhdwc8_:DNSRPS sub-test skipped
PASSED [100%]
generated xml file: /home/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system/rpz.xml
========================== 1 passed in 98.66 seconds ===========================
ERROR rpz (exit status: 99)
```
Every single test has exit status 99.
### What is the expected *correct* behavior?
These tests should almost all have result PASS, when checking the logs (except for two that show 50% PASSED):
```
% grep PASSED bin/tests/system/test-suite.log
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [ 50%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [ 50%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
```
### Relevant configuration files
I don't believe there is anything relevant for the build.
### Relevant logs
```
% cat bin/tests/system/rpz.log
============================= test session starts ==============================
platform linux -- Python 3.6.8, pytest-3.4.2, py-1.5.3, pluggy-0.6.0 -- /bin/python3
cachedir: ../.pytest_cache
rootdir: /tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system, inifile: pytest.ini
collecting ... collected 1 item
tests_sh_rpz.py::test_rpz
-------------------------------- live log setup --------------------------------
2024-02-05 09:23:29 INFO:rpz test started: rpz/tests_sh_rpz.py
2024-02-05 09:23:29 INFO:rpz using port range: <25322, 25341>
-------------------------------- live log call ---------------------------------
2024-02-05 09:23:35 INFO:rpz I:rpz_tmp_zaujh5m9:running native RPZ sub-test
2024-02-05 09:23:35 INFO:rpz I:rpz_tmp_zaujh5m9:checking QNAME rewrites (1)
2024-02-05 09:23:42 INFO:rpz I:rpz_tmp_zaujh5m9:checking NXDOMAIN/NODATA action on QNAME trigger (2)
2024-02-05 09:23:46 INFO:rpz I:rpz_tmp_zaujh5m9:checking IP rewrites (3)
2024-02-05 09:23:48 INFO:rpz I:rpz_tmp_zaujh5m9:ns2 zone reload queued
2024-02-05 09:23:49 INFO:rpz I:rpz_tmp_zaujh5m9:ns2 zone reload queued
2024-02-05 09:23:50 INFO:rpz I:rpz_tmp_zaujh5m9:checking radix tree deletions (4)
2024-02-05 09:23:52 INFO:rpz I:rpz_tmp_zaujh5m9:checking NSDNAME rewrites (5)
2024-02-05 09:23:54 INFO:rpz I:rpz_tmp_zaujh5m9:checking NSIP rewrites (6)
2024-02-05 09:23:55 INFO:rpz I:rpz_tmp_zaujh5m9:checking walled garden NSIP rewrites (7)
2024-02-05 09:23:56 INFO:rpz I:rpz_tmp_zaujh5m9:checking policy overrides (8)
2024-02-05 09:24:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking crashes (9)
2024-02-05 09:24:04 INFO:rpz I:rpz_tmp_zaujh5m9:performance not checked; queryperf not available
2024-02-05 09:24:06 INFO:rpz I:rpz_tmp_zaujh5m9:checking that ns3 with broken rpz does not crash (10)
2024-02-05 09:24:11 INFO:rpz I:rpz_tmp_zaujh5m9:checking if rpz survives a certain class of failed reconfiguration attempts (11)
2024-02-05 09:24:12 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz failed update will keep previous rpz rules (12)
2024-02-05 09:24:13 INFO:rpz I:rpz_tmp_zaujh5m9:ns3 zone reload queued
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking reload of a mixed-case RPZ zone (13)
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:ns3 zone reload queued
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking that ttl values are not zeroed when qtype is '*' (14)
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz updates/transfers with parent nodes added after children (15)
2024-02-05 09:24:56 INFO:rpz I:rpz_tmp_zaujh5m9:checking that going from an empty policy zone works (16)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:ns7 zone refresh queued
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that add-soa no at rpz zone level works (17)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that add-soa yes at response-policy level works (18)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:reconfiguring server with 'add-soa no' (19)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that 'add-soa no' at response-policy level works (19)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that 'add-soa unset' works (20)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz with delegation fails correctly (21)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking policies from expired zone are no longer in effect (22)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with A-only (23)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with A-only (24)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with no A or AAAA (25)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with no A or AAAA (26)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with A and AAAA (27)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with A and AAAA (28)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking that rewriting CD=1 queries handles pending data correctly (29)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:status (native RPZ sub-test): 0 (pass)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:attempting to configure servers with DNSRPS...
2024-02-05 09:25:04 INFO:rpz I:rpz_tmp_zaujh5m9:DNSRPS disabled at compile time
2024-02-05 09:25:04 INFO:rpz I:rpz_tmp_zaujh5m9:DNSRPS sub-test skipped
PASSED [100%]
generated xml file: /home/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system/rpz.xml
========================== 1 passed in 97.72 seconds ===========================
ERROR rpz (exit status: 99)
```
```
% cat bin/tests/system/rpz.xml
<?xml version="1.0" encoding="utf-8"?><testsuite errors="0" failures="0" name="pytest" skips="0" tests="1" time="97.721"><testcase classname="rpz.tests_sh_rpz" file="rpz/tests_sh_rpz.py" line="12" name="test_rpz" time="97.68873071670532"></testcase></testsuite>
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4559Convert DNS_GETDB_ into struct with 1-bit long booleans2024-02-02T13:23:23ZOndřej SurýConvert DNS_GETDB_ into struct with 1-bit long booleansSee https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8683#note_433377 for details:
> Going step further, I think it can very well be a struct with booleans. It should cost nothing because compiler is not stupid nowadays and it...See https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8683#note_433377 for details:
> Going step further, I think it can very well be a struct with booleans. It should cost nothing because compiler is not stupid nowadays and it will make decoding values in coredumps easier.
>
> (To be clear - I mean something like this: !6902 (merged))https://gitlab.isc.org/isc-projects/bind9/-/issues/4557dnstap logging support for name server operator policy applied to DNS message...2024-02-02T08:32:32ZMatt Braundnstap logging support for name server operator policy applied to DNS messages like RPZ### Description
dnstap format supports since 2021 to log name server policies applied to DNS messages. Bind does not currently log RPZ policy hits via dnstap logging.
### Request
Implement RPZ policy dns message processing via dnstap....### Description
dnstap format supports since 2021 to log name server policies applied to DNS messages. Bind does not currently log RPZ policy hits via dnstap logging.
### Request
Implement RPZ policy dns message processing via dnstap.
### Links / references
https://github.com/dnstap/dnstap.pb/blob/master/dnstap.proto#L70https://gitlab.isc.org/isc-projects/bind9/-/issues/4556CI build issues with BIND 9.112024-02-22T08:54:19ZMark AndrewsCI build issues with BIND 9.11Minimal changes to continue to build and run test on bind9.11 so we can test security back ports.
Support newer compilers, address python, openssl and Net::DNS changes. etc.Minimal changes to continue to build and run test on bind9.11 so we can test security back ports.
Support newer compilers, address python, openssl and Net::DNS changes. etc.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4555Release Checklist for BIND 9.16.48, 9.16.48-S1, 9.18.24, 9.18.24-S1, 9.19.212024-02-14T15:30:46ZMichal NowakRelease Checklist for BIND 9.16.48, 9.16.48-S1, 9.18.24, 9.18.24-S1, 9.19.21## Release Schedule
**Code Freeze:** Tuesday, 30 January 2024
**Tagging Deadline:** Friday, 2 February 2024
**Public Release:** Tuesday, 13 February 2024
## Release Checklist
### Before the Tagging Deadline
- [x] ***(QA)*** Inspec...## Release Schedule
**Code Freeze:** Tuesday, 30 January 2024
**Tagging Deadline:** Friday, 2 February 2024
**Public Release:** Tuesday, 13 February 2024
## Release Checklist
### Before the Tagging Deadline
- [x] ***(QA)*** Inspect the current output of the `cross-version-config-tests` job to verify that no unexpected backward-incompatible change was introduced in the current release cycle.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well. [Example](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/510)
- [x] ***(QA)*** Add a release marker to `CHANGES`. Examples: [9.18](https://gitlab.isc.org/isc-projects/bind9/-/commit/f14d8ad78c0506fd4247187f2177f8eceeb6b3b9), [9.16](https://gitlab.isc.org/isc-projects/bind9/-/commit/1bcdf21874f99a00da389d723e0ad07dfd70f9f1)
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only). [Example](https://gitlab.isc.org/isc-private/bind9/-/commit/0f03d5737bcbdaa1bf713c6db1887b14938c3421)
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` ([9.18+](https://gitlab.isc.org/isc-projects/bind9/-/commit/3c85ab7f4c35e6d8acef1393606002a0a8730100)) or `version` ([9.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7692/diffs?commit_id=1bcdf21874f99a00da389d723e0ad07dfd70f9f1)).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [x] ***(QA)*** Update GitLab settings for all maintained branches to disallow merging to them: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9.x.y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Check that the formatting is correct for the HTML version of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results [for the tags](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=tags) created and sign off on the releases to be published.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to allow merging to them again: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)
- [x] ***(QA)*** Prepare (using [`version_bump.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/version_bump.py)) and merge MRs resetting the release notes and updating the version string for each maintained branch.
- [x] ***(QA)*** Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums. Ask [signers on Mattermost](https://mattermost.isc.org/isc/channels/bind-9-qa).
- [x] ***(Signers)*** Ensure that the contents of tarballs and tags are identical.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again: Run `publish_bind.sh` on repo.isc.org to pre-publish.
- [x] ***(QA)*** Prepare the `patches/` subdirectory for each security release (if applicable).
- [x] ***(QA)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages (in [cloudsmith branch in private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith)). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/e2512f4cfaf991827a635e374e7e93b27a5f38ba)
- [x] ***(Marketing)*** Prepare and send out ASN emails (as outlined in the CVE checklist; if applicable).
### On the Day of Public Release
- [x] ***(QA)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(QA)*** Place tarballs in public location on FTP site.
- [x] ***(QA)*** [Inform Marketing of the release, providing FTP links for the published tarballs.](https://mattermost.isc.org/isc/pl/dkc5s77ct3nkfxf8afyuxwfu7r)
- [x] ***(QA)*** [Use the Printing Press project to prepare a release announcement email.](isc-private/printing-press!96)
- [x] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [x] ***(Marketing)*** Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- [x] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [x] ***(Marketing)*** Send the release announcement email to the *bind-announce* mailing list (and to *bind-users* if a major release - [example](https://lists.isc.org/pipermail/bind-users/2022-January/105624.html)).
- [x] ***(Marketing)*** Announce release on social media sites.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages in [private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/2007d566db81dd9dfd79e571e2f600a3bc284da4)
- [x] ***(QA)*** Build [public RPMs](https://gitlab.isc.org/isc-packages/rpms/bind). [Example commit](https://gitlab.isc.org/isc-packages/rpms/bind/-/commit/3b5e851ea7c4e3570371a4878b5461f02a44f8cc) which triggers [Copr builds](https://copr.fedorainfracloud.org/coprs/isc/) automatically
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker files [here](https://gitlab.isc.org/isc-projects/bind9-docker/-/branches) and make sure push is synchronized to [GitHub](https://github.com/isc-projects/bind9-docker). [Docker Hub](https://hub.docker.com/r/internetsystemsconsortium/bind9) should pick it up automatically. [Example](https://gitlab.isc.org/isc-projects/bind9-docker/-/commit/cada7e10e9af951595c98bfffc4bd42512faac05)
- [x] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Using [`merge_tag.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/merge_tag.py), merge published release tags back into the their relevant development/maintenance branches.
- [x] ***(QA)*** Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize [confidential issues](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=milestone_due_desc&state=opened&confidential=yes) which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Black, PyLint, Sphinx) by modifying the relevant [`Dockerfile`](https://gitlab.isc.org/isc-projects/images/-/merge_requests/228/diffs).
- [x] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI.
- [x] ***(QA)*** Update [`metadata.json`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/metadata.json) with the upcoming release information.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.February 2024 (9.16.47/9.16.48, 9.16.47/9.16.48-S1, 9.18.23/9.18.24, 9.18.23/9.18.24-S1, 9.19.21)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4554Signature expiration calculation backwards compatibility bug2024-02-24T07:53:48ZMatthijs Mekkingmatthijs@isc.orgSignature expiration calculation backwards compatibility bugThe `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `sig...The `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `signatures-validity - signatures-refresh`) which is wrong: it should be using a range of 0 to `signatures-refresh`.
The `sig-validity-interval` that was used for `auto-dnssec` defined two parameters, the first being the signatures validity (same as `dnssec-policy`'s `signatures-validity`), the optional second one being the minimum bound of the signatures validity. It also serves as a signatures refresh. Basically the refresh value is the difference between the first and second parameter.
So the second parameter actually has two meanings: It serves as a jitter and a refresh value.
With `dnssec-policy` there is not yet a way to define `jitter`. The `signatures-refresh` is actually defined as the.
Two things need to be done:
- [x] Add a configuration option to `dnssec-policy` to set desired jitter.
- [x] Ensure resign interval is used correctly.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4553return value for check DS shadows value for running keymgr2024-03-07T22:43:18ZMatthijs Mekkingmatthijs@isc.orgreturn value for check DS shadows value for running keymgrChecking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.Checking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4552keymgr: bug in Depends function2024-03-13T10:53:30ZMatthijs Mekkingmatthijs@isc.orgkeymgr: bug in Depends functionWhile working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certa...While working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certain record type is going to be swapped. For example, with the ZSK Pre-Publish rollover method the signatures created by the successor key `z` are being propagated first, so that the zone signatures for `x` and `z` can be swapped (smooth rollover). In this case, we say that `z` is the successor of `x` for the `ZRRSIG` record type. Here, `x` is the predecessor key that is going to be withdrawn from the zone. The set `Dep(x, T)` is a separately administrated set of keys that have a dependency on `x` for record type `T`.
For example, with the ZSK Pre-Publish method, the `ZRRSIG` records of key `x` can be withdrawn if there is a succeeding `ZRRSIG` of key `z` introduced in the zone. Key `x` now depends on key `z`, therefore `z` will be in the set `Dep(x, ZRRSIG)`. The successor relation requires that the predecessor key must not have any other keys relying on it. In other words, the set `Dep(x, T)` must be empty.
---
But if the key is phased out (all its states are in `HIDDEN`), there is no longer a dependency. Since the relationship is still maintained (`Predecessor` and `Successor` metadata), the `keymgr_dep` function still returned `true`. In other words, the set `Dep(x, T)` is not considered empty.
This slows down key rollovers, only retiring keys when the successor key has been fully propagated.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4551dnssec-keygen man page contradictory on whether TSIG keys can be generated2024-03-08T05:39:15ZChristopher Headdnssec-keygen man page contradictory on whether TSIG keys can be generated### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the secti...### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the section for the `-a` option:
> In prior releases, HMAC algorithms could be generated for use as TSIG keys, but that feature was removed in BIND 9.13.0. Use tsig-keygen to generate TSIG keys.
It looks like the top matter probably wasn’t updated when TSIG was spun out into `tsig-keygen`.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4550Resolve license aggregation for "reuse lint"2024-02-07T16:19:55ZMichal NowakResolve license aggregation for "reuse lint"`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: Pen...`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: PendingDeprecationWarning: Copyright and licensing
information for 'COPYRIGHT' has been found in both 'COPYRIGHT' and in the DEP5 file located at '.reuse/dep5'.
The information for these two sources has been aggregated. In the future this behaviour will change, and you will
need to explicitly enable aggregation. See <https://github.com/fsfe/reuse-tool/issues/779>. You need do nothing
yet. Run with `--suppress-deprecation` to hide this warning.
...
```Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4549heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone2024-03-08T07:52:43ZMichal Nowakheap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddoneJob [#3977008](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3977008) failed for 6b00e831e1f7dad6c02766721f3f921935f9d82d in the `shutdown` system test.
```
WARNING: ThreadSanitizer: heap-use-after-free
Write of size 8 at 0x0000000...Job [#3977008](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3977008) failed for 6b00e831e1f7dad6c02766721f3f921935f9d82d in the `shutdown` system test.
```
WARNING: ThreadSanitizer: heap-use-after-free
Write of size 8 at 0x000000000001 by main thread:
#0 ccmsg_senddone lib/isccc/ccmsg.c:160 (BuildId: d832ce616f43e7826d71895c29b8d1a636594d28)
#1 isc___nm_sendcb netmgr/netmgr.c:1882 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#2 isc__job_cb lib/isc/job.c:78 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#3 uv__run_idle /usr/src/libuv-v1.47.0/src/unix/loop-watcher.c:68 (BuildId: 073e85ad3e8928fc579b193a4ac75e2ebba7da2f)
#4 thread_body lib/isc/thread.c:85 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#5 isc_thread_main lib/isc/thread.c:116 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#6 isc_loopmgr_run lib/isc/loop.c:454 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#7 main bin/named/main.c:1574 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
Previous write of size 8 at 0x000000000001 by main thread:
#0 free <null> (BuildId: 732e44e7f1cd4f0f9ca7d27895a253bebdea6827)
#1 sdallocx lib/isc/jemalloc_shim.h:82 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#2 mem_put lib/isc/mem.c:328
#3 isc__mem_put lib/isc/mem.c:692
#4 conn_free bin/named/controlconf.c:597 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#5 controlconnection_unref bin/named/controlconf.c:200
#6 controlconnection_detach bin/named/controlconf.c:200 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#7 control_senddone bin/named/controlconf.c:284 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#8 ccmsg_senddone lib/isccc/ccmsg.c:159 (BuildId: d832ce616f43e7826d71895c29b8d1a636594d28)
#9 isc___nm_sendcb netmgr/netmgr.c:1882 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#10 isc__job_cb lib/isc/job.c:78 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#11 uv__run_idle /usr/src/libuv-v1.47.0/src/unix/loop-watcher.c:68 (BuildId: 073e85ad3e8928fc579b193a4ac75e2ebba7da2f)
#12 thread_body lib/isc/thread.c:85 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#13 isc_thread_main lib/isc/thread.c:116 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#14 isc_loopmgr_run lib/isc/loop.c:454 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#15 main bin/named/main.c:1574 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
SUMMARY: ThreadSanitizer: heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone
```
We had a similar issue #4501 before.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4547Add support for nginx load balancing with “X-Real-IP”2024-01-24T11:56:31ZMr BenAdd support for nginx load balancing with “X-Real-IP”### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supp...### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supported. Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Request
Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4546Cannot Compile - Invalid Regex Prevents Generation of Parsetab Module2024-01-23T22:35:43ZOleg SCannot Compile - Invalid Regex Prevents Generation of Parsetab Module<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
The Bind project (version 9.16.23) cannot be compiled due to regex
issues in the `bin/python/isc/policy.py` file.
Here is the output generated when running `make`:
### BIND version affected
9.16.23
### Steps to reproduce
1. On a Fedora 39 system (this probably applies beyond Fedora 39, too), with Python 3.12.1 installed,
simply clone the source code of the repo corresponding to
version 9.16.23.
2. Run `./configure` and ensure that it completes successfully
3. Run `make`
### What is the current *bug* behavior?
Make finishes prematurely because it cannot find the `parsetab` module.
### What is the expected *correct* behavior?
Make should be able to run the Python script and generate the `parsetab` module
successfully.
### Relevant configuration files
n/a
### Relevant logs
Here is the output of `make`:
```
/usr/bin/python policy.py parse /dev/null > /dev/null
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:63: Invalid regular expression for rule 't_DATESUFFIX'. missing -, : or ) at position 20
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:68: Invalid regular expression for rule 't_KEYTYPE'. global flags not at the start of the expression at position 14
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:73: Invalid regular expression for rule 't_ALGNAME'. global flags not at the start of the expression at position 14
PYTHONPATH=. /usr/bin/python -m parsetab
/usr/bin/python: No module named parsetab
make[3]: *** [Makefile:457: parsetab.py] Error 1
```