BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-02T13:23:23Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4559Convert DNS_GETDB_ into struct with 1-bit long booleans2024-02-02T13:23:23ZOndřej SurýConvert DNS_GETDB_ into struct with 1-bit long booleansSee https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8683#note_433377 for details:
> Going step further, I think it can very well be a struct with booleans. It should cost nothing because compiler is not stupid nowadays and it...See https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8683#note_433377 for details:
> Going step further, I think it can very well be a struct with booleans. It should cost nothing because compiler is not stupid nowadays and it will make decoding values in coredumps easier.
>
> (To be clear - I mean something like this: !6902 (merged))https://gitlab.isc.org/isc-projects/bind9/-/issues/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/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/4544"primaries" block documentation issues2024-01-23T15:27:16ZRay Bellis"primaries" block documentation issuesI'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years ...I'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years within the `also-notify` section of primary zones.
There's no direct mention of `primaries` in the grammar of an `also-notify` block. I _suspect_ that it's covered by `<remote-servers>` but the only link between `primaries` and `remote-servers` is this text in the glossary:
> remote-servers: A named list of one or more ip_addresses with optional tls_id, server_key, and/or port. A remote-servers list may include other remote-servers lists. See primaries block.
If in fact a `<remote-servers>` reference _is_ a (named) `primaries` list, then that ought to be spelled out more explicitly, and the documentation updated to reflect that this can be used in *any* `allow-notify` block in any applicable zone type.
I'd also suggest that the top level grammar ought to actually be called `xfer-servers` instead of `masters` and then that term used in place of `remote-servers` in the ARM. In the NOTIFY case the listed servers are secondaries, not primaries, and it makes no sense to call them primaries.
[`remote-servers` also causes confusion with `server <prefix> { }` used to specify per-server EDNS overrides, etc]Long-termMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4543Re-enable unreachable checks in dnssec system test2024-02-24T07:55:26ZTom KrizekRe-enable unreachable checks in dnssec system testIn https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been a...In https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been accidentally added to the `dnssec` test, making the remaining checks unreachable.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4542XoT: Primaries should be able to have different allow-transfer acls per trans...2024-01-22T13:10:56ZDave KnightXoT: Primaries should be able to have different allow-transfer acls per transport or ACLs should be extended with port and transport options### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per tr...### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per transport.
I want to require XoT for transfers over the Internet, but allow insecure AXFR to localnets.
It's not possible to have multiple allow-transfer definitions, i.e. this
allow-transfer port 53 transport tcp { acl_for_nonxot_clients; };
allow-transfer port 853 transport tls { acl_for_xot_clients; };
results in
'allow-transfer' redefined near 'allow-transfer'
And my understanding is that we can't refer to ports or transport in an acl.
### Request
Either allow multiple allow-transfer clauses, treating "allow transfer transport tcp" and "allow transfer transport tls" as different things, which can have their own acl specification, or add port and transport to the acl so that this can be controlled there.
### Links / referencesLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4540RFC 9471 DNS Glue Requirements in Referral Responses2024-02-08T10:27:45ZPeter DaviesRFC 9471 DNS Glue Requirements in Referral Responses[RFC 9471](https://www.rfc-editor.org/rfc/rfc9471.html) - DNS Glue Requirements in Referral Responses
It would be of help to users to implement RFC 9471 and allow BIND to reply TC=1 when
glue records would make a UDP reply larger than...[RFC 9471](https://www.rfc-editor.org/rfc/rfc9471.html) - DNS Glue Requirements in Referral Responses
It would be of help to users to implement RFC 9471 and allow BIND to reply TC=1 when
glue records would make a UDP reply larger than the maxium allowed.
3.2. Glue for Sibling Domain Name Servers
This document clarifes that when a name server generates a referral response, it
include all available glue records in the additional section. If, after adding glue for all in-domain
name servers, the glue for all sibling domain name servers does not ft due to message size
constraints, the name server set TC=1 but is not obligated to do so.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4538duplicate TLS session tickets from BIND2024-01-17T18:01:29ZPetr Špačekpspacek@isc.orgduplicate TLS session tickets from BIND### Summary
BIND sends **two** TLS session tickets in a row, in the same TCP frame. This looks like a bug. Probably no real-world impact except consuming a bit of extra bandwidth.
### BIND version affected
* ~"Affects v9.19" : e39b5447...### Summary
BIND sends **two** TLS session tickets in a row, in the same TCP frame. This looks like a bug. Probably no real-world impact except consuming a bit of extra bandwidth.
### BIND version affected
* ~"Affects v9.19" : e39b544704b98ddd8a19e317373b84ac74597f76 - noticed while testing !8646
* ~"Affects v9.18" : 071de1b5b54c27b1291bd97e3a95a93b1996eddc - isc-private/bind9!585
### Steps to reproduce
1. SSLKEYLOGFILE=/tmp/tlskeys /tmp/4527-improve-tls-framing-for-dot/sbin/named -g -c /tmp/named.conf
2. sudo tcpdump -i lo -w /tmp/tls.pcap 'port 853'
3. dig @127.0.0.1 +tls
- [tls.pcap](/uploads/e5836a9693d76f117c9e5c80f15cf2b1/tls.pcap)
- [tlskeys](/uploads/76d398d1c33b7eb90f4c7a14ff27a644/tlskeys)
### What is the current *bug* behavior?
For some reason BIND sends **two** TLS session tickets in a row, in the same TCP frame.
<details>
```
Frame 10: 608 bytes on wire (4864 bits), 608 bytes captured (4864 bits)
Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 853, Dst Port: 46779, Seq: 766, Ack: 476, Len: 542
Transport Layer Security
TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
Opaque Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 266
[Content Type: Handshake (22)]
Handshake Protocol: New Session Ticket
Handshake Type: New Session Ticket (4)
Length: 245
TLS Session Ticket
Session Ticket Lifetime Hint: 7200 seconds (2 hours)
Session Ticket Age Add: 1399829672
Session Ticket Nonce Length: 8
Session Ticket Nonce: 0000000000000000
Session Ticket Length: 224
Session Ticket [truncated]: 5f2c5c7290f6b002e39631b54f85b14de2620e615663e5e3a2a5c5194a3e5c47d5da9fc257200fe4318de304b2471b4a1f35607e53e0a3eb04e00421e2539bcdbf486e60ec9900448831dc70c1dcb081c0890d04c337dbe4aef4806dd5004019a0a7edfabbf17de7590
Extensions Length: 0
TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
Opaque Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 266
[Content Type: Handshake (22)]
Handshake Protocol: New Session Ticket
Handshake Type: New Session Ticket (4)
Length: 245
TLS Session Ticket
Session Ticket Lifetime Hint: 7200 seconds (2 hours)
Session Ticket Age Add: 310059667
Session Ticket Nonce Length: 8
Session Ticket Nonce: 0000000000000001
Session Ticket Length: 224
Session Ticket [truncated]: 5f2c5c7290f6b002e39631b54f85b14dc423d6b1f00ccd25e30d7cf9290c0dc32d8ed4b9c72a8e3555d9ccdba4b3b6299e5306c5bf9ca48f72325e23927d1e9ae572d8937faedeb7b5846b4f8817bef5e537a5ff8e516c20f520ebb535ab37fa64996854d10dcee1291
Extensions Length: 0
```
</details>
### What is the expected *correct* behavior?
I would expect just one ticket.Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4532An option to not have bind9/dnssec-settime (possibly other tools) reset permi...2024-01-16T20:30:36ZDan MahoneyAn option to not have bind9/dnssec-settime (possibly other tools) reset permissions on a .private file.### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using gi...### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using git, with a group-shared repository.
Typical permissions on .private files are bind:bind with mode 660, but because a normal user (in the bind group) diffs/commits/pushes the repository, these keys can also be user:bind mode 660.
(Noting as well that our tooling is not more comfortable running git tasks as root, complaining of other permissions issues. Also, the less we can do as root, the better.)
With bind's usual permissions model, one cannot do a git diff/git log if the file is owned by bind. If the file is owned by user:bind, bind loses access to it on the permissions change.
Changing the umask under which the process runs doesn't seem to fix this, we tried.
Running a periodic cron job to fix this is a possible workaround, but feels like it shouldn't be necessary.
### Request
For command line tools, an option to not do this.
For `named, an `options` statement that lets us turn this off.
Both retaining the current behavior by default.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4525bind acl doesn't respect interface identifier (in ipv6 link local address)2024-01-09T06:15:55Zelmaimbobind acl doesn't respect interface identifier (in ipv6 link local address)### Summary
Although BIND allows you to configure an IPv6 address with an interface identifier (e.g. fe80::1%ne0) in an "acl" statement, when it tests if an address satisfies the acl, it seems to only look at the address and ignores the...### Summary
Although BIND allows you to configure an IPv6 address with an interface identifier (e.g. fe80::1%ne0) in an "acl" statement, when it tests if an address satisfies the acl, it seems to only look at the address and ignores the interface identifier when performing the check.
### BIND version affected
```
# named -V
BIND 9.18.18-0ubuntu2-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-UHPUkp/bind9-9.18.18=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/bind9-UHPUkp/bind9-9.18.18=/usr/src/bind9-1:9.18.18-0ubuntu2 -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 13.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.55.1
linked to libnghttp2 version: 1.55.1
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.17
linked to json-c version: 0.17
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
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): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
These steps require access to two machines, each having an IPv6 link-local address on a shared network segment. One of the machines needs to have an operational installation of BIND. The other machine needs the dig utility, or a similar tool that allows a DNS query to be sent to a specific IPv6 address.
1. On the BIND machine (server A), run `ip -6 address` and verify that the server has a loopback interface (lo) with IPv6 address `::1`, and at least one other network interface that has a link-local address `fe80::xxxx:xxxx:xxxx:xxxx/64`. Make a note of the name of the interface name and the link-local address.
2. On the other machine (server B), run `ip -6 address` and make a note of the interface name that is on the same network as the BIND machine.
3. Verify connectivity between the servers by pinging from server B to the link-local address of server A -- including server B's interface identifier. E.g.: `ping fe80::1e69:7aff:fe6c:2ab0%eno1`
4. On server A, edit the BIND configuration and add `acl testing { fe80::/64; };`, and also include "testing;" at the start of both `allow-query` and `allow-recursion` options. Run `rndc reload` to apply the configuration changes.
5. On server B, verify that you can use dig (or similar) to successfully query a DNS name using the the same link-local address used in the ping test above. E.g.: `dig google.com @fe80::1e69:7aff:fe6c:2ab0%eno1`
6. Now change the "acl testing" block to `acl testing { !fe80::%lo/64; fe80::/64; };`. The idea here is that we are disallowing queries coming from link-local addresses on the loopback interface. In theory this should make no difference to our test, since our query isn't coming in the loopback interface. Run `rndc reload` to apply the configuration changes.
7. Repeat the "dig" test, and you will find that the BIND server will now refuse the request. This shows that BIND considers that the request satisfies "!fe80::%lo/64;" when in fact it shouldn't because it doesn't originate from the loopback interface.
### What is the current *bug* behavior?
BIND seems to ignore the interface identifier for IPv6 addresses when applying acls.
### What is the expected *correct* behavior?
BIND should observe the interface identifier as described in the [documentation](https://bind9.readthedocs.io/en/latest/reference.html#term-ipv6_address). Please note that interface identifiers may also contain VLAN IDs - e.g. "eno1.20".
### Relevant configuration files
FYI I am trying to use ACLs similar to the following, to differentiate between requests originating on link-local addresses from different interfaces, so that the queries are handled by different views:
```
acl trusted-networks {
127.0.0.0/8;
::1;
fe80::%eno1.20/64;
fe80::%eno1.160/64;
fe80::%tun1/64;
};
acl dmz-networks {
fe80::%eno1.192/64;
};
```
### Relevant logs
All my logs show is that the wrong view is being used, due to this bug.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4523dnstap support for new transport protocols2024-03-08T09:03:02ZPeter Daviesdnstap support for new transport protocols### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS ...### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS and DNS over HTTPS, users may wish to
differentiate between these transports in dnstap output.
### Links / references
The current dnstap protobuf lists support for DoT, DoH:
see https://github.com/dnstap/dnstap.pb/blob/master/dnstap.protoAydın MercanAydın Mercanhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4517dnssec-verify reports errors in NSEC3 chain2024-02-24T07:53:57ZLibor Peltandnssec-verify reports errors in NSEC3 chain### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the f...### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Bad NSEC3 record for fadb1aa3f.6DA7ffbF, bit map mismatch
Expected and found NSEC3 chains not equal
Break in NSEC3 chain at: VKGD3TE5QRGB6S0KJH6UV3FKS9FUMRIV
Expected: 01EAMK8ES71TN6TKHOK512LQMCORC5O9
Found: 0R6S95GSLHH7HT7MFN2N1NJGNFS7Q2CQ
DNSSEC completeness test failed (failure).
```
I'd say that the NSEC3 chain is however correct.
Some notes:
- opt-out is not used
- `fadb1aa3f.6da7ffbf.` -> `01eamk8es71tn6tkhok512lqmcorc5o9.6da7ffbf.` (first NSEC3 lexicographically, but this probably doesnt care)
- `427e09.owa.6da7ffbf.` -> `vkgd3te5qrgb6s0kjh6uv3fks9fumriv.6da7ffbf.` (last NSEC3 lexicographically)
- node `fadb1aa3f.6da7ffbf.` is "weird" in the way that it's a delegation with non-authoritative data: MX and even DNSKEY(!), but this shouldn't influence the chaining of NSEC3, moreover, it relates to the bitmap at 01EAMK... and not VKGD3T...
### BIND version affected
```
$ dnssec-verify -V
dnssec-verify 9.18.18-0ubuntu0.22.04.1-Ubuntu
```
### Steps to reproduce
Use faketime as the RRSIGs are expired already. It doesn't matter since the errors are related to NSEC3s and not signatures.
The zone file in question is attached.
Just call `$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone`
### What is the current *bug* behavior?
Verify reports errors in the attached zone's NSEC3 chain.
### What is the expected *correct* behavior?
No errors reported.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4505Implement kTLS support in BIND2024-02-14T17:13:53ZArtem BoldarievImplement kTLS support in BIND
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user sp...
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user space, including offloading TLS encryption to the NICs that support that (e.g. [NVIDIA Mellanox ConnectX-6 Dx](https://www.nvidia.com/en-us/networking/ethernet/connectx-6-dx/)), almost completely freeing the CPU from this task, because even in the case of hardware acceleration of encryption within the CPU, it still requires some cycles from it. Also, using it might reduce memory copying in some cases.
Of course, kernel space encryption is more limited compared to the one provided by OpenSSL and its derivatives in the user space: these limitations are imposed by hardware - e.g. NICs might not support anything but AES 128 (aka `TLS_AES_128_GCM_SHA256`), as it is the only cipher mandatory for TLS v1.3). If it is good enough for WEB servers, it should be good enough for DNS, too.
Even when kTLS is used, the handshake itself happens in the user space (e.g. using OpenSSL) with negotiated parameters passed to the kernel using `setsockopt()` calls on a TCP socket descriptor.
OpenSSL provides support for kTLS encryption natively since version 3.X (see `SSL_OP_ENABLE_KTLS` [option](https://www.openssl.org/docs/manmaster/man3/SSL_set_options.html)) but, as far as I understand it, it does so only when OpenSSL manages the underlying TCP socket file descriptor natively: not our case, as we are using LibUV for that. However, considering that the idea of kTLS is that with it enabled, we are supposed to pass unencrypted data to `send()` and `recv()`, that is kTLS-enabled socket from the higher level perspective works (mostly) as a TCP socket, we might try the following approach to implement kTLS, that *might* work:
1. We use our existing code (`tlsstream.c`) to handle handshake, just like we do now;
2. After completing the handshake, we pass the negotiated information to the kernel. OpenSSL might have some interfaces for that. In the worst case, we might need to do that by hand using. `setsockopt()`;
3. Then, we add new code paths to `tlsstream.c` to bypass TLS connection objects (`isc_tls_t`) and use the underlying TCP connection directly, which, by now, works in "kTLS-mode", providing transparent TLS encryption;
4. Control messages, like TLS shutdown, will require additional care.
That is how I see the initial plan that might or might not work. There can (and, likely, will) be unforeseen obstacles that might turn out to overcomplicate the code base so much that it might make it unfeasible to implement, like adding a kTLS-only transport. Furthermore, that might require some assistance from LibUV. That will require some trial and error.
That is mostly written with Linux in mind. If the kTLS interface in FreeBSD is similar enough (it seems so at the first glance), we should support both platforms.
The issue is created mostly to dump the information from my mind and keep kTLS under our radar: we might want to do that, as at least `dnsdist` has experimental support for it. It will be even more important in the future, as it seems now that encrypted DNS transport will be even more important to the point of replacing the good ol' Do53 at some point.
For sure, it is not a 9.20 material - rather 9.21-9.22 if we are lucky, as it is a big feature. Also, I foresee a similar concept eventually appearing for QUIC, too (kQUIC?). Also, I am aquiet certain that we *will* need #3504 for this (implemented here: !8576).
See also:
1. https://docs.kernel.org/networking/tls.html
2. https://man.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html
3. https://delthas.fr/blog/2023/kernel-tls/ - mostly discusses it in the context of HTTP and `sendfile()` acceleration, but contains many references on the topic.
4. https://docs.nvidia.com/networking/display/ofedv512580/kernel+transport+layer+security+(ktls)+offloadsLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4503Possible pytest RNDC interface improvements2023-12-21T18:03:30ZŠtěpán BalážikPossible pytest RNDC interface improvementsReview of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
...Review of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
- [ ] Find a way to the the `*.in` files templating in pure Python. This is needed for the elimination of the `setup.sh` scripts. This will probably require depending on `jinja` explicitly.
- [ ] Add an "rndc null" before every reconfiguration to show which file is used (NamedInstance.add_mark_to_log() as it may be generically useful?)
- [ ] Extend `NamedInstance` with some kind of `query` method. This is needed as a replacement for the calls to `dig` which are common in system tests.
- [ ] There are now two objects representing the ports used in tests: dictionary returned by the `ports` fixture and the new `NamedPorts` class. Unify them. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411674).
- [ ] Consider switch from `NamedTuple` to `dataclass` (Python 3.7 feature, requires a external dependency on some distros we run) as discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411004).
- [ ] `NamedInstance.rndc(…)` method probably ought to be `async`. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411007)
Feel free to add others!Long-termŠtěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4502Missing reference?2024-02-24T07:53:00ZMark AndrewsMissing reference?Job [#3894124](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3894124) failed for c56a0ce25353ac1d4a8226d72373e3d7fb4c4c10:
```
2023-12-21 02:40:08 INFO:catz I:catz_tmp_8975m3uv:ns4 crashed on shutdown
2023-12-21 02:40:08 ERROR:cat...Job [#3894124](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3894124) failed for c56a0ce25353ac1d4a8226d72373e3d7fb4c4c10:
```
2023-12-21 02:40:08 INFO:catz I:catz_tmp_8975m3uv:ns4 crashed on shutdown
2023-12-21 02:40:08 ERROR:catz Failed to stop servers
2023-12-21 02:40:08 INFO:catz I:catz_tmp_8975m3uv:Core dump(s) found: /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121
2023-12-21 02:40:08 INFO:catz D:catz_tmp_8975m3uv:backtrace from /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121:
2023-12-21 02:40:08 INFO:catz D:catz_tmp_8975m3uv:--------------------------------------------------------------------------------
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D catz_tmp_8975m3uv-ns4 -m'.
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:Program terminated with signal SIGABRT, Aborted.
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#0 0x00007ff5cd7dfb8f in raise () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:[Current thread is 1 (Thread 0x7ff5b1dff700 (LWP 56142))]
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#0 0x00007ff5cd7dfb8f in raise () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#1 0x00007ff5cd7b2ea5 in abort () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#2 0x0000000000422b8a in assertion_failed (file=0x7ff5d17eda82 "view.c", line=427, type=isc_assertiontype_insist, cond=0x7ff5d17c47c0 "__v > 0 && __v < (4294967295U)") at main.c:234
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#3 0x00007ff5d1c35f9d in isc_assertion_failed (file=file@entry=0x7ff5d17eda82 "view.c", line=line@entry=427, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7ff5d17c47c0 "__v > 0 && __v < (4294967295U)") at assertions.c:48
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#4 0x00007ff5d176d241 in dns_view_attach (source=source@entry=0x7ff5ca3c0c00, targetp=targetp@entry=0x7ff5afa051f8) at view.c:429
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#5 0x000000000042b579 in catz_run (entry=0x7ff5b803f0c0, origin=origin@entry=0x7ff5ca20c540, view=0x7ff5ca3c0c00, udata=0x680608 <ns_catz_cbdata>, type=type@entry=CATZ_DELZONE) at server.c:2957
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#6 0x000000000042b5d2 in catz_delzone (entry=<optimized out>, origin=origin@entry=0x7ff5ca20c540, view=<optimized out>, udata=<optimized out>) at server.c:2973
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#7 0x00007ff5d1644645 in dns__catz_zones_merge (catz=0x7ff5ca20c540, newcatz=0x7ff5afa17000) at catz.c:696
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#8 0x00007ff5d1647be0 in dns__catz_update_cb (data=<optimized out>) at catz.c:2481
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#9 0x00007ff5d1c6316a in isc__work_cb (req=<optimized out>) at work.c:30
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#10 0x00007ff5cf6244ee in worker () from /lib64/libuv.so.1
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#11 0x00007ff5ce4f71da in start_thread () from /lib64/libpthread.so.0
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#12 0x00007ff5cd7cae73 in clone () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:catz_tmp_8975m3uv:--------------------------------------------------------------------------------
2023-12-21 02:40:09 INFO:catz D:catz_tmp_8975m3uv:full backtrace from /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121 saved in /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121-backtrace.txt
2023-12-21 02:40:10 INFO:catz D:catz_tmp_8975m3uv:core dump /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121 archived as /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121.gz
2023-12-21 02:40:11 INFO:catz I:catz_tmp_8975m3uv:1 assertion failure(s) found
2023-12-21 02:40:11 ERROR:catz Found core dumps or sanitizer reports
2023-12-21 02:40:11 INFO:catz test artifacts in: catz_sh_catz
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4489dnssec-guide should mention use of validate-except2023-12-13T12:29:01ZStacey Marshalldnssec-guide should mention use of validate-except### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentione...### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentioned in the DNSSEC guide (bind9/doc/dnssec-guide) within the ARM.
### Request
Within DNSSEC guide where `dnssec-validation` is discussed for troubleshooting, add some information about the use of `validate-except { string; }` with some examples.
Suggest too that dnssec-validation](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-dnssec-validation) statement also mention `validate-except`. Yes I see [validate-except](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-validate-except) is immediately below it, but without the dotted line it may not be seen.
### Links / references
https://lists.isc.org/pipermail/bind-users/2023-December/108172.htmlhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4485Update httppicoparser2023-12-13T16:43:09ZOndřej SurýUpdate httppicoparserThis sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78This sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4475Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove2024-02-24T07:54:00ZMichal NowakData races in isc_buffer_peekuint8, rdataset_settrust, and memmoveJob [#3848477](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848477) failed for c4fcdbefc5ac65e62f8d16ba78737aa6174c9592.
There are three new types of TSAN errors in the failed `respdiff-long:tsan` CI job.
I did not happen [yesterd...Job [#3848477](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848477) failed for c4fcdbefc5ac65e62f8d16ba78737aa6174c9592.
There are three new types of TSAN errors in the failed `respdiff-long:tsan` CI job.
I did not happen [yesterday](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3843810) on 64ef6968f379fa220c2a2d76311705b4e248e286, so should this be caused by a new code, the only theoretically relevant MR is !8515.
```
WARNING: ThreadSanitizer: data race
Read of size 1 at 0x000000000001 by main thread:
#0 isc_buffer_peekuint8 ../../lib/isc/include/isc/buffer.h:847
#1 isc_buffer_getuint8 ../../lib/isc/include/isc/buffer.h:854
#2 dns_ncache_getsigrdataset lib/dns/ncache.c:630
#3 validate_ncache lib/dns/validator.c:2388
#4 validate_nx lib/dns/validator.c:2431
#5 validator_start lib/dns/validator.c:2994
#6 isc__async_cb lib/isc/async.c:111
#7 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#8 thread_body lib/isc/thread.c:85
#9 isc_thread_main lib/isc/thread.c:116
#10 isc_loopmgr_run lib/isc/loop.c:454
#11 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000001 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1015 at 0x000000000020 allocated by main thread:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 isc_thread_main lib/isc/thread.c:116
#16 isc_loopmgr_run lib/isc/loop.c:454
#17 main bin/named/main.c:1574
Thread T0001 'isc-loop-0002' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race ../../lib/isc/include/isc/buffer.h:847 in isc_buffer_peekuint8
```
```
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by main thread:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 isc_thread_main lib/isc/thread.c:116
#9 isc_loopmgr_run lib/isc/loop.c:454
#10 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000001 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1015 at 0x000000000014 allocated by thread T0002:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 thread_run lib/isc/thread.c:100
Thread T0001 'isc-loop-0001' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
Thread T0002 'isc-loop-0002' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race lib/dns/ncache.c:499 in rdataset_settrust
```
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by main thread:
#0 memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810
#1 memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:808
#2 memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:36
#3 dns_name_fromregion lib/dns/name.c:739
#4 dns_ncache_current lib/dns/ncache.c:701
#5 validate_ncache lib/dns/validator.c:2382
#6 validate_nx lib/dns/validator.c:2431
#7 validator_start lib/dns/validator.c:2994
#8 isc__async_cb lib/isc/async.c:111
#9 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#10 thread_body lib/isc/thread.c:85
#11 isc_thread_main lib/isc/thread.c:116
#12 isc_loopmgr_run lib/isc/loop.c:454
#13 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000014 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:200
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1047 at 0x000000000021 allocated by thread T0001:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 thread_run lib/isc/thread.c:100
Thread T0001 'isc-loop-0001' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race /usr/include/x86_64-linux-gnu/bits/string_fortified.h:36 in memmove
```
I restarted the job, and this is a [reproducible issue](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3849392).May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4470ns_interfacemgr_t listenon queue set incorrectly2024-03-28T08:28:47Zliu chaofengns_interfacemgr_t listenon queue set incorrectly<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential!
-->
### Summary
ns_interfacemgr_t listenon queue set incorrectly
### BIND version used
master branch
### Steps to reproduce
1. config named.conf like below
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
2. then start the named process
3. run "netstat -lpn|grep named" found the 53 and 10053 has already listened.
4. the ns_interfacemgr_t has a listenon queue
struct ns_interfacemgr {
...
ISC_LIST(isc_sockaddr_t) listenon;
....
}
5. I dump the listenon queue, found that there is only 127.0.0.1#53,
127.0.0.1#10053 is not in the listenon queue.
### What is the current *bug* behavior?
I think this behavior maybe a bug,
### What is the expected *correct* behavior?
the listenon should contain 127.0.0.1#53 and 127.0.0.1#10053
### Relevant configuration files
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/4469Follow-up from "Resolve "Crash on shutdown when DNSSEC validation is running:...2024-02-24T07:53:03ZMark AndrewsFollow-up from "Resolve "Crash on shutdown when DNSSEC validation is running: ENSURE(isc_mempool_getallocated(*namepoolp) == 0) failed""The following discussion from !8526 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8526#note_420948): (+1 comment)
> Now the hard question: Was this caused by ...The following discussion from !8526 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8526#note_420948): (+1 comment)
> Now the hard question: Was this caused by some recent change in the mempool usage? @ondrej?
>
> If so, can we have, say, a Cocinelle check for the correct order of operations? Chasing down these shutdown issues one by one is nightmare and consumes QA time, so if we can have an automated check I'm all for it.
>
> If an automated check is not feasible please could you manually check places affected by (presumed) recent changes to see if there are other place with similar bugs?
>
> Thank you!May 2024 (9.18.27, 9.18.27-S1, 9.19.24)