ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-02-24T08:17:15Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4586Don't count expired / future RRSIGs in verification failure quota2024-02-24T08:17:15ZMark AndrewsDon't count expired / future RRSIGs in verification failure quotaExpired / future RRSIGs don't trigger a public key verification.Expired / future RRSIGs don't trigger a public key verification.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4580Add resolver.arpa to the built in empty zones2024-03-21T00:23:52ZMark AndrewsAdd resolver.arpa to the built in empty zonesRFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served z...RFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served zone per [RFC6303]. In practice, this means that resolvers SHOULD respond to queries of any
type other than SVCB for _dns.resolver.arpa. with NODATA and queries of any type for any domain name under
resolver.arpa with NODATA.
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4571findnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_c...2024-03-08T08:24:37ZMark Andrewsfindnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_currentThese are not currently reference counted by if they where it would introduce a memory/reference leak.These are not currently reference counted by if they where it would introduce a memory/reference leak.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/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/kea/-/issues/3247changes in hammer for rocky linux2024-03-28T08:11:54ZMarcin Godzinachanges in hammer for rocky linuxWe need to extend Hammer to build on Rocky Linux 9. We have a business need for this.We need to extend Hammer to build on Rocky Linux 9. We have a business need for this.kea2.5.8Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/stork/-/issues/1307Missing empty placeholder in some tables2024-03-28T14:13:56ZSlawek FigielMissing empty placeholder in some tablesThe issue was found by @piotrek during 1.15 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1296#note_434139
Some tables don't display feedback about empty data set:
![image](https://gitlab.isc.org/isc-projects/stork/...The issue was found by @piotrek during 1.15 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1296#note_434139
Some tables don't display feedback about empty data set:
![image](https://gitlab.isc.org/isc-projects/stork/uploads/497ba0f438fff4d1587a392bfe251491/image.png)
Also Total# of subnets is not 0, but nothing is displayed.1.16Piotrek ZadrogaPiotrek Zadrogahttps://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/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/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/4535"digdelv" system test often fails the "try the next server after a TCP socket...2024-02-24T07:57:52ZMichał Kępień"digdelv" system test often fails the "try the next server after a TCP socket connection error/timeout" checkFor at least the past two weeks or so, the following check in the
`digdelv` system test has been failing particularly often, for no
apparent reason that I could think of:
```
2024-01-14 04:17:49 INFO:digdelv I:digdelv_tmp_aq8itlsn:c...For at least the past two weeks or so, the following check in the
`digdelv` system test has been failing particularly often, for no
apparent reason that I could think of:
```
2024-01-14 04:17:49 INFO:digdelv I:digdelv_tmp_aq8itlsn:check that dig tries the next server after a TCP socket connection error/timeout (89)
2024-01-14 04:18:09 INFO:digdelv I:digdelv_tmp_aq8itlsn:failed
```
It is an intermittent failure. It seems to be at least strongly
"preferring" FreeBSD jobs (and may even be exclusive to these, but I
have not checked all of its occurrences):
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3926964
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3938693
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3938692
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939505
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939504
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939503
The check itself dates back to March 2022 (!5976), so it is surprising
to only see an uptick in its failures now. Perhaps some other fix
merged in the meantime changed `dig` behavior in a way that trips this
logic up?May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://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/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/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)