BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-21T23:36:33Zhttps://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/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/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/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/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/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/4545Flamethrower DoH queries timeout with BIND on FreeBSD2024-03-04T16:12:33ZMichal NowakFlamethrower DoH queries timeout with BIND on FreeBSDIn "stress" CI jobs, we run three types of scenarios where we send thousands of UDP and TCP queries per second to an authoritative, recursive, or recursive RPZ server. Each scenario runs on Linux amd64, Linux arm64, and FreeBSD 12.4 amd6...In "stress" CI jobs, we run three types of scenarios where we send thousands of UDP and TCP queries per second to an authoritative, recursive, or recursive RPZ server. Each scenario runs on Linux amd64, Linux arm64, and FreeBSD 12.4 amd64 platforms. For a long time, I have tried to add support for DoT and DoH, and with the adoption of AWS for CI, this is now possible.
The major problem now is that there's something wrong with BIND-Flamethrower cooperation for DoH queries on FreeBSD 12.4 for all scenarios (authoritative, recursive, and recursive with RPZ). The problem is that Flamethrower 0.12 from upstream Git `master` - run on FreeBSD in CI or Linux in my local environment - never gets answers to DoH queries from BIND on FreeBSD (DoH on BIND on Linux is fine; DoT, TCP, and UDP on FreeBSD are fine as well). 100% of queries are timeouted. During the Flamethrower runtime, in the BIND `-d 99` log, there is only a lot of lines like this: `22-Jan-2024 14:39:14.040 socket 0x8030df800: TLS server session created for 192.168.122.1#43511 on 192.168.122.73#4430`. However, the query does not seem to be processed in any way. It gets processed fine when sent by `dig +https`.
See job [#3956703](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3956703) for logs and config files.
Here's a 10-second PCAP (`tcpdump port 4430 -i vtnet0`) from my local environment: [cap.pcap](/uploads/5b4bfee595db99cb92b220ce97eff697/cap.pcap).
Flamethrower output with 100% of timeouted queries:
<details><summary>Click to expand</summary>
```
/usr/local/bin/flame --dnssec -P doh -F inet -g file -f ~/Downloads/fbsddoh/query_datafile -Q 1 -p 4430 192.168.122.73
WARNING: QPS limit is less than concurrent senders, changing limit to 30
binding traffic generators to 0.0.0.0
flaming target(s) [192.168.122.73] on port 4430 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol doh
query generator [file] contains 105000 record(s)
rate limit @ 30 QPS (1 QPS per concurrent sender)
1.1768e-05s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
1.00012s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
2.00152s: send: 30, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
3.00237s: send: 0, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
4.00255s: send: 0, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
5.00297s: send: 90, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 30
6.00343s: send: 0, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
7.00418s: send: 0, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
8.00446s: send: 90, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 90
9.00494s: send: 0, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
10.0056s: send: 0, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
11.0064s: send: 90, avg send: 75, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 90
^C11.1595s: send: 0, avg send: 75, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
stopping, waiting up to 3s for in flight to finish...
------
run id : 7ffd5c99e030
run start : 2024-01-22T16:41:23Z
runtime : 14.1608 s
total sent : 300
total rcvd : 0
min resp : 0 ms
avg resp : -nan ms
max resp : 0 ms
avg r qps : 0
avg s qps : 75
avg pkt : 35.3258 bytes
tcp conn. : 568
timeouts : 300 (100%)
bad recv : 0
net errors : 0
```
</details>
BIND config file:
<details><summary>Click to expand</summary>
```
http local {
endpoints { "/dns-query"; };
};
options {
port 5300;
listen-on port 5300 { 10.53.0.2; };
listen-on-v6 port 5300 { fd92:7065:b8e:ffff::2; };
listen-on port 8530 tls ephemeral { 10.53.0.2; }; // DoT IPv4
listen-on-v6 port 8530 tls ephemeral { fd92:7065:b8e:ffff::2; }; // DoT IPv6
listen-on port 4430 tls ephemeral http local { 10.53.0.2; }; // DoH IPv4
listen-on port 4430 tls ephemeral http local { 192.168.122.73; }; // DoH IPv4
listen-on-v6 port 4430 tls ephemeral http local { fd92:7065:b8e:ffff::2; }; // DoH IPv6
#directory "/var/tmp/gitlab_runner/builds/e-TSUMFs/0/isc-projects/bind9/output/ns2";
allow-query { any ; };
query-source address 10.53.0.2;
pid-file "named.pid";
recursion no;
tcp-clients 50;
statistics-file "named.stats";
};
statistics-channels {
inet 10.53.0.2 port 5308 allow { any; };
};
key "rndc-key" {
algorithm hmac-sha256;
secret "G+hIujn1FwNv1QgEWLrzN8ZXodAHzciE7tMSYDIiw54=";
};
controls {
inet 10.53.0.2 port 5309
allow { any; } keys { "rndc-key"; };
};
include "trusted-keys.conf";
view "default" {
zone "." {
type hint;
file "root.hint";
};
zone "test.example." in {
type master ;
file "test.example.db.signed";
};
};
logging {
channel "namedlog" {
file "named.log" versions 5 size 50M;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"namedlog";
};
};
```
</details>
The `query_datafile` file is in the CI job artifact.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/4541values of ruletype field for update-policy statement2024-03-08T05:30:58Zperlangvalues of ruletype field for update-policy statementOne document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``...One document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``, ``ms-self``,
``ms-selfsub``, ``ms-subdomain``, ``ms-subdomain-self-rhs``, ``krb5-self``,
``krb5-selfsub``, ``krb5-subdomain``, ``krb5-subdomain-self-rhs``,
``tcp-self``, ``6to4-self``, and ``external``.
```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/4536The new "cipher-suites" system test fails in FIPS mode2024-03-08T05:23:01ZMichał KępieńThe new "cipher-suites" system test fails in FIPS mode!8576 was merged 3 days ago and here is a list of its failures in GitLab
CI since:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938188
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938189
- https://gitlab.isc.org/isc-...!8576 was merged 3 days ago and here is a list of its failures in GitLab
CI since:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938188
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3938189
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939001
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939002
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939846
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939847
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939988
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3939989
These look like permanent failures; it is probably a rare case of a
FIPS-only failure that was not caught before merging since we only run
FIPS-mode jobs in scheduled pipelines rather than for every merge
request.
Looks like there is a pattern to these failures - there seem to be
different issues on different platforms:
- on Oracle Linux 9 in FIPS mode, there is often a **crash**:
```
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D cipher-suites_tmp__8wequ'.
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:Program terminated with signal SIGABRT, Aborted.
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#0 0x00007fde4caa158c in __pthread_kill_implementation () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:[Current thread is 1 (Thread 0x7fde49fba600 (LWP 103424))]
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#0 0x00007fde4caa158c in __pthread_kill_implementation () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#1 0x00007fde4ca54d06 in raise () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#2 0x00007fde4ca287f3 in abort () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#3 0x0000000000422b05 in assertion_failed (file=0x7fde4d8c26a1 "netmgr/tcp.c", line=918, type=isc_assertiontype_insist, cond=0x7fde4d8c2720 "csock->recv_cb != ((void *)0)") at main.c:234
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#4 0x00007fde4d88aace in isc_assertion_failed (file=file@entry=0x7fde4d8c26a1 "netmgr/tcp.c", line=line@entry=918, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fde4d8c2720 "csock->recv_cb != ((void *)0)") at assertions.c:48
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#5 0x00007fde4d8829e3 in accept_connection (csock=<optimized out>, csock@entry=0x7fde48c0b000) at netmgr/tcp.c:918
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#6 0x00007fde4d882c1d in tcp_connection_cb (server=<optimized out>, status=<optimized out>) at netmgr/tcp.c:558
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#7 0x00007fde4d481e77 in uv.server_io () from /lib64/libuv.so.1
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#8 0x00007fde4d49285e in uv.io_poll.part () from /lib64/libuv.so.1
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#9 0x00007fde4d47c5a8 in uv_run () from /lib64/libuv.so.1
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#10 0x00007fde4d89d896 in loop_thread (arg=arg@entry=0x7fde4bea6180) at loop.c:282
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#11 0x00007fde4d8af4b5 in thread_body (wrap=wrap@entry=0x1dc7350) at thread.c:85
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#12 0x00007fde4d8af4de in thread_run (wrap=0x1dc7350) at thread.c:100
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#13 0x00007fde4ca9f812 in start_thread () from /lib64/libc.so.6
2024-01-14 08:18:07 INFO:cipher-suites D:/builds/isc-projects/bind9/bin/tests/system/cipher-suites_tmp__8wequh4:#14 0x00007fde4ca3f450 in clone3 () from /lib64/libc.so.6
```
- on Oracle Linux 8 in FIPS mode, there is often a **test failure**:
```
2024-01-13 00:16:03 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns2" (1)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns3" (2)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns4" (3)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns2" (4)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns3" (5)
2024-01-13 00:16:04 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns4" (6)
2024-01-13 00:16:13 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:failed
2024-01-13 00:16:13 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns2", failure expected (7)
2024-01-13 00:16:22 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns2", failure expected (8)
2024-01-13 00:16:32 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns3", failure expected (9)
2024-01-13 00:16:41 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns3", failure expected (10)
2024-01-13 00:16:51 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns4", failure expected (11)
2024-01-13 00:17:00 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns4", failure expected (12)
2024-01-13 00:17:09 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example" at "ns5", failure expected (13)
2024-01-13 00:17:19 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-128" at "ns5", failure expected (14)
2024-01-13 00:17:28 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-aes-256" at "ns5", failure expected (15)
2024-01-13 00:17:38 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:testing zone transfer over TLS (XoT): - zone "example-chacha-20" at "ns5", failure expected (16)
2024-01-13 00:17:47 INFO:cipher-suites I:cipher-suites_tmp_5cchgkwp:exit status: 1
```
I would normally follow up on the original issue in cases like this, but
it seems that at least the crash may be a pre-existing issue, so I
thought that separating it out might be prudent.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/4531Improvements to the parental-agents definition in the arm2024-03-08T05:42:15ZDan MahoneyImprovements to the parental-agents definition in the armHi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [X] Search the existing issues in GitLab (both open and closed) to see if your report m...Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [X] Search the existing issues in GitLab (both open and closed) to see if your report might be a duplicate. We have a large database here and many issues have already been fixed in the latest versions!
- [X] Make sure this is **not** a support question. If you have specific trouble configuring or debugging your setup, please use the bind-users mailing list: https://lists.isc.org/mailman/listinfo/bind-users
- [X] You have read and understood the "out in the open" support policy: https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ . Even though it was written by the PowerDNS folks, we follow it as well!
Before continuing, **please select the appropriate issue template in the drop-down menu above, under the heading _Description_**.
(There is no "doc" template. Maybe there should be.)
The current doc for parental-agents laid out in the 9.18 arm is, some formatting tweaks for gitlab aside:
> Grammar zone (primary, secondary): `parental-agents [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... };`
>
> Grammar topmost: `parental-agents <string> [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... }; // may occur multiple times`
>
> Blocks: topmost, zone (primary, secondary)
>
> Tags: zone
>
> Defines a list of delegation agents to be used by primary and secondary zones.
>
> 8.2.10. `parental-agents` Block Definition and Usage
>
> `parental-agents` lists allow for a common set of parental agents to be easily used by multiple primary and secondary zones. A parental agent is the entity that is allowed to change a zone’s delegation information (defined in RFC 7344).
What is not apparent from the above:
* If you define a "topmost" parental agent, you must still define it in a zone for it to be used. There is no way to configure a default parental agent, nor to have it apply to zones without stating it for each. The example cited in the 9.18 migration article in the KB only mentions the pure-zone-based version, and doesn't give a good example of how to do it with a globally-defined one.
* The "usage" statement for the zone does not make it apparent how to specify an agent defined topmost -- this implies either two "zone" usage statements (Grammar zone with no defined topmost agent, grammar zone with the agent defined only in the zone statement), or a more complex definition of the "Grammar Zone" statement where it's either "parental-agents { "string"; } followed by the rest of the possible options. (I guess it's possible to use a topmost-defined parental agent but ALSO add others? -- I'm not sure how to properly bracket those options, depending on if that's the case.)
* **"A parental agent is the entity that is allowed to change a zone's delegation information"** is untrue in this case. While that is one possible usage (for example, specifying "a0.org.afilias-nst.info." for an agent for example.org), The a0.org.afilias-nst.info. is not allowed to change the delegation information -- some hidden SRS server and a stealth master are, as part of the DNSSEC process. A parental-agent may also be set to 8.8.8.8 or any other TSIG-relationship-defined validating resolver, none of which are allowed to change anything about the delegation.
* Also, the "allowed to change" wording implies that there is some nsupdate-like relationship required between our zone and it, that's to be configured, especially because things like TSIG keys are offered as options.
* It isn't immediately clear that the only thing BIND does is send DS queries.
A better phrasing here might be:
"A parental agent is a trusted DNS server that can confirm that a zone's delegation information has been updated in the parent zone of the one being configured, as defined in (rfc foo section bar). [An optional statement about what is implied by "trusted" (TSIG/DNSSEC/ACLs on the parental-agent server) could go here.]"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/4529Abort in nsupdate2024-03-08T05:49:14ZMark AndrewsAbort in nsupdateThis was with main as far as nsupdate was concerned. It appears that it managed to call dns_requestmgr_shutdown twice.
```
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------...This was with main as far as nsupdate was concerned. It appears that it managed to call dns_requestmgr_shutdown twice.
```
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: nsupdate [60914]
Path: /Users/USER/*/nsupdate
Identifier: nsupdate
Version: ???
Code Type: ARM-64 (Native)
Parent Process: Exited process [88632]
Responsible: Terminal [1931]
User ID: 505
Date/Time: 2024-01-12 16:55:38.9877 +1100
OS Version: macOS 13.6.3 (22G436)
Report Version: 12
Anonymous UUID: E43701DF-63DC-8EF6-83FC-FFBFB7819AE8
Sleep/Wake UUID: 2E0B9225-F88F-4D2B-82C0-1ADB50A22170
Time Awake Since Boot: 1300000 seconds
Time Since Wake: 12303 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: nsupdate [60914]
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x19ff40744 __pthread_kill + 8
1 libsystem_pthread.dylib 0x19ff77c28 pthread_kill + 288
2 libsystem_c.dylib 0x19fe85ae8 abort + 180
3 libisc-9.19.21-dev.dylib 0x104352eb4 isc_assertion_failed + 60 (assertions.c:49)
4 libdns-9.19.21-dev.dylib 0x1048f45cc dns_requestmgr_shutdown + 268 (request.c:198)
5 nsupdate 0x1041e94b4 maybeshutdown + 60 (nsupdate.c:741)
6 nsupdate 0x1041eeedc update_completed + 112 (nsupdate.c:2452)
7 libdns-9.19.21-dev.dylib 0x1048f7d64 req_sendevent_cb + 40 (request.c:949)
8 libisc-9.19.21-dev.dylib 0x104353444 isc__async_cb + 448 (async.c:111)
9 libuv.1.dylib 0x10452a3c4 uv__async_io + 320
10 libuv.1.dylib 0x10453a1e0 uv__io_poll + 1748
11 libuv.1.dylib 0x10452a7bc uv_run + 244
12 libisc-9.19.21-dev.dylib 0x1043758f0 loop_thread + 372 (loop.c:282)
13 libisc-9.19.21-dev.dylib 0x104394914 thread_body + 88 (thread.c:85)
14 libisc-9.19.21-dev.dylib 0x10439488c isc_thread_main + 104 (thread.c:116)
15 libisc-9.19.21-dev.dylib 0x10437564c isc_loopmgr_run + 472 (loop.c:454)
16 nsupdate 0x1041e5ea4 main + 420 (nsupdate.c:3483)
17 dyld 0x19fc1ff28 start + 2236
Thread 1:
0 libsystem_kernel.dylib 0x19ff40854 poll + 8
1 liburcu-cds.8.dylib 0x1045b58c8 compat_futex_async + 76 (compat_futex.c:139)
2 liburcu-cds.8.dylib 0x1045b2824 futex_async + 28 (futex.h:193) [inlined]
3 liburcu-cds.8.dylib 0x1045b2824 futex_wait + 88 (workqueue.c:135)
4 liburcu-cds.8.dylib 0x1045b255c workqueue_thread + 796 (workqueue.c:246)
5 libsystem_pthread.dylib 0x19ff77fa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x19ff72da0 thread_start + 8
Thread 2:
0 libsystem_kernel.dylib 0x19ff40854 poll + 8
1 liburcu.8.dylib 0x104459d10 compat_futex_async + 76 (compat_futex.c:139)
2 liburcu.8.dylib 0x104457d24 futex_async + 28 (futex.h:193) [inlined]
3 liburcu.8.dylib 0x104457d24 wait_gp + 44 (urcu.c:267) [inlined]
4 liburcu.8.dylib 0x104457d24 wait_for_readers + 380 (urcu.c:359)
5 liburcu.8.dylib 0x104457a4c urcu_memb_synchronize_rcu + 476 (urcu.c:500)
6 liburcu.8.dylib 0x1044596ec call_rcu_thread + 384 (urcu-call-rcu-impl.h:381)
7 libsystem_pthread.dylib 0x19ff77fa8 _pthread_start + 148
8 libsystem_pthread.dylib 0x19ff72da0 thread_start + 8
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000
x4: 0x000000019fe88a6f x5: 0x000000016bc10370 x6: 0x0000000000000036 x7: 0x0000000000000000
x8: 0xe903a03852a19ded x9: 0xe903a039a9cdbced x10: 0x0000000000000002 x11: 0x00000000fffffffd
x12: 0x0000010000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x0000000000000000
x16: 0x0000000000000148 x17: 0x0000000200223020 x18: 0x0000000000000000 x19: 0x0000000000000006
x20: 0x00000001fb6c2100 x21: 0x0000000000000103 x22: 0x00000001fb6c21e0 x23: 0x00000001057784c8
x24: 0x0000000105778288 x25: 0x0000000000000001 x26: 0x0000000000000001 x27: 0x0000000105778230
x28: 0x0000000000000001 fp: 0x000000016bc10d60 lr: 0x000000019ff77c28
sp: 0x000000016bc10d40 pc: 0x000000019ff40744 cpsr: 0x40001000
far: 0x0000000000000000 esr: 0x56000080 Address size fault
Binary Images:
0x1041e4000 - 0x1041f3fff nsupdate (*) <fc5fc9ca-b970-4719-8d9d-1c52d49b85ca> /Users/USER/*/nsupdate
0x104328000 - 0x1043c3fff libisc-9.19.21-dev.dylib (*) <6553893e-d490-4ced-97f1-6f2ab6fc025b> /Users/USER/*/libisc-9.19.21-dev.dylib
0x104764000 - 0x104a0ffff libdns-9.19.21-dev.dylib (*) <350ca5b7-cb2b-46f8-9592-d7870788e644> /Users/USER/*/libdns-9.19.21-dev.dylib
0x1042a4000 - 0x1042d7fff libisccfg-9.19.21-dev.dylib (*) <500e50a8-58e3-4ee5-bd13-5be5df9ee128> /Users/USER/*/libisccfg-9.19.21-dev.dylib
0x10447c000 - 0x1044cffff libns-9.19.21-dev.dylib (*) <d3c1a218-875c-45d8-92ec-e68a5824c086> /Users/USER/*/libns-9.19.21-dev.dylib
0x10425c000 - 0x10425ffff libmaxminddb.0.dylib (*) <c6878189-90b5-3d08-84f3-de63d925a475> /opt/local/lib/libmaxminddb.0.dylib
0x104284000 - 0x104293fff liblmdb.dylib (*) <d0a90a8e-5def-39e0-95ba-4d616af7843d> /opt/local/lib/liblmdb.dylib
0x104300000 - 0x10430ffff libz.1.3.dylib (*) <4a63b405-84ae-37fa-973c-c99ab2634dd6> /opt/local/lib/libz.1.3.dylib
0x104ac0000 - 0x104c1ffff libjemalloc.2.dylib (*) <e64634dc-6335-326d-bad8-693b384a3426> /Users/USER/*/libjemalloc.2.dylib
0x104408000 - 0x10440ffff libjson-c.2.dylib (*) <55d0e643-f390-30c0-afb8-bb90ad791aae> /opt/local/lib/libjson-c.2.dylib
0x1044f0000 - 0x10450ffff libnghttp2.14.dylib (*) <04ae6ed8-9919-383a-a3bd-49cfda4df482> /opt/local/lib/libnghttp2.14.dylib
0x10463c000 - 0x10471bfff libxml2.2.dylib (*) <275b0d3d-c45c-3a11-9647-f59ff0501dfc> /opt/local/lib/libxml2.2.dylib
0x104524000 - 0x10453ffff libuv.1.dylib (*) <076fd891-2017-328a-a7d4-89d9faf42dde> /opt/local/lib/libuv.1.dylib
0x104ddc000 - 0x104e5ffff libssl.3.dylib (*) <b0393f6d-2afe-313d-bf36-e5f919b9e6cb> /opt/local/libexec/*/libssl.3.dylib
0x10528c000 - 0x10555ffff libcrypto.3.dylib (*) <3189ddc3-b9ec-33cb-af81-0a7f01bd4280> /opt/local/libexec/*/libcrypto.3.dylib
0x104564000 - 0x104597fff libgssapi_krb5.2.2.dylib (*) <0223e7e9-a50c-3d53-96fa-841a0b2125b6> /opt/local/lib/libgssapi_krb5.2.2.dylib
0x104f60000 - 0x104fdffff libkrb5.3.3.dylib (*) <60f5165b-b650-3afe-b99a-49b8c4a8213d> /opt/local/lib/libkrb5.3.3.dylib
0x104438000 - 0x104447fff libk5crypto.3.1.dylib (*) <3b40599e-83d4-36d9-bf5d-978b55a6186a> /opt/local/lib/libk5crypto.3.1.dylib
0x10426c000 - 0x10426ffff libcom_err.1.1.dylib (*) <ddbf7057-c200-3a1c-8279-03a92e74e9a0> /opt/local/lib/libcom_err.1.1.dylib
0x1045e0000 - 0x1045fffff libedit.0.dylib (*) <a368e05a-b24b-3f87-885c-176dd89d538f> /opt/local/lib/libedit.0.dylib
0x104454000 - 0x10445bfff liburcu.8.dylib (*) <bfb91bed-832b-3dfe-9ba0-0a0ed23bf291> /Users/USER/*/liburcu.8.dylib
0x1045b0000 - 0x1045b7fff liburcu-cds.8.dylib (*) <fce9d042-2e9d-3f6a-bd48-2c436aa2c3be> /Users/USER/*/liburcu-cds.8.dylib
0x104318000 - 0x10431bfff liburcu-common.8.dylib (*) <9a24f984-8a16-39d4-a5cc-5d5c303f349e> /Users/USER/*/liburcu-common.8.dylib
0x104ea0000 - 0x104ebffff liblzma.5.dylib (*) <67f10b23-041f-3578-b51c-22d5a66c7ff7> /opt/local/lib/liblzma.5.dylib
0x10513c000 - 0x10523ffff libiconv.2.dylib (*) <5fec81f0-90a7-34f9-afa5-27882cebd803> /opt/local/lib/libiconv.2.dylib
0x10592c000 - 0x105abbfff libicui18n.74.1.dylib (*) <b9f63e5c-0953-3fdd-818f-5281f283526a> /opt/local/lib/libicui18n.74.1.dylib
0x105be0000 - 0x105d13fff libicuuc.74.1.dylib (*) <34bfb2bf-1dd1-3d1f-9ce9-fdfd37ff8475> /opt/local/lib/libicuuc.74.1.dylib
0x107b34000 - 0x109893fff libicudata.74.1.dylib (*) <364b1ef5-ef47-32b8-a939-f19d872051a7> /opt/local/lib/libicudata.74.1.dylib
0x1045cc000 - 0x1045d3fff libkrb5support.1.1.dylib (*) <986d8b90-c209-3c3c-b319-b5d8a61c7aca> /opt/local/lib/libkrb5support.1.1.dylib
0x104610000 - 0x10461bfff libintl.8.dylib (*) <149107de-c05b-36cc-9fdc-a7a784cec35f> /opt/local/lib/libintl.8.dylib
0x105020000 - 0x10505bfff libncurses.6.dylib (*) <64dbc603-ea0b-3259-8ba5-d0fbd3d5954c> /opt/local/lib/libncurses.6.dylib
0x19ff37000 - 0x19ff70fe7 libsystem_kernel.dylib (*) <6024d562-0a3b-3568-8ee2-1741160ba022> /usr/lib/system/libsystem_kernel.dylib
0x19ff71000 - 0x19ff7dfff libsystem_pthread.dylib (*) <7acb080f-eabe-3a59-8d9f-7459f33bb263> /usr/lib/system/libsystem_pthread.dylib
0x19fe0f000 - 0x19fe8dff7 libsystem_c.dylib (*) <840fe68c-8175-347b-bfb1-3b6bce431935> /usr/lib/system/libsystem_c.dylib
0x19fc1a000 - 0x19fca8587 dyld (*) <b35b0343-b5b9-3204-8eba-8dad651a4e3a> /usr/lib/dyld
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=965.2M resident=0K(0%) swapped_out_or_unallocated=965.2M(100%)
Writable regions: Total=596.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=596.5M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
CoreMedia Capture Data 13.5M 49
Kernel Alloc Once 32K 1
MALLOC 137.2M 13
MALLOC guard page 96K 6
MALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)
STACK GUARD 48K 3
Stack 65.0M 3
__AUTH 320K 62
__AUTH_CONST 3740K 147
__DATA 3079K 170
__DATA_CONST 5190K 178
__DATA_DIRTY 361K 58
__LINKEDIT 808.6M 32
__OBJC_RO 66.4M 1
__OBJC_RW 2012K 1
__TEXT 156.6M 187
dyld private memory 272K 2
shared memory 32K 2
=========== ======= =======
TOTAL 1.6G 916
TOTAL, minus reserved VM space 1.2G 916
-----------
Full Report
-----------
{"app_name":"nsupdate","timestamp":"2024-01-12 16:55:40.00 +1100","app_version":"","slice_uuid":"fc5fc9ca-b970-4719-8d9d-1c52d49b85ca","build_version":"","platform":1,"share_with_app_devs":1,"is_first_party":1,"bug_type":"309","os_version":"macOS 13.6.3 (22G436)","roots_installed":0,"incident_id":"3CBD864A-8D4D-434C-BA89-1EA680808DA3","name":"nsupdate"}
{
"uptime" : 1300000,
"procRole" : "Unspecified",
"version" : 2,
"userID" : 505,
"deployVersion" : 210,
"modelCode" : "MacBookPro17,1",
"coalitionID" : 1082,
"osVersion" : {
"train" : "macOS 13.6.3",
"build" : "22G436",
"releaseType" : "User"
},
"captureTime" : "2024-01-12 16:55:38.9877 +1100",
"incident" : "3CBD864A-8D4D-434C-BA89-1EA680808DA3",
"pid" : 60914,
"translated" : false,
"cpuType" : "ARM-64",
"roots_installed" : 0,
"bug_type" : "309",
"procLaunch" : "2024-01-12 16:55:38.0241 +1100",
"procStartAbsTime" : 33266850463036,
"procExitAbsTime" : 33266865919747,
"procName" : "nsupdate",
"procPath" : "\/Users\/USER\/*\/nsupdate",
"parentProc" : "Exited process",
"parentPid" : 88632,
"coalitionName" : "com.apple.Terminal",
"crashReporterKey" : "E43701DF-63DC-8EF6-83FC-FFBFB7819AE8",
"responsiblePid" : 1931,
"responsibleProc" : "Terminal",
"codeSigningID" : "nsupdate",
"codeSigningTeamID" : "",
"codeSigningFlags" : 570556929,
"codeSigningValidationCategory" : 10,
"codeSigningTrustLevel" : 0,
"wakeTime" : 12303,
"sleepWakeUUID" : "2E0B9225-F88F-4D2B-82C0-1ADB50A22170",
"sip" : "enabled",
"exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
"termination" : {"flags":0,"code":6,"namespace":"SIGNAL","indicator":"Abort trap: 6","byProc":"nsupdate","byPid":60914},
"asi" : {"libsystem_c.dylib":["abort() called"]},
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
"faultingThread" : 0,
"threads" : [{"triggered":true,"id":45604294,"threadState":{"x":[{"value":0},{"value":0},{"value":0},{"value":0},{"value":6977784431,"symbolLocation":0,"symbol":"__vfprintf.xdigs_lower"},{"value":6102778736},{"value":54},{"value":0},{"value":16790439999532277229},{"value":16790440005289753837},{"value":2},{"value":4294967293},{"value":1099511627776},{"value":0},{"value":0},{"value":0},{"value":328},{"value":8592175136},{"value":0},{"value":6},{"value":8513134848,"symbolLocation":0,"symbol":"_main_thread"},{"value":259},{"value":8513135072,"symbolLocation":224,"symbol":"_main_thread"},{"value":4386686152},{"value":4386685576},{"value":1},{"value":1},{"value":4386685488},{"value":1}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6978763816},"cpsr":{"value":1073745920},"fp":{"value":6102781280},"sp":{"value":6102781248},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6978537284,"matchesCrashFrame":1},"far":{"value":0}},"queue":"com.apple.main-thread","frames":[{"imageOffset":38724,"symbol":"__pthread_kill","symbolLocation":8,"imageIndex":31},{"imageOffset":27688,"symbol":"pthread_kill","symbolLocation":288,"imageIndex":32},{"imageOffset":486120,"symbol":"abort","symbolLocation":180,"imageIndex":33},{"imageOffset":175796,"sourceLine":49,"sourceFile":"assertions.c","symbol":"isc_assertion_failed","imageIndex":1,"symbolLocation":60},{"imageOffset":1639884,"sourceLine":198,"sourceFile":"request.c","symbol":"dns_requestmgr_shutdown","imageIndex":2,"symbolLocation":268},{"imageOffset":21684,"sourceLine":741,"sourceFile":"nsupdate.c","symbol":"maybeshutdown","imageIndex":0,"symbolLocation":60},{"imageOffset":44764,"sourceLine":2452,"sourceFile":"nsupdate.c","symbol":"update_completed","imageIndex":0,"symbolLocation":112},{"imageOffset":1654116,"sourceLine":949,"sourceFile":"request.c","symbol":"req_sendevent_cb","imageIndex":2,"symbolLocation":40},{"imageOffset":177220,"sourceLine":111,"sourceFile":"async.c","symbol":"isc__async_cb","imageIndex":1,"symbolLocation":448},{"imageOffset":25540,"symbol":"uv__async_io","symbolLocation":320,"imageIndex":12},{"imageOffset":90592,"symbol":"uv__io_poll","symbolLocation":1748,"imageIndex":12},{"imageOffset":26556,"symbol":"uv_run","symbolLocation":244,"imageIndex":12},{"imageOffset":317680,"sourceLine":282,"sourceFile":"loop.c","symbol":"loop_thread","imageIndex":1,"symbolLocation":372},{"imageOffset":444692,"sourceLine":85,"sourceFile":"thread.c","symbol":"thread_body","imageIndex":1,"symbolLocation":88},{"imageOffset":444556,"sourceLine":116,"sourceFile":"thread.c","symbol":"isc_thread_main","imageIndex":1,"symbolLocation":104},{"imageOffset":317004,"sourceLine":454,"sourceFile":"loop.c","symbol":"isc_loopmgr_run","imageIndex":1,"symbolLocation":472},{"imageOffset":7844,"sourceLine":3483,"sourceFile":"nsupdate.c","symbol":"main","imageIndex":0,"symbolLocation":420},{"imageOffset":24360,"symbol":"start","symbolLocation":2236,"imageIndex":34}]},{"id":45604295,"frames":[{"imageOffset":38996,"symbol":"poll","symbolLocation":8,"imageIndex":31},{"imageOffset":22728,"sourceLine":139,"sourceFile":"compat_futex.c","symbol":"compat_futex_async","imageIndex":21,"symbolLocation":76},{"symbol":"futex_async","inline":true,"imageIndex":21,"imageOffset":10276,"symbolLocation":28,"sourceLine":193,"sourceFile":"futex.h"},{"imageOffset":10276,"sourceLine":135,"sourceFile":"workqueue.c","symbol":"futex_wait","imageIndex":21,"symbolLocation":88},{"imageOffset":9564,"sourceLine":246,"sourceFile":"workqueue.c","symbol":"workqueue_thread","imageIndex":21,"symbolLocation":796},{"imageOffset":28584,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":32},{"imageOffset":7584,"symbol":"thread_start","symbolLocation":8,"imageIndex":32}]},{"id":45604816,"frames":[{"imageOffset":38996,"symbol":"poll","symbolLocation":8,"imageIndex":31},{"imageOffset":23824,"sourceLine":139,"sourceFile":"compat_futex.c","symbol":"compat_futex_async","imageIndex":20,"symbolLocation":76},{"symbol":"futex_async","inline":true,"imageIndex":20,"imageOffset":15652,"symbolLocation":28,"sourceLine":193,"sourceFile":"futex.h"},{"symbol":"wait_gp","inline":true,"imageIndex":20,"imageOffset":15652,"symbolLocation":44,"sourceLine":267,"sourceFile":"urcu.c"},{"imageOffset":15652,"sourceLine":359,"sourceFile":"urcu.c","symbol":"wait_for_readers","imageIndex":20,"symbolLocation":380},{"imageOffset":14924,"sourceLine":500,"sourceFile":"urcu.c","symbol":"urcu_memb_synchronize_rcu","imageIndex":20,"symbolLocation":476},{"imageOffset":22252,"sourceLine":381,"sourceFile":"urcu-call-rcu-impl.h","symbol":"call_rcu_thread","imageIndex":20,"symbolLocation":384},{"imageOffset":28584,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":32},{"imageOffset":7584,"symbol":"thread_start","symbolLocation":8,"imageIndex":32}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "arm64",
"base" : 4364058624,
"size" : 65536,
"uuid" : "fc5fc9ca-b970-4719-8d9d-1c52d49b85ca",
"path" : "\/Users\/USER\/*\/nsupdate",
"name" : "nsupdate"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4365385728,
"size" : 638976,
"uuid" : "6553893e-d490-4ced-97f1-6f2ab6fc025b",
"path" : "\/Users\/USER\/*\/libisc-9.19.21-dev.dylib",
"name" : "libisc-9.19.21-dev.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4369825792,
"size" : 2801664,
"uuid" : "350ca5b7-cb2b-46f8-9592-d7870788e644",
"path" : "\/Users\/USER\/*\/libdns-9.19.21-dev.dylib",
"name" : "libdns-9.19.21-dev.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4364845056,
"size" : 212992,
"uuid" : "500e50a8-58e3-4ee5-bd13-5be5df9ee128",
"path" : "\/Users\/USER\/*\/libisccfg-9.19.21-dev.dylib",
"name" : "libisccfg-9.19.21-dev.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4366778368,
"size" : 344064,
"uuid" : "d3c1a218-875c-45d8-92ec-e68a5824c086",
"path" : "\/Users\/USER\/*\/libns-9.19.21-dev.dylib",
"name" : "libns-9.19.21-dev.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4364550144,
"size" : 16384,
"uuid" : "c6878189-90b5-3d08-84f3-de63d925a475",
"path" : "\/opt\/local\/lib\/libmaxminddb.0.dylib",
"name" : "libmaxminddb.0.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4364713984,
"size" : 65536,
"uuid" : "d0a90a8e-5def-39e0-95ba-4d616af7843d",
"path" : "\/opt\/local\/lib\/liblmdb.dylib",
"name" : "liblmdb.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4365221888,
"size" : 65536,
"uuid" : "4a63b405-84ae-37fa-973c-c99ab2634dd6",
"path" : "\/opt\/local\/lib\/libz.1.3.dylib",
"name" : "libz.1.3.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4373348352,
"size" : 1441792,
"uuid" : "e64634dc-6335-326d-bad8-693b384a3426",
"path" : "\/Users\/USER\/*\/libjemalloc.2.dylib",
"name" : "libjemalloc.2.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4366303232,
"size" : 32768,
"uuid" : "55d0e643-f390-30c0-afb8-bb90ad791aae",
"path" : "\/opt\/local\/lib\/libjson-c.2.dylib",
"name" : "libjson-c.2.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4367253504,
"size" : 131072,
"uuid" : "04ae6ed8-9919-383a-a3bd-49cfda4df482",
"path" : "\/opt\/local\/lib\/libnghttp2.14.dylib",
"name" : "libnghttp2.14.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4368613376,
"size" : 917504,
"uuid" : "275b0d3d-c45c-3a11-9647-f59ff0501dfc",
"path" : "\/opt\/local\/lib\/libxml2.2.dylib",
"name" : "libxml2.2.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4367466496,
"size" : 114688,
"uuid" : "076fd891-2017-328a-a7d4-89d9faf42dde",
"path" : "\/opt\/local\/lib\/libuv.1.dylib",
"name" : "libuv.1.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4376608768,
"size" : 540672,
"uuid" : "b0393f6d-2afe-313d-bf36-e5f919b9e6cb",
"path" : "\/opt\/local\/libexec\/*\/libssl.3.dylib",
"name" : "libssl.3.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4381523968,
"size" : 2965504,
"uuid" : "3189ddc3-b9ec-33cb-af81-0a7f01bd4280",
"path" : "\/opt\/local\/libexec\/*\/libcrypto.3.dylib",
"name" : "libcrypto.3.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4367728640,
"size" : 212992,
"uuid" : "0223e7e9-a50c-3d53-96fa-841a0b2125b6",
"path" : "\/opt\/local\/lib\/libgssapi_krb5.2.2.dylib",
"name" : "libgssapi_krb5.2.2.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4378198016,
"size" : 524288,
"uuid" : "60f5165b-b650-3afe-b99a-49b8c4a8213d",
"path" : "\/opt\/local\/lib\/libkrb5.3.3.dylib",
"name" : "libkrb5.3.3.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4366499840,
"size" : 65536,
"uuid" : "3b40599e-83d4-36d9-bf5d-978b55a6186a",
"path" : "\/opt\/local\/lib\/libk5crypto.3.1.dylib",
"name" : "libk5crypto.3.1.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4364615680,
"size" : 16384,
"uuid" : "ddbf7057-c200-3a1c-8279-03a92e74e9a0",
"path" : "\/opt\/local\/lib\/libcom_err.1.1.dylib",
"name" : "libcom_err.1.1.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4368236544,
"size" : 131072,
"uuid" : "a368e05a-b24b-3f87-885c-176dd89d538f",
"path" : "\/opt\/local\/lib\/libedit.0.dylib",
"name" : "libedit.0.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4366614528,
"size" : 32768,
"uuid" : "bfb91bed-832b-3dfe-9ba0-0a0ed23bf291",
"path" : "\/Users\/USER\/*\/liburcu.8.dylib",
"name" : "liburcu.8.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4368039936,
"size" : 32768,
"uuid" : "fce9d042-2e9d-3f6a-bd48-2c436aa2c3be",
"path" : "\/Users\/USER\/*\/liburcu-cds.8.dylib",
"name" : "liburcu-cds.8.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4365320192,
"size" : 16384,
"uuid" : "9a24f984-8a16-39d4-a5cc-5d5c303f349e",
"path" : "\/Users\/USER\/*\/liburcu-common.8.dylib",
"name" : "liburcu-common.8.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4377411584,
"size" : 131072,
"uuid" : "67f10b23-041f-3578-b51c-22d5a66c7ff7",
"path" : "\/opt\/local\/lib\/liblzma.5.dylib",
"name" : "liblzma.5.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4380147712,
"size" : 1064960,
"uuid" : "5fec81f0-90a7-34f9-afa5-27882cebd803",
"path" : "\/opt\/local\/lib\/libiconv.2.dylib",
"name" : "libiconv.2.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4388470784,
"size" : 1638400,
"uuid" : "b9f63e5c-0953-3fdd-818f-5281f283526a",
"path" : "\/opt\/local\/lib\/libicui18n.74.1.dylib",
"name" : "libicui18n.74.1.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4391305216,
"size" : 1261568,
"uuid" : "34bfb2bf-1dd1-3d1f-9ce9-fdfd37ff8475",
"path" : "\/opt\/local\/lib\/libicuuc.74.1.dylib",
"name" : "libicuuc.74.1.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4424155136,
"size" : 30801920,
"uuid" : "364b1ef5-ef47-32b8-a939-f19d872051a7",
"path" : "\/opt\/local\/lib\/libicudata.74.1.dylib",
"name" : "libicudata.74.1.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4368154624,
"size" : 32768,
"uuid" : "986d8b90-c209-3c3c-b319-b5d8a61c7aca",
"path" : "\/opt\/local\/lib\/libkrb5support.1.1.dylib",
"name" : "libkrb5support.1.1.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4368433152,
"size" : 49152,
"uuid" : "149107de-c05b-36cc-9fdc-a7a784cec35f",
"path" : "\/opt\/local\/lib\/libintl.8.dylib",
"name" : "libintl.8.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4378984448,
"size" : 245760,
"uuid" : "64dbc603-ea0b-3259-8ba5-d0fbd3d5954c",
"path" : "\/opt\/local\/lib\/libncurses.6.dylib",
"name" : "libncurses.6.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6978498560,
"size" : 237544,
"uuid" : "6024d562-0a3b-3568-8ee2-1741160ba022",
"path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
"name" : "libsystem_kernel.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6978736128,
"size" : 53248,
"uuid" : "7acb080f-eabe-3a59-8d9f-7459f33bb263",
"path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6977286144,
"size" : 520184,
"uuid" : "840fe68c-8175-347b-bfb1-3b6bce431935",
"path" : "\/usr\/lib\/system\/libsystem_c.dylib",
"name" : "libsystem_c.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6975234048,
"size" : 583048,
"uuid" : "b35b0343-b5b9-3204-8eba-8dad651a4e3a",
"path" : "\/usr\/lib\/dyld",
"name" : "dyld"
}
],
"sharedCache" : {
"base" : 6974570496,
"size" : 3585916928,
"uuid" : "eccd2a5c-66b8-3acf-a00a-c68fea25a443"
},
"vmSummary" : "ReadOnly portion of Libraries: Total=965.2M resident=0K(0%) swapped_out_or_unallocated=965.2M(100%)\nWritable regions: Total=596.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=596.5M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nCoreMedia Capture Data 13.5M 49 \nKernel Alloc Once 32K 1 \nMALLOC 137.2M 13 \nMALLOC guard page 96K 6 \nMALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 48K 3 \nStack 65.0M 3 \n__AUTH 320K 62 \n__AUTH_CONST 3740K 147 \n__DATA 3079K 170 \n__DATA_CONST 5190K 178 \n__DATA_DIRTY 361K 58 \n__LINKEDIT 808.6M 32 \n__OBJC_RO 66.4M 1 \n__OBJC_RW 2012K 1 \n__TEXT 156.6M 187 \ndyld private memory 272K 2 \nshared memory 32K 2 \n=========== ======= ======= \nTOTAL 1.6G 916 \nTOTAL, minus reserved VM space 1.2G 916 \n",
"legacyInfo" : {
"threadTriggered" : {
"queue" : "com.apple.main-thread"
}
},
"logWritingSignature" : "490eba448e2f7f291b7eb689c23aab8ca82c55b9",
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "639124e81d92412bfb4880b3",
"factorPackIds" : {
},
"deploymentId" : 240000012
},
{
"rolloutId" : "60186475825c62000ccf5450",
"factorPackIds" : {
},
"deploymentId" : 240000068
}
],
"experiments" : [
]
}
}
```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/4528rndc reconfig/reload ignores changes to listen-on statements when port or int...2024-03-11T14:38:57ZArtem Boldarievrndc reconfig/reload ignores changes to listen-on statements when port or interface address are left unchangedOne could change `listen-on` statements to change DNS transports without changing both port and interface addresses. For example, one could change a line:
```
listen-on port 1234;
```
to
```
listen-on port 1234 tls some-tls-config;
``...One could change `listen-on` statements to change DNS transports without changing both port and interface addresses. For example, one could change a line:
```
listen-on port 1234;
```
to
```
listen-on port 1234 tls some-tls-config;
```
and then run `rndc reconfig`. However, that would not work because we lack a mechanism for changing listener type. Moreover, the example above will crash BIND with abort() because the code will try to update a TLS context on a listener that does not support TLS.
The problem was found while investigating issue #4518, which can be considered a special case of this issue: it can be described as a lack of ability to update/recreate listeners on reconfiguration.
The solution is to always recreate listeners on listener type change (e.g. Do53->DoT or enabling PROXY). That partially raises the issue mentioned in #3122, but there is no way around that except for allowing any process to bind "privileged" ports on affected platforms (read: BSDs). That might bring some troubles, but:
It is a very edge case, as listener types do not change often. The fact that no one has reported the issue in at least two years or more proves that.
We have no mechanism to dynamically change layers in an active listener, and it is hard to justify adding such a complex mechanism in the critical part of the code.
**P.S.**
Historically, we would recreate listeners on reconfiguration for new transports in order to ensure that TLS certificates are reloaded, but we changed that (see #3122 and, to a lesser extent, #3415, as well as the related merge requests for additional details). That made this issue more apparent, although even back then, reconfiguration would have been broken for plain HTTP/2 listeners.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/4527DoT responses are split into two TLS frames2024-03-08T05:25:17ZPetr Špačekpspacek@isc.orgDoT responses are split into two TLS frames### Summary
DNS message length and the rest of DNS message are sent as two separate TLS frames. This is **not** a protocol issue, it's just a subtle sub-optimality which triggers bugs in other **non-compliant** DoT clients (like Flameth...### Summary
DNS message length and the rest of DNS message are sent as two separate TLS frames. This is **not** a protocol issue, it's just a subtle sub-optimality which triggers bugs in other **non-compliant** DoT clients (like Flamethrower 0.11.0 [0ee1fba](https://github.com/DNS-OARC/flamethrower/commit/0ee1fba170d7673e32dc0226d08732fd08acc7ac)).
### BIND version affected
* ~"Affects v9.19": a6fb9184546
Version ~"v9.18" does not seem to be affected.
### Steps to reproduce
Generally - do a DoT query and watch content of TLS stream in Wireshark. I'm using Flamethrower which does not recognize the split answer because of it's own bug.
1. $ named -g -c [named.conf](/uploads/99544c0fb6bbf8f9b6f373fd8933851b/named.conf)
2. $ export SSLKEYLOGFILE=/tmp/tlskeys
3. $ tcpdump -n -i lo 'host 127.0.0.1 and port 853' -w /tmp/dot-answer-in-two-tls-frames.pcap
4. $ flame 127.0.0.1 -q 1 -P dot -c 1 -l 5
5. $ sudo pkill tcpdump
- [dot-answer-in-two-tls-frames.pcap](/uploads/1302147320c7cea67ceb613071f7a83f/dot-answer-in-two-tls-frames.pcap)
6. Configure Wireshark to read /tmp/tlskeys file according to https://wiki.wireshark.org/TLS#extracting-decryption-secrets-to-a-text-file
7. Inspect the PCAP: $ wireshark /tmp/dot-answer-in-two-tls-frames.pcap
### What is the current *bug* behavior?
Packet with DNS answer looks like this:
```
Transmission Control Protocol, Src Port: 853, Dst Port: 46339, Seq: 1358, Ack: 515, Len: 99
Transport Layer Security
[2 Reassembled TLS segments (55 bytes): #13(2), #13(53)]
[Frame: 13, payload: 0-1 (2 bytes)]
[Frame: 13, payload: 2-54 (53 bytes)]
[Segment count: 2]
[Reassembled PDU length: 55]
[Reassembled PDU data: 0035394e81800001000100000001047465737403636f6d0000010001c00c0001000100000931000443e192f800002904d0000000000000]
Domain Name System (response)
Length: 53
Transaction ID: 0x394e
Flags: 0x8180 Standard query response, No error
...
```
### What is the expected *correct* behavior?
Preferably just one TLS frame with message length + payload.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/4522Dig in 9.19.19 accept weird source- and destination-ports within the "proxy"-...2024-03-08T05:12:06ZThomas AmgartenDig in 9.19.19 accept weird source- and destination-ports within the "proxy"-statement### Summary
`dig` in 9.19.19 allows weird source- and destination ports within the new `proxy`-statement.
### BIND version affected
```
$ dig -v
DiG 9.19.19
```
### Steps to reproduce
Run `dig` with a source- or destination port state...### Summary
`dig` in 9.19.19 allows weird source- and destination ports within the new `proxy`-statement.
### BIND version affected
```
$ dig -v
DiG 9.19.19
```
### Steps to reproduce
Run `dig` with a source- or destination port statement >65535 (+proxy=127.0.0.1#**23784238942739842738942374**-127.0.0.1#**234234234234238423984234234234**). Although the port is fix set to 65535, `dig` accepts a value >65535:
```
$ dig @test -p 5353 +proxy=127.0.0.1#23784238942739842738942374-127.0.0.1#234234234234238423984234234234 www.isc.org
; <<>> DiG 9.19.19 <<>> @test -p 5353 +proxy www.isc.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12881
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f0ee394660e9fe95010000006597c815b35dc2d99d32e656 (good)
;; QUESTION SECTION:
;www.isc.org. IN A
;; ANSWER SECTION:
www.isc.org. 160 IN CNAME isc.map.fastlydns.net.
isc.map.fastlydns.net. 24 IN A 151.101.38.217
;; Query time: 4 msec
;; SERVER: 10.100.102.21#5353(test) (UDP)
;; CLIENT PROXY HEADER: source: 127.0.0.1#65535, destination: 127.0.0.1#65535
;; WHEN: Fri Jan 05 10:12:53 CET 2024
;; MSG SIZE rcvd: 119
```
### What is the current *bug* behavior?
See above.
### What is the expected *correct* behavior?
I would expect, that `dig` doesn't allow a weird port setting.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/4521Timeout in dig not handled in system tests2024-03-07T22:44:44ZMark AndrewsTimeout in dig not handled in system testsJob [#3918128](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3918128) failed for 47a16b58326221f6c7972b32d67fdecfdcd202ba:
```
bin/tests/system/rndc_tmp_geya4m_a/dig.out.4.test31:;; communications error to 10.53.0.4#24164: timed out
...Job [#3918128](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3918128) failed for 47a16b58326221f6c7972b32d67fdecfdcd202ba:
```
bin/tests/system/rndc_tmp_geya4m_a/dig.out.4.test31:;; communications error to 10.53.0.4#24164: timed out
bin/tests/system/rndc_tmp_geya4m_a/dig.out.1.test55:;; communications error to 10.53.0.6#24164: timed out
bin/tests/system/rndc_tmp_geya4m_a/dig.out.1.test55:;; communications error to 10.53.0.6#24164: timed out
bin/tests/system/rndc_tmp_geya4m_a/dig.out.1.test55:;; communications error to 10.53.0.6#24164: timed out
```
Also in serve-staleMarch 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/4520Log message in lib/ns/update.c needs updating2024-03-08T05:21:18ZMark AndrewsLog message in lib/ns/update.c needs updatingThis message in lib/ns/update.c should report the actual type being ignored. It could be CDNSKEY, DNSKEY, or CDS.
```
update_log(client, zone,
...This message in lib/ns/update.c should report the actual type being ignored. It could be CDNSKEY, DNSKEY, or CDS.
```
update_log(client, zone,
LOGLEVEL_PROTOCOL,
"attempt to "
"delete in use "
"DNSKEY ignored");
```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/4519Check return value of snprintf in lib/isccfg/check.c2024-03-08T07:31:23ZMatthijs Mekkingmatthijs@isc.orgCheck return value of snprintf in lib/isccfg/check.cThe following [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924#note_426161) from !5924 should be addressed.
There are two occurrences where the return value of `snprintf` is not checked. We should check the r...The following [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924#note_426161) from !5924 should be addressed.
There are two occurrences where the return value of `snprintf` is not checked. We should check the return value of `snprintf` to protect from overflow. When ignoring this, the character string in the buffer is probably not terminating by a NUL byte any longer because of the truncation.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/4518BIND-9.19.19 doesn't honor "rndc reload" for enabling/disabling the new proxy...2024-03-12T08:29:25ZThomas AmgartenBIND-9.19.19 doesn't honor "rndc reload" for enabling/disabling the new proxy-mechanism### Summary
Testing BIND-9.19.19 with the new proxy protocol function, I recognized, that enabling/disabling the proxy-statement on the `listen-on`-statement requires a restart of named and doesn't be honored with `rndc reload`.
I'm no...### Summary
Testing BIND-9.19.19 with the new proxy protocol function, I recognized, that enabling/disabling the proxy-statement on the `listen-on`-statement requires a restart of named and doesn't be honored with `rndc reload`.
I'm not sure, if this is a bug or if it works as expected.
### BIND version affected
```
$ named -V
BIND 9.19.19 (Development Release) <id:18a05ca>
running on Linux x86_64 4.18.0-425.19.2.el8_7.x86_64 #1 SMP Tue Apr 4 22:38:11 UTC 2023
built by make with '--prefix=/usr/local/bind-9.19.19' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-dnstap' '--with-libxml' '--enable-singletrace' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.5.0 20210514 (Red Hat 8.5.0-16)
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.1
linked to libuv version: 1.41.1
compiled with liburcu version: 0.10.1
compiled with jemalloc version: 5.2.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
```
### Steps to reproduce
- Start `named` without the proxy-feature
```listen-on port 5353 { 10.100.102.21; 127.0.0.1; };```
- Afterwards, add the proxy-feature to the `listen-on`-statement
```listen-on port 5353 proxy plain { 10.100.102.21; 127.0.0.1; };```
- Reload `named` with `rndc reload`
- Verify, if `named` honors the proxy-protocol (what's **not** the case now):
```
$ dig @10.100.102.21 -p 5353 isc.org +proxy
;; Warning: ID mismatch: expected ID 10605, got 3338
```
- Because that's not working now, do a restart of `named`:
`$ systemctl restart named`
- Query the resolver again:
```
$ dig @10.100.102.21 -p 5353 isc.org +proxy
; <<>> DiG 9.19.19 <<>> @10.100.102.21 -p 5353 isc.org +proxy
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62575
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6c3f83b370b29227010000006596bff6545d52c215a2e120 (good)
;; QUESTION SECTION:
;isc.org. IN A
;; ANSWER SECTION:
isc.org. 300 IN A 149.20.2.28
;; Query time: 356 msec
;; SERVER: 10.100.102.21#5353(10.100.102.21) (UDP)
;; CLIENT PROXY HEADER: LOCAL
;; WHEN: Thu Jan 04 15:25:58 CET 2024
;; MSG SIZE rcvd: 80
```
### What is the current *bug* behavior?
`named` doesn't honor enabling/disabling the proxy-feature in the `listen-on`-statement with `rndc reload`. Only a restart of `named` makes this working.
### What is the expected *correct* behavior?
A `rndc reload` should be enough to enabling/disabling the proxy-feature.
### Relevant configuration files
See the `listen-on`-snippet above.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldariev