ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-11-16T02:27:40Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4355Potential cache poisoning due to unexpected recursion instead of following de...2023-11-16T02:27:40ZCathy AlmondPotential cache poisoning due to unexpected recursion instead of following delegation when serve-stale is enabled### Summary
As reported in [Support ticket #22830](https://support.isc.org/Ticket/Display.html?id=22830)
The server is authoritative for some zones as well as supporting recursion for others. Some zones delegate subdomains to other na...### Summary
As reported in [Support ticket #22830](https://support.isc.org/Ticket/Display.html?id=22830)
The server is authoritative for some zones as well as supporting recursion for others. Some zones delegate subdomains to other nameservers. For those, the NS RRset in the delegation is unreachable/unresolvable.
With `stale-answer-enable no;` the expected SERVFAIL is returned to the clients querying for names in these subdomains.
With `stale-answer-enable yes;` the resolver appears not to follow the delegation but instead attempts resolution directly from the root nameservers instead, sometimes providing different answers to the client that those intended by the configuration and delegation (albeit broken).
### BIND version used
```
BIND 9.16.43-Ubuntu (Extended Support Version) <id:de6f1a0>
running on Linux x86_64 5.15.0-1041-aws #46~20.04.1-Ubuntu SMP Wed Jul 19 15:40:00 UTC 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--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' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--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' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-FMDtLY/bind9-9.16.43=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
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
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
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
Pasting here from the report to Support team:
Locally setup in-addr.arpa for private /16 network: 59.10.in-addr.arpa
with delegation for /24:
```
$ORIGIN 59.10.in-addr.arpa.
1 NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
As these NSs are fake, we can't contact them ever and without serve-stale enabled - we always receive SERVFAIL.
**But, as soon as serve-stale is enabled, named will start to try to run recursion from the root**, and we start getting NXDOMAIN (what is cacheable answer)
```
# dig 1.59.10.in-addr.arpa @127.0.0.1
; <<>> DiG 9.16.43-Ubuntu <<>> 1.59.10.in-addr.arpa @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21068
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c6da2a29e4d47c6a01000000651554607e40e4b8c2a75c00 (good)
;; QUESTION SECTION:
;1.59.10.in-addr.arpa. IN A
;; AUTHORITY SECTION:
10.in-addr.arpa. 10800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800
;; Query time: 156 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 10:24:32 UTC 2023
;; MSG SIZE rcvd: 172
```
The same thing with direct zones.
For example:
- Test zone: myctl.com
- Test record: test.myctl.com (on the external NSs it returns 127.0.0.1)
Delegation in the local zone file:
```
$ORIGIN myctl.com.
test NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
Without serve-stale enabled, I always have SERVFAIL answer.
With serve-stale enabled, I have SERVFAL twice, then recursion started from the root, and I will have answer from the external nameservers not specified in the localzone file:
```
# dig test.myctl.com. @127.0.0.1
; <<>> DiG 9.16.43-Ubuntu <<>> test.myctl.com. @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29218
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 42aa29742ab548b00100000065155561f82a157e5a4464ae (good)
;; QUESTION SECTION:
;test.myctl.com. IN A
;; Query time: 60 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 10:28:49 UTC 2023
;; MSG SIZE rcvd: 71
```
```
# dig test.myctl.com. @127.0.0.1
; <<>> DiG 9.16.43-Ubuntu <<>> test.myctl.com. @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42780
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c14a6db123fa69bc010000006515556372206781ce6b989d (good)
;; QUESTION SECTION:
;test.myctl.com. IN A
;; ANSWER SECTION:
test.myctl.com. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
test.myctl.com. 3600 IN NS nss2.example.net.
test.myctl.com. 3600 IN NS nss1.example.net.
test.myctl.com. 3600 IN NS nss3.example.net.
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 10:28:51 UTC 2023
;; MSG SIZE rcvd: 155
```
### What is the current *bug* behavior?
Unexpected recursion from root down (ignoring the delegation from the local auth parent zones) by the resolver when stale-answer-enable is 'yes'
### What is the expected *correct* behavior?
Consistent SERVFAIL (by following the delegation NS RRset and being unable to resolve the delegated nameserver names in the parent zone).
### Relevant configuration files
Relevant snippets from named.conf (for the full configuration, see the Support ticket):
```
options {
directory "/var/cache/bind";
listen-on-v6 {
"none";
};
dnssec-validation no;
minimal-responses no;
qname-minimization off;
stale-answer-enable yes;
stale-answer-client-timeout 1800;
stale-cache-enable yes;
stale-refresh-time 30;
masterfile-format text;
};
zone "59.10.in-addr.arpa" in {
type master;
file "zones/59.10.rev";
forwarders {
};
};
zone "myctl.com" in {
type master;
file "zones/myctl.com";
forwarders {
};
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
```
```
# cat /var/cache/bind/zones/myctl.com
$ORIGIN .
$TTL 3600 ; 1 hour
myctl.com IN SOA dc1.example.net. corporate.example.net. (
428210 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)
NS ns1.myctl.com.
NS ns2.myctl.com.
ns1.myctl.com. IN A 127.0.0.1
ns2.myctl.com. IN A 127.0.0.1
$ORIGIN myctl.com.
test NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
```
# cat /var/cache/bind/zones/59.10.rev
$ORIGIN .
$TTL 3600 ; 1 hour
59.10.in-addr.arpa IN SOA dc1.example.net. corporate.example.net. (
428210 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)
NS ns1.example.net.
NS ns2.example.net.
$ORIGIN 59.10.in-addr.arpa.
1 NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
Notably, this server IS authoritative for the parent zones but delegates to an NS RRset that it's not authoritative for and where the names can't be resolved to anything useful.
Therefore the resolver should be attempting to use the delegation NS RRset for these internal-only zones and delegations from them, and not attempting resolution from the root down (but it *DOES* nevertheless attempt that with `stale-answer-enable yes;`
### Why this is potentially a security defect:
Quoting the reporter:
We expect that internal customers will get some internal IPs in answers, or didn’t get anything if something wrong (like broken internal NSs) or get answers from the cache when the NSs configured in the zone file are not available but answers already in the cache. But not external IPs or unexpected answers.
Lets assume something goes wrong with our internal NSs (nss[1-3].example.net, like in example above), and everyone inside the company get some sort of external IP (or loopback IP) for some requested record (like in example above). Let it be “supernewfeature.myctl.com” (this is only for example), and everyone inside the company start to run some sort of queries against that record with answer pointed to unexpected place, then service might be overload/unexpected responses replied/anything else.
When the serve-stale is disabled - everyone will get SERVFAIL, and external services will not be impacted.
Also I see this as a way of potential attack, when in the external nameservers place some sort of victim IP address what can cause to DDoS or pointing to some sort of fishing website.
That's why I evaluate that issue as security issue.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/1178Build pipeline for LDAP hook2023-10-09T15:23:58ZSlawek FigielBuild pipeline for LDAP hook1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4354Checking zone transfer information in the statistics channel fails on OpenBSD2023-10-12T09:37:12ZMichal NowakChecking zone transfer information in the statistics channel fails on OpenBSDJob [\#3693319](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3693319) failed for 23b52fb6a04e49f079942bb23ad4a5f0fb13e8da.
There's a permanent test failure in the `statschannel` system test on OpenBSD on `main` after e92d1eeafca6e5a...Job [\#3693319](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3693319) failed for 23b52fb6a04e49f079942bb23ad4a5f0fb13e8da.
There's a permanent test failure in the `statschannel` system test on OpenBSD on `main` after e92d1eeafca6e5a75299bff6a90ce37848409e85 got merged, specifically the `Checking zone transfer information in the statistics channel` check (that worked before the change) and the `Checking zone transfer transports` check (that was added in the change).
```plaintext
2023-10-03 00:23:55 INFO:statschannel I:statschannel_tmp_2s8p6u20:Checking zone transfer information in the statistics channel (25)
2023-10-03 00:23:55 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using xml
2023-10-03 00:23:56 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using json
...
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using xml
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using json
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:failed
```
```plaintext
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:Checking zone transfer transports (26)
2023-10-03 00:25:28 INFO:statschannel cmp: EOF on xfrins.example.format26
2023-10-03 00:25:28 INFO:statschannel cmp: EOF on xfrins.example-tcp.format26
2023-10-03 00:25:28 INFO:statschannel cmp: EOF on xfrins.example-tls.format26
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:failed
```
[xfrins.xml.x25](/uploads/fb7a275e22d23fbe33fa5f158cafd91d/xfrins.xml.x25)
[xfrins.json.j26](/uploads/9e3c39332724d734cd6cb96fcfca3555/xfrins.json.j26)
[xfrins.json.j25](/uploads/b0f3f858e762257000fe4293140b890e/xfrins.json.j25)November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/stork/-/issues/1176Subnet, network, host and possibly other tabs are not shown2023-10-05T14:58:41ZMarcin SiodelskiSubnet, network, host and possibly other tabs are not shownI speculate that this is a regression after the most recent Primeng/Angular upgrade.
Open a tab with a list of subnets. Click on one of the subnets. The subnet contents are shown and the tab with the list of subnets is unselected, but t...I speculate that this is a regression after the most recent Primeng/Angular upgrade.
Open a tab with a list of subnets. Click on one of the subnets. The subnet contents are shown and the tab with the list of subnets is unselected, but the tab for the subnet is not visible. In other words, you always have only one (default) tab and no way to navigate between different tabs.
In the following picture you can see what happens after clicking on a subnet. The subnet contents are displayed but there is only one tab.
![Zrzut_ekranu_2023-10-3_o_21.28.07](/uploads/3159164320680fabd343a780fd7c8a2c/Zrzut_ekranu_2023-10-3_o_21.28.07.png)1.13Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/1175No error message when I apply a different subnet with the same subnet id2023-10-04T08:58:11ZSandeep GagalapallyNo error message when I apply a different subnet with the same subnet idHi,
I was testing the premium hook command "remote-subnet4-set" to see if there is way to let the user know that there is an existing subnet-id , what happens is if I add a new subnet with the same subnet-id which I used before it gets...Hi,
I was testing the premium hook command "remote-subnet4-set" to see if there is way to let the user know that there is an existing subnet-id , what happens is if I add a new subnet with the same subnet-id which I used before it gets replaced instead of throwing an error or message in response. How can make these records unique ?
For example. If I send this command first and then lets say if another user uses the same id '2' , the config is getting replaced.
```
{
"command": "remote-subnet4-set",
"service": [
"dhcp4"
],
"arguments": {
"subnets": [
{
"id": 2,
"subnet": "192.0.2.0/24",
"shared-network-name": "",
"pools": [
{
"pool": "192.0.2.100 - 192.0.2.200",
}
]
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"all"
]
}
}
```
Thank You,
Sandeephttps://gitlab.isc.org/isc-projects/stork/-/issues/1174LDAP hook: Enable hook coverage check2024-02-01T18:05:55ZSlawek FigielLDAP hook: Enable hook coverage checkWe should check the test coverage for the LDAP hook similarly to the Stork core.We should check the test coverage for the LDAP hook similarly to the Stork core.1.15Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3095DHCPv4 option 21 policy-filter example may be misleading2023-10-20T13:42:39ZPiotrek ZadrogaDHCPv4 option 21 policy-filter example may be misleadingExample of that Option that is currently in the source code (`all-options.json`) may be misleading.
```
/*
Code Len Address 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+--...Example of that Option that is currently in the source code (`all-options.json`) may be misleading.
```
/*
Code Len Address 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Address 2 Mask 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
*/
// Type: array of {IPv4 address}
{
"code": 21,
"data": "192.0.2.21, 192.0.2.22",
"name": "policy-filter"
},
```
`data` should be rather pairs of (IPv4, mask), e.g.
```
"data": "192.0.2.0, 255.255.255.0",
```
or
```
"data": "192.0.2.0, 255.255.255.0, 10.2.0.0, 255.255.0.0",
```kea2.5.3Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/stork/-/issues/1171Install Stork packages in FIPS mode2024-01-02T19:06:51ZSlawek FigielInstall Stork packages in FIPS modeWe got a report on our [mailing list](https://lists.isc.org/pipermail/stork-users/2023-October/000190.html) that it may be impossible to install Stork packages on the RedHat 9 in FIPS mode enabled.
User's logs:
```
The error messages f...We got a report on our [mailing list](https://lists.isc.org/pipermail/stork-users/2023-October/000190.html) that it may be impossible to install Stork packages on the RedHat 9 in FIPS mode enabled.
User's logs:
```
The error messages from the install are as follows…
Error unpacking rpm package isc-stork-server-1.12.0.230802125029-1.x86_64
Error occurred during transaction.
Verifying : isc-stork-server-1.12.0.230802125029-1.x86_64
Completion plugin: generating completion cache…
Failed: isc-stork-server-1.12.0.230802125029-1.x86_64
Failed:
isc-stork-server-1.12.0.230802125029-1.x86_64
Error: Transaction failed
###
The dnf.log is showing…
DDEBUG RPM transaction start.
DDEBUG RPM transaction over.
DEBUG Errors occurred during transaction.
DDEBUG timer: verify transaction: 70 ms
DDEBUG timer: transaction: 172 ms
DEBUG Comletion plugin: Generating completion cache…
DEBUG Failed: isc-stork-server-1.12.0.230802125029-1.x86_64
DDEBUG Cleaning up.
DDEBUG Cleaning up.
DDEBUG Plugins were unloaded.
SUBDEBUG
Traceback (most recent call last):
File “/user/lib/python3.9/site-packages/dnf/cli/main.py”, line 67, in main
return _main(base, args, cli_class, option_parser_class)
File “/usr/lib/python3.9/site-package/dnf/cli/main.py”, line 106, in _main
return cli_run(clci, base)
File “/usr/lib/python3.9/site-package/dnf/cli/main.py”, line 130, in
cli_run
ret = resolving(cli, base)
File “/usr/lib/python3.9/site-package/dnf/cli/main.py”, line 176, in
resolving
base.do_transaction(display=disiplays)
File “/usr/lib/python3.9/site-package/dnf/cli/main.py”, line 264, in
do_transaction
raise dnf.exceptions.Error(_(‘Transaction failed’))
dnf.exceptions.Error: Transaction failed
CRITICAL Error: Transaction failed
###
The dnf.librepo.log is showing…
INFO --- logging initialized ---
SUBDEBUG Installed: isc-stork-server-1.12.0.230802125029-1.x86_64
ERROR ERROR unpacking rpm package
isc-stork-server-1.12.0.230802125029-1.x86_64
```
User's workaround:
```
It looks like there are two things you can do.
1. Skip the evaluation of the digest
rpm -ivh isc-stork-server-1.12.0.230802125029-1.x86_64.rpm --nofiledigest --noidgest
2. Disable, run the dnf, then re-enable FIPS
# fips-mode-setup --check
# fips-mode-setup --disable
# fips-mode-setup --check
# shutdown -r now
# dnf install isc-stork-server-1.12.0.230802125029-1.x86_64.rpm
# flips-mode-setup --enable
# fips-mode-setup --check
# shutdown -r now
You may have to reset your update-crypto-policies setting to fix and other issues after reboot.
```1.15Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4351rndc exits with error message "rndc: src/unix/core.c:580: uv__close: Assertio...2023-10-02T16:01:34ZKarl Wiemanrndc exits with error message "rndc: src/unix/core.c:580: uv__close: Assertion `fd > 2' failed." when STDIN is closed<!--
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
When the 9.18.16 version of rndc is invoked when STDIN is closed, it panics with "rndc: src/unix/core.c:580: uv__close: Assertion `fd > 2' failed.". The 9.16.37 version, and all earlier versions, do not have this behavior.
### BIND version used
BIND 9.18.16 (Extended Support Version) <id:8193c9b>
running on Linux x86_64 3.10.0-1160.95.1.el7.x86_64 #1 SMP Fri Jun 23 08:44:55 EDT 2023
built by make with '--prefix=/opt/bind-9.18.16' '--disable-doh'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384
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: /opt/bind-9.18.16/etc/named.conf
rndc configuration: /opt/bind-9.18.16/etc/rndc.conf
DNSSEC root key: /opt/bind-9.18.16/etc/bind.keys
nsupdate session key: /opt/bind-9.18.16/var/run/named/session.key
named PID file: /opt/bind-9.18.16/var/run/named/named.pid
named lock file: /opt/bind-9.18.16/var/run/named/named.lock
### Steps to reproduce
While this is an odd use case, it is critical to our disaster recovery process. rndc should not care if STDIN is open or not as it does not require it.
### Code or rndctest.c that reproduces the issue. Compile with gcc -o rndctest rndctest.c ###
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <fcntl.h>
int main(argc,argv)
int argc;
char *argv[];
{
int option;
char *logdir = (char *)NULL;
char *logfile = (char *)NULL;
int status;
int verbose = 0;
int exit_code = 0;
int ofd;
int fd;
char *rndcargs[4];
char *rarg1="/u1/kwieman/rndc"; /* Point this to the rndc binary */
char *rarg2="reload";
char *rarg3="tstcloud.blackrock.com"; /* Point this to a valid DNS zone */
close(1);
ofd = open("rndc.stdout",O_WRONLY|O_CREAT,
S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
if (ofd == -1)
exit(-2);
close(2);
fd = open("rndc.stderr",O_WRONLY|O_CREAT,
S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
if (fd == -1)
exit(-3);
close(0);
rndcargs[0] = rarg1;
rndcargs[1] = rarg2;
rndcargs[2] = rarg3;
rndcargs[3] = (char *)0;
if (execv("/u1/kwieman/rndc",rndcargs))
exit_code = 1;
exit(exit_code);
}
### What is the current *bug* behavior?
rndc reload <DNS Zone> panics when STDIN is not open.
### What is the expected *correct* behavior?
rndc should not panic.
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/stork/-/issues/1170CI: switch to auto-scaling runner2023-10-12T11:43:23ZTomek MrugalskiCI: switch to auto-scaling runnerThere are new auto-scaling runners available. @manu updated !651 to address this, but we need a ticket for it, too. At least to keep the @project_87_bot quiet...There are new auto-scaling runners available. @manu updated !651 to address this, but we need a ticket for it, too. At least to keep the @project_87_bot quiet...1.14Emanuel PetrEmanuel Petrhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4350key-directory directive appears to be ignored/lost2023-10-16T08:39:58ZPerry Lorierkey-directory directive appears to be ignored/lost### Summary
named is currently spamming my logs (several times a second) with:
```
01-Oct-2023 23:48:04.780 general: warning: dns_dnssec_findzonekeys: error reading K118.35.155.90.in-addr.arpa.+013+61902.private: file not found
```
I _...### Summary
named is currently spamming my logs (several times a second) with:
```
01-Oct-2023 23:48:04.780 general: warning: dns_dnssec_findzonekeys: error reading K118.35.155.90.in-addr.arpa.+013+61902.private: file not found
```
I _think_ this started when I upgraded to 9.19.17-1-Debian. (I only noticed after it filled up / with error logs which was several hours later)
Previously the lines looked like:
```
2023-09-17T02:39:40.407470+01:00 windy named[3479]: dns_dnssec_keylistfromrdataset: error reading /var/lib/bind/keys/K118.35.155.90.in-addr.arpa.+008+45120.private: file not found
```
And instead of it doing it for this one zone, it's now doing it for _all_ zones (including ones that have valid keys in that directory).
Stracing named, shows it's attempting to:
```
[pid 2091764] openat(AT_FDCWD, "K118.35.155.90.in-addr.arpa.+008+25456.key", O_RDONLY) = -1 ENOENT (No such file or directory)
```
which is the wrong directory, it should be looking in `/var/lib/bind/keys/`. Playing around with gdb, `zone->keydirectory` appears to be NULL, but it _does_ seem to be attempting to set it correctly at startup. I can't find where `zone->keydirectory` becomes NULL.
### BIND version used
```
# named -V
BIND 9.19.17-1-Debian (Development Release) <id:>
running on Linux x86_64 6.4.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-1 (2023-07-23)
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' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.19.17=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-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.11 19 Sep 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with liburcu version: 0.14.0
compiled with jemalloc version: 5.3.0
compiled with libnghttp2 version: 1.56.0
linked to libnghttp2 version: 1.56.0
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
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.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): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
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
It appears running this config shows it attempting to load keys from the wrong directory.
### What is the current *bug* behavior?
bind attempts to load keys from it's current working directory.
### What is the expected *correct* behavior?
bind attempts to load keys from the directory specified in `key-directory`
### Relevant configuration files
I use the `key-directory` within the options block, I've tried adding it to the zone blocks too but that doesn't seem to help.
```
acl "recursive" {
127.0.0.0/8;
90.155.35.112/28;
213.49.232.21/32;
192.168.0.0/16;
2001:8b0:8dd::/48;
};
dnssec-policy "lorier" {
dnskey-ttl PT1H;
keys {
csk key-directory lifetime unlimited algorithm ecdsa256;
};
max-zone-ttl P1D;
parent-ds-ttl P1D;
parent-propagation-delay PT1H;
publish-safety PT1H;
purge-keys P90D;
retire-safety PT1H;
signatures-refresh P5D;
signatures-validity P14D;
signatures-validity-dnskey P14D;
zone-propagation-delay PT5M;
};
logging {
channel "simple_logging" {
file "/var/log/named/named.log" versions 5 size 10485760;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
channel "extra_logging" {
file "/var/log/named/extra.log" versions 5 size 10485760;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"simple_logging";
};
category "unmatched" {
"extra_logging";
};
};
options {
directory "/var/cache/bind";
listen-on-v6 {
"any";
};
allow-query-cache {
"recursive";
};
allow-recursion {
"recursive";
};
auth-nxdomain no;
dnssec-validation auto;
key-directory "/var/lib/bind/keys";
};
key "certbot-key" {
algorithm "hmac-sha512";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
key "ddns-key.snow.lorier.net" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "ddns-key.heatwave.lorier.net" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
zone "lorier.net" {
type master;
file "/var/lib/bind/db.lorier.net.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "certbot-key" name "_acme-challenge.dmz.lorier.net." "txt";
grant "ddns-key.snow.lorier.net" name "snow.lorier.net." "ANY";
grant "ddns-key.heatwave.lorier.net" name "heatwave.lorier.net" "ANY";
};
allow-transfer {
64.62.231.249/32;
104.237.156.70/32;
114.23.226.193/32;
127.0.0.1/32;
131.203.119.149/32;
202.37.129.62/32;
};
also-notify {
64.62.231.249;
104.237.156.70;
114.23.226.193;
127.0.0.1;
131.203.119.149;
202.37.129.62;
};
dnssec-policy "lorier";
key-directory "/var/lib/bind/keys";
notify-source 90.155.35.114;
};
zone "_acme-challenge.lorier.net" {
type master;
file "/var/lib/bind/db._acme-challenge.lorier.net.signed";
update-policy {
grant "certbot-key" name "_acme-challenge.lorier.net." "txt";
};
dnssec-policy "lorier";
key-directory "/var/lib/bind/keys";
};
zone "int.lorier.net" {
type master;
file "/var/lib/bind/db.int.lorier.net.signed";
update-policy {
grant "local-ddns" zonesub "ANY";
};
dnssec-policy "lorier";
};
zone "112.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.112.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "113.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.113.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "114.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.114.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "115.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.115.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "116.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.116.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "117.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.117.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "118.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.118.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "119.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.119.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "120.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.120.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "121.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.121.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "122.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.122.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "123.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.123.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "124.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.124.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "125.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.125.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "126.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.126.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "127.35.155.90.in-addr.arpa" {
type master;
file "/var/lib/bind/db.127.35.155.90.in-addr.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "0.0.0.0.d.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa" {
type master;
file "/var/lib/bind/db.0.0.0.0.d.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "8.e.9.b.d.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa" {
type master;
file "/var/lib/bind/db.8.e.9.b.d.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
grant "*" tcp-self "." "PTR";
};
dnssec-policy "lorier";
};
zone "0.b.8.0.1.0.0.2.ip6.arpa" {
type master;
file "/var/lib/bind/db.0.b.8.0.1.0.0.2.ip6.arpa.signed";
update-policy {
grant "local-ddns" zonesub "any";
};
dnssec-policy "lorier";
};
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
```
### Relevant logs and/or screenshots
```
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K121.35.155.90.in-addr.arpa.+013+29194.private: file not found
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K117.35.155.90.in-addr.arpa.+013+42622.private: file not found
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K123.35.155.90.in-addr.arpa.+013+44371.private: file not found
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K113.35.155.90.in-addr.arpa.+013+39511.private: file not found
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K118.35.155.90.in-addr.arpa.+013+61902.private: file not found
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K_acme-challenge.lorier.net.+013+59310.private: file not found
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K123.35.155.90.in-addr.arpa.+013+44371.private: file not found
01-Oct-2023 23:54:02.479 general: warning: dns_dnssec_findzonekeys: error reading K121.35.155.90.in-addr.arpa.+013+29194.private: file not found
```
Note that it's writing out duplicate messages multiple times a second.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4349Document the complex defaults of inline-signing2023-11-07T09:29:45ZBjörn PerssonDocument the complex defaults of inline-signingThe reference manual needs to explain how inline-signing and dnssec-policy will interact in BIND 9.20. This patch describes how it works in the development branch, to the best of my understanding.
[0001-Document-the-complex-defaults-of-...The reference manual needs to explain how inline-signing and dnssec-policy will interact in BIND 9.20. This patch describes how it works in the development branch, to the best of my understanding.
[0001-Document-the-complex-defaults-of-inline-signing.patch](/uploads/15d6ee902fba86b2ec85ff0a54a3dc32/0001-Document-the-complex-defaults-of-inline-signing.patch)November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4347In-Views for RPZ2023-10-01T04:16:47ZMohammad AltenbakjiIn-Views for RPZI am looking for any workaround to achieve in-view support for RPZ slave zones as I am using a server which has high volume RPZ and I need to implement and share those RPZs across different views .I am looking for any workaround to achieve in-view support for RPZ slave zones as I am using a server which has high volume RPZ and I need to implement and share those RPZs across different views .https://gitlab.isc.org/isc-projects/bind9/-/issues/4343CID 465861: Null pointer dereferences (REVERSE_INULL) /lib/ns/client.c: 237...2023-10-04T13:26:28ZArаm SаrgsyаnCID 465861: Null pointer dereferences (REVERSE_INULL) /lib/ns/client.c: 2370 in ns__client_setup()Not sure why this was triggered now. The f5af981831ea8a707090c1b09a47c25b75d86b5a commit has touched this function recently, but the detected "issue" was present there before that, IIUC.
FTR, there is nothing serious - it's just an unne...Not sure why this was triggered now. The f5af981831ea8a707090c1b09a47c25b75d86b5a commit has touched this function recently, but the detected "issue" was present there before that, IIUC.
FTR, there is nothing serious - it's just an unnecessary NULL-check.
```
*** CID 465861: Null pointer dereferences (REVERSE_INULL)
/lib/ns/client.c: 2370 in ns__client_setup()
2364 }
2365
2366 if (client->message != NULL) {
2367 dns_message_detach(&client->message);
2368 }
2369
>>> CID 465861: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "client->manager" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
2370 if (client->manager != NULL) {
2371 ns_clientmgr_detach(&client->manager);
2372 }
2373
2374 return (result);
2375 }
```November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4342rndc can crash when standard file descriptors are closed2023-10-02T09:27:34ZPeter Daviesrndc can crash when standard file descriptors are closedBIND 9.18.19:
We have received a report that when run in the background, for example, from a
script, rndc can crash.
"We tracked it down to an assert coming from libuv. It turns out that the way
we were calling it didn't pass o...BIND 9.18.19:
We have received a report that when run in the background, for example, from a
script, rndc can crash.
"We tracked it down to an assert coming from libuv. It turns out that the way
we were calling it didn't pass open file descriptors for stdin or stderr. That
allowed user file descriptors to be created in that range, triggering the assert.
The fix was to make sure that we had open file descriptors for all 3, even if they
were tied to /dev/null. "
https://github.com/libuv/libuv/blob/v1.x/src/unix/core.c#L633C61-L633C61
[SF #00001290](https://isc.lightning.force.com/lightning/r/Case/5007V00002XclgJQAR/view)https://gitlab.isc.org/isc-projects/stork/-/issues/1169Wrong architecture name for 32-bit ARMv72023-11-24T14:33:30ZSlawek FigielWrong architecture name for 32-bit ARMv7Originally reported in [this comment](https://gitlab.isc.org/isc-projects/stork/-/issues/381#note_405301)
The build system should use the `armhf` name of the architecture when compiling packages for ARMv7 architecture.Originally reported in [this comment](https://gitlab.isc.org/isc-projects/stork/-/issues/381#note_405301)
The build system should use the `armhf` name of the architecture when compiling packages for ARMv7 architecture.1.14Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4341Investigate the memory spike when the cache is cold2023-12-05T15:58:56ZOndřej SurýInvestigate the memory spike when the cache is coldOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4340"max-cache-size" is a no-op since BIND 9.19.162023-11-27T13:22:48ZMichał Kępień"max-cache-size" is a no-op since BIND 9.19.16Commit 4db150437e14b28c5b50ae466af9ce502fd73185 (part of !7873)
inadvertently turned the `max-cache-size` option into a no-op by
removing the `isc_mem_setwater()` call from `dns_cache_setcachesize()`.
This was not caught in testing as t...Commit 4db150437e14b28c5b50ae466af9ce502fd73185 (part of !7873)
inadvertently turned the `max-cache-size` option into a no-op by
removing the `isc_mem_setwater()` call from `dns_cache_setcachesize()`.
This was not caught in testing as the current memory use limitation
logic employed in `named` is not stable enough for low `max-cache-size`
values (which is documented) and most tests use the implicit default of
`max-cache-size 90%;`.
Shout-out to @esesterhenn for [spotting this][1], thank you! :medal:
[1]: https://mattermost.isc.org/x41-dsec/pl/e9ja89c8at8wxpyqkjcpoukoycNovember 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/kea-docker/-/issues/29DHCP-DDNS reports to be unhealthy: unix:///run/supervisord.sock no such file2023-09-29T08:02:08ZSlawek FigielDHCP-DDNS reports to be unhealthy: unix:///run/supervisord.sock no such file`docker ps`:
```
ab4328f5038b docker.cloudsmith.io/isc/docker/kea-dhcp-ddns:2.5.2 "supervisord -c /etc…" 2 minutes ago Up 2 minutes (unhealthy) 8000/tcp, 53001/udp blissful_golick
```
`docker inspect ab4328f5038b`:
```
...`docker ps`:
```
ab4328f5038b docker.cloudsmith.io/isc/docker/kea-dhcp-ddns:2.5.2 "supervisord -c /etc…" 2 minutes ago Up 2 minutes (unhealthy) 8000/tcp, 53001/udp blissful_golick
```
`docker inspect ab4328f5038b`:
```
"Health": {
"Status": "unhealthy",
"FailingStreak": 7,
"Log": [
{
"Start": "2023-09-27T11:00:31.713049044+02:00",
"End": "2023-09-27T11:00:31.916313585+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T11:01:01.920471624+02:00",
"End": "2023-09-27T11:01:02.151545652+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T11:01:32.15958959+02:00",
"End": "2023-09-27T11:01:32.379092512+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T11:02:02.387677501+02:00",
"End": "2023-09-27T11:02:02.604991397+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T11:02:32.611539729+02:00",
"End": "2023-09-27T11:02:32.880081368+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
}
]
}
```https://gitlab.isc.org/isc-projects/kea-docker/-/issues/28DHCPv4 reports to be unhealthy: unix:///run/supervisord.sock no such file2023-09-29T08:01:59ZSlawek FigielDHCPv4 reports to be unhealthy: unix:///run/supervisord.sock no such file`docker ps`:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14c8e2b97f65 docker.cloudsmith.io/isc/docker/k...`docker ps`:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14c8e2b97f65 docker.cloudsmith.io/isc/docker/kea-dhcp4:2.5.2 "supervisord -c /etc…" 3 minutes ago Up 3 minutes (unhealthy) 67/tcp, 8000-8001/tcp, 67/udp dreamy_aryabhata
```
`docker inspect 14c8e2b97f65`:
```
"Health": {
"Status": "unhealthy",
"FailingStreak": 8,
"Log": [
{
"Start": "2023-09-27T10:53:47.623250136+02:00",
"End": "2023-09-27T10:53:47.815853441+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T10:54:17.820523313+02:00",
"End": "2023-09-27T10:54:18.055149013+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T10:54:48.059574411+02:00",
"End": "2023-09-27T10:54:48.279292809+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T10:55:18.28319628+02:00",
"End": "2023-09-27T10:55:18.496146941+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
},
{
"Start": "2023-09-27T10:55:48.50016321+02:00",
"End": "2023-09-27T10:55:48.703369609+02:00",
"ExitCode": 4,
"Output": "unix:///run/supervisord.sock no such file\n"
}
]
}
```
Container logs:
```
2023-09-27 08:51:47,038 INFO Included extra file "/etc/supervisor/conf.d/kea-agent.conf" during parsing
2023-09-27 08:51:47,038 INFO Included extra file "/etc/supervisor/conf.d/kea-dhcp4.conf" during parsing
2023-09-27 08:51:47,038 INFO Set uid to user 0 succeeded
2023-09-27 08:51:47,212 INFO RPC interface 'supervisor' initialized
2023-09-27 08:51:47,212 CRIT Server 'inet_http_server' running without any HTTP authentication checking
2023-09-27 08:51:47,212 INFO supervisord started with pid 1
2023-09-27 08:51:48,214 INFO spawned: 'kea-agent' with pid 7
2023-09-27 08:51:48,215 INFO spawned: 'kea-dhcp4' with pid 8
2023-09-27 08:51:48.224 INFO [kea-ctrl-agent.dctl/7.140137835985712] DCTL_STARTING Control-agent starting, pid: 7, version: 2.5.2 (development)
2023-09-27 08:51:48.224 WARN [kea-ctrl-agent.dctl/7.140137835985712] DCTL_DEVELOPMENT_VERSION This software is a development branch of Kea. It is not recommended for production use.
2023-09-27 08:51:48.225 WARN [kea-ctrl-agent.ctrl-agent/7.140137835985712] CTRL_AGENT_CONFIG_SYNTAX_WARNING Control Agent configuration syntax warning: /etc/kea/kea-ctrl-agent.conf:9.14: Extraneous comma. A piece of configuration may have been omitted.
2023-09-27 08:51:48.225 INFO [kea-ctrl-agent.ctrl-agent/7.140137835985712] CTRL_AGENT_HTTP_SERVICE_STARTED HTTP service bound to address 127.0.0.1:8000
2023-09-27 08:51:48.225 INFO [kea-ctrl-agent.dctl/7.140137835985712] DCTL_CONFIG_COMPLETE server has completed configuration: listening on 127.0.0.1, port 8000, control sockets: dhcp4, 0 lib(s):
2023-09-27 08:51:48.225 INFO [kea-ctrl-agent.ctrl-agent/7.140137835985712] CTRL_AGENT_STARTED Kea Control Agent version 2.5.2 started
2023-09-27 08:51:48.231 INFO [kea-dhcp4.dhcp4/8.139888193660432] DHCP4_STARTING Kea DHCPv4 server version 2.5.2 (development) starting
2023-09-27 08:51:48.231 WARN [kea-dhcp4.dhcp4/8.139888193660432] DHCP4_DEVELOPMENT_VERSION This software is a development branch of Kea. It is not recommended for production use.
2023-09-27 08:51:48.232 WARN [kea-dhcp4.dhcp4/8.139888193660432] DHCP4_CONFIG_SYNTAX_WARNING configuration syntax warning: /etc/kea/kea-dhcp4.conf:36.35: Extraneous comma. A piece of configuration may have been omitted.
2023-09-27 08:51:48.232 INFO [kea-dhcp4.hosts/8.139888193660432] HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
2023-09-27 08:51:48.232 WARN [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2023-09-27 08:51:48.232 WARN [kea-dhcp4.dhcp4/8.139888193660432] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2023-09-27 08:51:48.232 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth0
2023-09-27 08:51:48.232 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
2023-09-27 08:51:48.232 WARN [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CONFIGURED_SUBNET_WITHOUT_ID a subnet was configured without an id: 192.168.50.0/24
2023-09-27 08:51:48.232 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 192.168.50.0/24 with params: t1=1000, t2=2000, valid-lifetime=4000
2023-09-27 08:51:48.233 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2023-09-27 08:51:48.233 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth0
2023-09-27 08:51:48.233 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
2023-09-27 08:51:48.233 INFO [kea-dhcp4.commands/8.139888193660432] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /run/kea/control_socket_4
2023-09-27 08:51:48.233 INFO [kea-dhcp4.dhcp4/8.139888193660432] DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added IPv4 subnets: 1; DDNS: disabled
2023-09-27 08:51:48.234 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_MEMFILE_DB opening memory file lease database: type=memfile universe=4
2023-09-27 08:51:48.240 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv
2023-09-27 08:51:48.240 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 0 leases, extended info sanity checks modified 0 / updated 0 leases and 0 leases have relay or remote id
2023-09-27 08:51:48.240 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
2023-09-27 08:51:48.271 INFO [kea-dhcp4.dhcpsrv/8.139888193660432] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 192.168.50.0/24
2023-09-27 08:51:48.272 WARN [kea-dhcp4.dhcp4/8.139888193660432] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 16, queue size: 64
2023-09-27 08:51:48.272 INFO [kea-dhcp4.dhcp4/8.139888193660432] DHCP4_STARTED Kea DHCPv4 server version 2.5.2 started
2023-09-27 08:51:49,274 INFO success: kea-agent entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-09-27 08:51:49,274 INFO success: kea-dhcp4 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
```