ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-17T13:37:16Zhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/62Disable output of "client-classes" in global if no classes defined2024-03-17T13:37:16ZDarren AnkneyDisable output of "client-classes" in global if no classes definedThis is placed in the configuration:
```
"client-classes": [],
```
in the global area when there are no classes defined. Stop that. It doesn't cause any problems, but it doesn't need to be there.This is placed in the configuration:
```
"client-classes": [],
```
in the global area when there are no classes defined. Stop that. It doesn't cause any problems, but it doesn't need to be there.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4642[dig] +ednsflags do not enable EDNS2024-03-17T03:16:43ZStéphane Bortzmeyer[dig] +ednsflags do not enable EDNS### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by mak...### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by make with default
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with liburcu version: 0.13.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
```
### Steps to reproduce
```
dig +noedns +ednsflags=0x4000 isc.org SOA
``
### What is the current *bug* behavior?
EDNS is still disabled
### What is the expected *correct* behavior?
+ednsflags should enable EDNS, like +nsid or +dnssec do. (Or may be only if the value is not-zero.)
/label ~Bughttps://gitlab.isc.org/isc-projects/bind9/-/issues/4641dig +ednsflags does not re-enable EDNS2024-03-17T03:12:44ZMark Andrewsdig +ednsflags does not re-enable EDNS+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the same+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the sameApril 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4637host, dig and nslookup don't resolve IDN domains when not used in a tty2024-03-16T06:49:38ZDirk Stöckerhost, dig and nslookup don't resolve IDN domains when not used in a tty### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve t...### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve the domain.
See also my initial bug report to perl (https://github.com/Perl/perl5/issues/22080) which points to the exact code location for this bug.
### BIND version affected
I'm using bind-utils-9.18.24-1.1.x86_64 on openSUSE Tumbleweed. Same happens on older version (Ubuntu LTS).
### Steps to reproduce
See description above
1. Call `host stöcker.eu |cat` in Linux shell
### What is the current *bug* behavior?
Does not resolve a correct name
### What is the expected *correct* behavior?
Does resolve the name whether it's a tty or not.
### Relevant configuration files
none
### Relevant logs
noneNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/653dig output should not display IDNs unless explicitly requested2024-03-16T06:48:48ZRay Bellisdig output should not display IDNs unless explicitly requestedThe 9.13 behaviour when linked with libidn appears to be a change from earlier versions, where dig will now automagically convert punycode labels into unicode, but worse, fail to do so and terminate with an error if the conversion cannot...The 9.13 behaviour when linked with libidn appears to be a change from earlier versions, where dig will now automagically convert punycode labels into unicode, but worse, fail to do so and terminate with an error if the conversion cannot be done in the current locale.
(as noted by Vixie on the DNS Operations list on 2018/10/31).
I think the default should be to _not_ do this unless the +idnout option is passed.https://gitlab.isc.org/isc-projects/kea/-/issues/3291stat-lease4-get does not return leases statistics correctly2024-03-15T10:00:43ZJohn Papstat-lease4-get does not return leases statistics correctly**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server'...**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server's CLI using curl. Although there are active leases for clients the Web UI displays 0 for assigned IPs on all subnets. Probably a bug in the stat-lease4-get API command.
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea server 2.0.2, Stork 1.15.0 and run them with the following configs: '...'
2. Configure several subnets.
2. Have 3 VMs act as clients on all subnets and get ip addresses from kea server
3. Clients get IP address but the Stork GUI shows 0 for all lease statistics.
**Expected behavior**
Stork GUI should display the leases statistics for the connected clients.
**Environment:**
- Kea version: 2.0.2
- Stork: 1.15.0
- OS: Ubuntu 22.04 x64
- Kea: Hooks libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Additional Information**
Querying the DHCP agent from the stork server using the cli and the management API I figured out that the stat-lease4-get command without arguments returns different results for the same subnet than the stat-lease4-get command having the subnet-id as an argument.
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"]}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 47, 56, 0, 0, 0 ], [ 51, 56, 0, 0, 0 ], [ 66, 41, 0, 0, 0 ] ], "timestamp": "2024-03-08 14:09:09.100431" } }, "result": 0, "text": "stat-lease4-get[all subnets]: 3 rows found" } ]
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"], "arguments": {"subnet-id" : 66}}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 66, 41, 0, 3, 0 ] ], "timestamp": "2024-03-08 14:09:17.884123" } }, "result": 0, "text": "stat-lease4-get[subnet-id=66]: 1 rows found" } ]
The second output above has the correct leases stats for subnet-id 66 while the first output shows 0 leases for subnet-id 66https://gitlab.isc.org/isc-projects/bind9/-/issues/4639Add OpenSSL Flags to proxystream_test2024-03-14T23:42:27ZSamuel ChiangAdd OpenSSL Flags to proxystream_testproxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch pr...proxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch provided below :smile:
```
diff --git a/tests/isc/Makefile.am b/tests/isc/Makefile.am
index 5cdd915..6ee1935 100644
--- a/tests/isc/Makefile.am
+++ b/tests/isc/Makefile.am
@@ -115,10 +115,12 @@ proxyheader_test_SOURCES = \
proxyheader_test_data.h
proxystream_test_CPPFLAGS = \
- $(AM_CPPFLAGS)
+ $(AM_CPPFLAGS) \
+ $(OPENSSL_CFLAGS)
proxystream_test_LDADD = \
- $(LDADD)
+ $(LDADD) \
+ $(OPENSSL_LIBS)
proxystream_test_SOURCES = \
proxystream_test.c \
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4614Fix memory consumption in qp (Follow-up from "create QPDB zone database")2024-03-14T18:06:55ZMatthijs Mekkingmatthijs@isc.orgFix memory consumption in qp (Follow-up from "create QPDB zone database")The following discussion from !8543 should be addressed:
- [x] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8543#note_438118): (+1 comment)
> I gave it a quick look and sanity check - ...The following discussion from !8543 should be addressed:
- [x] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8543#note_438118): (+1 comment)
> I gave it a quick look and sanity check - loaded `net.` TLD into this version (configured as secondary - [named.conf](/uploads/d55553c50824d4c519123d18d743225f/named.conf)).
>
> Here's a quick summary:
>
> | metric | main | qpdb-heavy | 4411-qpdb-lite |
> |---------------------------------------------|---------|------------|----------------|
> | zone load time | 4:20 | 1:30 | 1:38 |
> | memory RSS | 6.2 GiB | 12.8 GiB | 12.8 GiB |
> | repeated bla.net. A query [QPS] | 155 k | 160 k | 152 k |
> | repeated bla.net. A query [CPU utilization] | 400 % | 300 % | 320 % |
> | random delegations [QPS] | 150 k | 150 k | 148 k |
> | random delegations [CPU utilization] | 470 % | 370 % | 410 % |
>
> TL;DR smaller CPU usage while doubling amount of memory.
>
> Statistics channel output after just loading the zone (no queries yet):
> - [main.json](/uploads/b0e43a7f25acb60fad379fee27577f06/main.json)
> - [heavy.json](/uploads/42baadb5c3dba87142ef36552c71d725/heavy.json)
> - [lite.json](/uploads/7bc0516d2565aba18692cc9bf0bd50b1/lite.json)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4629CID 487882: Error handling issues in lib/dns/qpzone.c2024-03-14T14:12:59ZMichal NowakCID 487882: Error handling issues in lib/dns/qpzone.cCoverity Scan claims we should consider checking the return value of `dns_qpiter_next()` in `lib/dns/qpzone.c` as done elsewhere:
```c
/lib/dns/qpzone.c: 2804 in activeempty()
2798 * of the name we were searching for. Step the iter...Coverity Scan claims we should consider checking the return value of `dns_qpiter_next()` in `lib/dns/qpzone.c` as done elsewhere:
```c
/lib/dns/qpzone.c: 2804 in activeempty()
2798 * of the name we were searching for. Step the iterator
2799 * forward, then step() will continue forward until it
2800 * finds a node with active data. If that node is a
2801 * subdomain of the one we were looking for, then we're
2802 * at an active empty nonterminal node.
2803 */
>>> CID 487882: Error handling issues (CHECKED_RETURN)
>>> Calling "dns_qpiter_next" without checking return value (as is done elsewhere 26 out of 27 times).
2804 dns_qpiter_next(it, NULL, NULL, NULL);
2805 return (step(search, it, FORWARD, next) &&
2806 dns_name_issubdomain(next, current));
2807 }
2808
2809 static bool
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/1326Stork does not display leases statistics2024-03-14T14:07:08ZJohn PapStork does not display leases statistics**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server'...**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server's CLI using curl. Although there are active leases for clients the Web UI displays 0 for assigned IPs on all subnets. Probably a bug in the stat-lease4-get API command.
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea server 2.0.2, Stork 1.15.0 and run them with the following configs: '...'
2. Configure several subnets.
2. Have 3 VMs act as clients on all subnets and get ip addresses from kea server
3. Clients get IP address but the Stork GUI shows 0 for all lease statistics.
**Expected behavior**
Stork GUI should display the leases statistics for the connected clients.
**Environment:**
- Kea version: 2.0.2
- Stork: 1.15.0
- OS: Ubuntu 22.04 x64
- Kea: Hooks libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Additional Information**
Querying the DHCP agent from the stork server using the cli and the management API I figured out that the stat-lease4-get command without arguments returns different results for the same subnet than the stat-lease4-get command having the subnet-id as an argument.
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"]}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 47, 56, 0, 0, 0 ], [ 51, 56, 0, 0, 0 ], [ 66, 41, 0, 0, 0 ] ], "timestamp": "2024-03-08 14:09:09.100431" } }, "result": 0, "text": "stat-lease4-get[all subnets]: 3 rows found" } ]
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"], "arguments": {"subnet-id" : 66}}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 66, 41, 0, 3, 0 ] ], "timestamp": "2024-03-08 14:09:17.884123" } }, "result": 0, "text": "stat-lease4-get[subnet-id=66]: 1 rows found" } ]
The second output above has the correct leases stats for subnet-id 66 while the first output shows 0 leases for subnet-id 66https://gitlab.isc.org/isc-projects/bind9/-/issues/1132HTTPS and SVCB records2024-03-14T12:58:04ZMark AndrewsHTTPS and SVCB recordsSubject to change. Defined in draft-ietf-dnsop-svcb-https (now published as RFC 9460). Experimental type codes of HTTPS/65482 and SVBC/65481Subject to change. Defined in draft-ietf-dnsop-svcb-https (now published as RFC 9460). Experimental type codes of HTTPS/65482 and SVBC/65481September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4624Invalid durations in configuration files do not cause a syntax error2024-03-14T12:54:59ZMatthijs Mekkingmatthijs@isc.orgInvalid durations in configuration files do not cause a syntax errorFor example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.For example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4631CID 487884: Dead code in lib/dns/qpcache.c2024-03-14T11:50:20ZMichal NowakCID 487884: Dead code in lib/dns/qpcache.cCoverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->...Coverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->next = newheader;
3457 qpnode->dirty = 1;
3458 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3459 changed->dirty = true;
3460 }
3461 } else {
3462 /*
3463 * No rdatasets of the given type exist at the node.
3464 */
```
```c
/lib/dns/qpcache.c: 3409 in add()
3403 }
3404 newheader->next = topheader->next;
3405 newheader->down = topheader;
3406 topheader->next = newheader;
3407 qpnode->dirty = 1;
3408 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3409 changed->dirty = true;
3410 }
3411 mark_ancient(header);
3412 if (sigheader != NULL) {
3413 mark_ancient(sigheader);
3414 }
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4608Ensure static stub NS records are not returned2024-03-14T04:33:38ZMark AndrewsEnsure static stub NS records are not returnedstatic-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com ...static-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com NS (TTL is 600)
- wait 120 seconds
- query for foo.com A (TTL is 600)
- wait 500 seconds
- query for foo.com A
```
; <<>> DiG 9.19.20-dev <<>> foo.com -p 5555
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18858
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: dddb220761d487fa0100000065dec10ee6a221e99d9baa11 (good)
;; QUESTION SECTION:
;foo.com. IN A
;; ANSWER SECTION:
foo.com. 100 IN A 34.206.39.153
;; AUTHORITY SECTION:
com. 86400 IN NS com.
;; Query time: 2 msec
;; SERVER: ::1#5555(::1) (UDP)
;; WHEN: Wed Feb 28 16:13:50 AEDT 2024
;; MSG SIZE rcvd: 94
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4630CID 487883: Null pointer dereference in lib/dns/qpzone.c2024-03-14T00:31:50ZMichal NowakCID 487883: Null pointer dereference in lib/dns/qpzone.cCoverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferre...Coverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferred until closeversion() is called.
4933 */
4934 if (result == ISC_R_SUCCESS && version == NULL) {
>>> CID 487883: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "version" to "setsecure", which dereferences it.
4935 setsecure(db, version, qpdb->origin);
4936 }
4937
4938 return (result);
4939 }
4940
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/832"dnssec-keyfromlabel: fatal: failed to get key example.com/RSASHA256: no PKCS...2024-03-13T13:55:36ZCathy Almond"dnssec-keyfromlabel: fatal: failed to get key example.com/RSASHA256: no PKCS#11 provider" could be more helpfulIn the circumstances when it was encountered, the error emitted above when dnssec-keyfromlabel terminated with a fatal error was not helpful for troubleshooting the problem.
What it actually meant (in this instance) was that the syntax ...In the circumstances when it was encountered, the error emitted above when dnssec-keyfromlabel terminated with a fatal error was not helpful for troubleshooting the problem.
What it actually meant (in this instance) was that the syntax of the options provided to the native pkcs11 library was at fault, therefore the library call failed. It didn't mean that the library was inaccessible (although it wasn't possible to access the HSM because of this error).
Since the syntax is defined in the ARM:
```
Keywords include "token", which identifies the HSM; "object", which
identifies the key; and "pin-source", which identifies a file from
which the HSM's PIN code can be obtained. The label will be
stored in the on-disk "private" file.
```
Perhaps it would have been more useful to parse what was provided and emit a more helpful error if it was not acceptable - or even not to parse but to suggest that the library rejected what it was given - it wasn't that there was no library available (which is what it looks like from the words being used).
(From Support ticket [#14117](https://support.isc.org/Ticket/Display.html?id=14117) )Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1837[ISC-support #14369] Considering changing ECS caching strategy or negative data2024-03-13T13:17:48ZBrian Conry[ISC-support #14369] Considering changing ECS caching strategy or negative dataCurrently our ECS implementation caches all negative responses at the global scope.
A customer has requested that we store them at the learned scope.
RFC 7871 (Informational only) section 7.4, paragraph 4 notes that the original spec w...Currently our ECS implementation caches all negative responses at the global scope.
A customer has requested that we store them at the learned scope.
RFC 7871 (Informational only) section 7.4, paragraph 4 notes that the original spec was ambiguous and hints that the interpretation of scoping negative answers is more likely to be used in future protocol specifications (if any) than caching them globally.
> This issue is expected to be revisited in a future revision of the protocol, possibly blessing the mixing of positive and negative answers. There are implications for cache data structures that developers should consider when writing new ECS code.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/753Request for ECS-like feature or extension to ECS2024-03-13T13:07:04ZBrian ConryRequest for ECS-like feature or extension to ECSOne of our support customers' product development team are investigating extending the functionality of their customer (presumably opt-in premium) content filtering service.
Currently the service works at the DNS layer by filtering that...One of our support customers' product development team are investigating extending the functionality of their customer (presumably opt-in premium) content filtering service.
Currently the service works at the DNS layer by filtering that's aware of both the query source IP (public IP of the account) and the originally requested name.
The desired feature is to allow for different content filtering to be applied to different devices within the customer's home, i.e. on the other side of the NAT gateway.
This service provider has the ability to control the DNS proxying software on the SP-provided CPE, which in standard topologies will be able to identify individual devices based on their MAC address or LAN IP. Non-standard topologies where this is not possible are not a concern at this time.
BIND would not have to originate any of the device-identifying data, but it would have to be able to pass it along - though only to a specific set of servers for privacy reasons - and maintain a usable cache from the returned responses.https://gitlab.isc.org/isc-projects/bind9/-/issues/4038"tcp:checking that BIND 9 doesn't crash on long TCP messages" gets named oom-...2024-03-13T12:53:25ZMichal Nowak"tcp:checking that BIND 9 doesn't crash on long TCP messages" gets named oom-killed### Summary
TCP test consumes excessive amounts of memory, which is not accounted for in memory statistics.
### BIND version used
* ~"Affects v9.19": 1b0e7e7a50733366dfae39de93f85f2293b725ff
* ~"Affects v9.18": ff3d25a47f9f969669b2e4f...### Summary
TCP test consumes excessive amounts of memory, which is not accounted for in memory statistics.
### BIND version used
* ~"Affects v9.19": 1b0e7e7a50733366dfae39de93f85f2293b725ff
* ~"Affects v9.18": ff3d25a47f9f969669b2e4f5cde10c50f9cdd171
Versions tested but NOT affected:
* ~"v9.16": adb71afffec615f63fb79306ae429fa55a6d5fd7
### Steps to reproduce
* Run test step "tcp:checking that BIND 9 doesn't crash on long TCP messages" in a loop. Essentially:
```
for I in $(seq 1 10); do perl ../packet.pl -a "127.0.0.1" -p "53" -t tcp -r 300000 1996-alloc_dnsbuf-crash-test.pkt; sleep 5; done
```
Source:
https://gitlab.isc.org/isc-projects/bind9/-/blob/1b0e7e7a50733366dfae39de93f85f2293b725ff/bin/tests/system/tcp/tests.sh#L197
### What is the current *bug* behavior?
Kernel shows excessive memory consumption and at the same time memory statistics in BIND do not show it. Apparently it is really consumed by something because sometimes OOM killer comes to the rescue.
Job [#3348347](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3348347) failed for 0f25d62a408c75820e6db585950b121fd1ffdb70.
```
I:tcp:checking that BIND 9 doesn't crash on long TCP messages (10)
I:tcp:sending 300000 time(s): 00010000000100000000000003697363036f72670000fc0001
I:tcp:failed
I:tcp:exit status: 1
I:tcp:stopping servers
I:tcp:ns1 died before a SIGTERM was sent
I:tcp:ns1 didn't die when sent a SIGTERM
I:tcp:stopping servers failed
R:tcp:FAIL
```
After a local investigation, this is a likely case of running out of memory. This is what I get locally:
```
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-3.scope,task=lt-named,pid=68053,uid=1000
Out of memory: Killed process 68053 (lt-named) total-vm:6015604kB, anon-rss:3451292kB, file-rss:5652kB, shmem-rss:0kB, UID:1000 pgtables:10744kB oom_score_adj:0
```
~~We should bump VM's memory to more than [4G](https://gitlab.isc.org/isc-projects/gitlab-runner-scripts/-/blob/main/libvirt-qemu/domain-template.xml#L8), or rather don't run this particular test on QCOW2 images.~~September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/kea/-/issues/3190heap-use-after-free and invalid vptr on Mgrs after IOThreadPool IOService/oth...2024-03-13T12:10:37ZAndrei Pavelandrei@isc.orgheap-use-after-free and invalid vptr on Mgrs after IOThreadPool IOService/other-non-main-thread IOservice distructionReplication steps:
1. Start `kea-dhcp4` built with address sanitizer and UB sanitizer with this configuration:
```plaintext
{
"Dhcp4": {
"hooks-libraries": [
{
"library": "/opt/kea/lib/kea/hooks/li...Replication steps:
1. Start `kea-dhcp4` built with address sanitizer and UB sanitizer with this configuration:
```plaintext
{
"Dhcp4": {
"hooks-libraries": [
{
"library": "/opt/kea/lib/kea/hooks/libdhcp_ping_check.so",
"parameters": {
}
}
]
}
}
```
2. `kill -SIGINT $(pidof kea-dhcp4)` or `clrl-C` in the terminal.
3a. If Kea is built with code prior to merging of issue 3019, then you should observe this warning: https://gitlab.isc.org/isc-projects/kea/-/issues/3190#note_423820
3b. If Kea is built after merging of issue 3019, then you might observe a different warning:
```plaintext
INFO PING_CHECK_MGR_STOPPED channel operations have stopped
/usr/include/boost/asio/basic_deadline_timer.hpp:351:41: runtime error: member call on address 0x60b000015ac0 which does not point to an object of type 'boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime>>'
0x60b000015ac0: note: object has invalid vptr
00 00 00 00 00 0d 00 00 00 00 00 00 a8 6d b5 51 38 7f 00 00 00 00 00 00 00 00 00 00 10 5e 05 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/include/boost/asio/basic_deadline_timer.hpp:351:41 in
/usr/include/boost/asio/detail/io_object_impl.hpp:97:15: runtime error: member call on address 0x60b000015ac0 which does not point to an object of type 'boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime>>'
0x60b000015ac0: note: object has invalid vptr
00 00 00 00 00 0d 00 00 00 00 00 00 a8 6d b5 51 38 7f 00 00 00 00 00 00 00 00 00 00 10 5e 05 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/include/boost/asio/detail/io_object_impl.hpp:97:15 in
/usr/include/boost/asio/detail/deadline_timer_service.hpp:100:5: runtime error: member call on address 0x60b000015ac0 which does not point to an object of type 'boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime>>'
0x60b000015ac0: note: object has invalid vptr
00 00 00 00 00 0d 00 00 00 00 00 00 a8 6d b5 51 38 7f 00 00 00 00 00 00 00 00 00 00 10 5e 05 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/include/boost/asio/detail/deadline_timer_service.hpp:100:5 in
INFO PING_CHECK_UNLOAD Ping Check hooks library has been unloaded
```kea2.5.7Razvan BecheriuRazvan Becheriu