ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-07-01T14:40:17Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/725Add a component for editing DHCP option data2022-07-01T14:40:17ZMarcin SiodelskiAdd a component for editing DHCP option dataWe need to add a component that allows for editing option data (e.g. belonging to host reservations). The same component will be later used for subnet-level options etc.
This ticket follows the #720 that enables creating new host reserv...We need to add a component that allows for editing option data (e.g. belonging to host reservations). The same component will be later used for subnet-level options etc.
This ticket follows the #720 that enables creating new host reservations. The host reservations can be currently added without option data.1.5Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2387Create ddns-tuning.dox file for ddns-tuning hook library2022-04-25T16:59:05ZThomas MarkwalderCreate ddns-tuning.dox file for ddns-tuning hook libraryThe developer's doc for ddsn-tuning was overlooked. It's absence causes distcheck to fail. Adding a stub for now.The developer's doc for ddsn-tuning was overlooked. It's absence causes distcheck to fail. Adding a stub for now.kea2.1.5https://gitlab.isc.org/isc-projects/kea/-/issues/2386Documentation building error duplicate label hooks-ddns-tuning2022-04-25T12:56:43ZMarcin GodzinaDocumentation building error duplicate label hooks-ddns-tuningQuick fix to repair duplicate warning in documentation buildingQuick fix to repair duplicate warning in documentation buildingkea2.1.5Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/2385bump up lib versions for 2.1.52022-04-25T13:18:59ZRazvan Becheriubump up lib versions for 2.1.5kea2.1.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2384ddns-tuning should preparse subnet host expressions so expression errors are ...2022-05-09T13:37:37ZThomas Markwalderddns-tuning should preparse subnet host expressions so expression errors are caught prior to client traffic submissionThis ticket addresses a ddns-tuning hook library review comment
https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/262#note_281640
This entails adding callbacks dhcpX_srv_configured and cbX_updated, during which the cache...This ticket addresses a ddns-tuning hook library review comment
https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/262#note_281640
This entails adding callbacks dhcpX_srv_configured and cbX_updated, during which the cache would be flushed and subnet expressions would be parsed and cached if parsing succeds, or logged if not. I believe this also eliminates the needs to for using time stamp of last flush to detect updated subnets, since all changes would be handled in the above callbacks.kea2.1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3296Check the algorithm name / oid for PRIVATEDNS and PRIVATEOID signatures.2022-05-16T10:34:23ZMark AndrewsCheck the algorithm name / oid for PRIVATEDNS and PRIVATEOID signatures.The fromwire and fromtext methods need to check that there are well formed algorithm names / oids in SIG and RRSIG records for algorithms 253 and 254 respectively. These checks are the same as have already been applied to KEY, DNSKEY et...The fromwire and fromtext methods need to check that there are well formed algorithm names / oids in SIG and RRSIG records for algorithms 253 and 254 respectively. These checks are the same as have already been applied to KEY, DNSKEY etc.
```
A.1.1. Private Algorithm Types
Algorithm number 253 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with a wire encoded
domain name, which MUST NOT be compressed. The domain name indicates
the private algorithm to use, and the remainder of the public key
area is determined by that algorithm. Entities should only use
domain names they control to designate their private algorithms.
Algorithm number 254 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with an unsigned
length byte followed by a BER encoded Object Identifier (ISO OID) of
that length. The OID indicates the private algorithm in use, and the
remainder of the area is whatever is required by that algorithm.
Entities should only use OIDs they control to designate their private
algorithms.
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/kea/-/issues/2382installation premium hook instruction in ARM refer to subscription hook list2022-04-22T19:19:19ZWlodzimierz Wencelinstallation premium hook instruction in ARM refer to subscription hook listMinor thing in:
https://kea.readthedocs.io/en/kea-2.1.4/arm/hooks.html#installing-hook-packages
point 5 of the list:
```
5. Rerun configure, using the same configuration options that were used when originally building Kea. It is possibl...Minor thing in:
https://kea.readthedocs.io/en/kea-2.1.4/arm/hooks.html#installing-hook-packages
point 5 of the list:
```
5. Rerun configure, using the same configuration options that were used when originally building Kea. It is possible to verify that configure has detected the premium package by inspecting the summary printed when it exits. The first section of the output should look something like this:
Package:
Name: kea
Version: 2.1.4
Extended version: 2.1.4 (tarball)
OS Family: Linux
Using GNU sed: yes
Premium package: yes
Included Hooks: forensic_log flex_id host_cmds subnet_cmds radius host_cache class_cmds cb_cmds lease_query
```
included hooks list if from subscribes package, may lead to questions like "I bought hooks and according to docs I should have more".kea2.1.5Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2381race conditions found in kea-dhcp4 MT when perfdhcp packets contain DHO_HOST_...2022-05-20T12:57:01ZThomas Markwalderrace conditions found in kea-dhcp4 MT when perfdhcp packets contain DHO_HOST_NAMETSAN reported two different race conditions while I was testing #1548 in MT mode in kea-dhcp4 with a version of perfdhcp that I hacked to send the DHO_HOST_OPTION in client packets. I have verified that these both exist in master withou...TSAN reported two different race conditions while I was testing #1548 in MT mode in kea-dhcp4 with a version of perfdhcp that I hacked to send the DHO_HOST_OPTION in client packets. I have verified that these both exist in master without #1548 (i.e. they have been in the code for quite some time).
The first one is in std::regex() which is called from util::StringSanitzerImpl(). I isloted this enough to be pretty convinced this is in the std::regex implementation (at least under Ubuntu 20.04. I alternated between a local static mutex and a class member mutex in StringSanitizerImpl (see hack_mutex.diff). When hack_mutex_ is a local static the race is avoided, when it is a a member of StringSantizierImpl() the race occurs. I believe this means that the memory in contention resides within std::regex itself. If one undefines USE_REGEX so the code uses regcomp, the race does not occur at all.
The second on is in isc::cryptolink::CryptoLink::initialize(), which is being called when creating the D2Dhcid for NameChangeRequests. I added a mutex and lock to CryptoLink which makes the race condition go away, see crypto.diff. It isn't pretty maybe but it's demonstrative.
These haven't shown up before because most of tests don't send host name (or FQDN) options in client packets. I imagine we would have probably see these same conditions if perfdhcp sent FQDN options in v4 or v6 as well.
I have attached the tsan report, my server config, config.*, and the perfdhcp hack diff.
[kea-dhcp4.log](/uploads/b36f81cb15b9d3b2d6a7da086c64dd5c/kea-dhcp4.log)
[tsan.conf](/uploads/d847830c0a9258eeb640c6e18f096ed0/tsan.conf)
[perfdhcp_dho_host.diff](/uploads/767d437c2c41cd1ce9db4c6804bfa2b9/perfdhcp_dho_host.diff)
[config.log](/uploads/cb8ed4ea767cb11081078485bd115ce7/config.log)
[config.report](/uploads/23954a9b3bddbf19bde934bc05dd7467/config.report)
[hack_mutex.diff](/uploads/bc4fc1b39adcd125c9487b958119b9ae/hack_mutex.diff)
[crypto.diff](/uploads/1d9fdf8f33806734ba4dcf146d45be9d/crypto.diff)kea2.1.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2379Have the CI check for missing files in src/share/api2022-07-01T15:44:24ZFrancis DupontHave the CI check for missing files in src/share/apiFind a way to detect missing command describing files in src/share/api and add it to Continuous Integration.Find a way to detect missing command describing files in src/share/api and add it to Continuous Integration.kea2.2.0 - a new stable branchAndrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2377Unit tests fail when build/test box has an eth1 interface2022-04-19T19:37:58ZDan TheisenUnit tests fail when build/test box has an eth1 interfaceIt seems that some unit tests expect that the build box does not have an `eth1` interface. My build box happened to have an `eth1` interface, and running into this was slightly confusing. Unit tests that expect an interface to NOT exist ...It seems that some unit tests expect that the build box does not have an `eth1` interface. My build box happened to have an `eth1` interface, and running into this was slightly confusing. Unit tests that expect an interface to NOT exist should probably use non-default interface names.
Relevant output:
```
[ RUN ] CfgSubnets4Test.iface
cfg_subnets4_unittest.cc:1777: Failure
Expected: parser.parse(elems) throws an exception of type DhcpConfigError.
Actual: it throws nothing.
[ FAILED ] CfgSubnets4Test.iface (0 ms)
[ RUN ] SharedNetwork4ParserTest.iface
shared_network_parser_unittest.cc:472: Failure
Expected: parser.parse(config_element) throws an exception of type DhcpConfigError.
Actual: it throws nothing.
[ FAILED ] SharedNetwork4ParserTest.iface (0 ms)
[ RUN ] SharedNetwork4ParserTest.iface
shared_network_parser_unittest.cc:472: Failure
Expected: parser.parse(config_element) throws an exception of type DhcpConfigError.
Actual: it throws nothing.
[ FAILED ] SharedNetwork4ParserTest.iface (0 ms)
[ RUN ] SharedNetwork6ParserTest.iface
shared_network_parser_unittest.cc:1007: Failure
Expected: parser.parse(config_element) throws an exception of type DhcpConfigError.
Actual: it throws nothing.
[ FAILED ] SharedNetwork6ParserTest.iface (0 ms)
[ FAILED ] 4 tests, listed below:
[ FAILED ] CfgSubnets4Test.iface
[ FAILED ] CfgSubnets6Test.iface
[ FAILED ] SharedNetwork4ParserTest.iface
[ FAILED ] SharedNetwork6ParserTest.iface
```kea2.1.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/stork/-/issues/722Stork server/agent log setting.2022-05-30T17:49:10ZSina HosseiniStork server/agent log setting.Hello, I have some troubles with the Stork server & agent logging mechanism.
There is just no way to configure how these two handle their logs, by default they send their logs to `/var/log/syslog` but the problem is on top of not being ...Hello, I have some troubles with the Stork server & agent logging mechanism.
There is just no way to configure how these two handle their logs, by default they send their logs to `/var/log/syslog` but the problem is on top of not being able to disable it, there are ANSI color codes in the log messages ( which I have no idea how they're getting logged in the first place ) and that is causing issues for my log management.
Sample:
```bash
#011/tmp/build/tools/1.17.5/go/src/runtime/asm_amd64.s:1581
#033[31mERRO#033[0m[2022-04-03 14:00:31] periodicexecutor.go:169 errors were encountered while pulling data from apps: missing Arguments from Lease Stats response {ResponseHeader:{Result:2 Text:'stat-lease6-get' command not supported. Daemon:dhcp6} Arguments:<nil>}
#033[36mINFO#033[0m[2022-04-03 14:00:31] statspuller.go:69 completed pulling lease stats from Kea apps: 0/1 succeeded
```
I found out that these logs are correctly formatted when using the `journalctl` command, however, the ANSI color codes exist in the `/var/log/syslog` and since my log management is gathering all logs through `syslog` the ANSI color codes are proving problematic.
Please address this issue, any help regarding how to drop these codes, fix them, or any workaround is appreciated.
Many thanks in advance.1.4Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3253Remove privileged task mode2022-04-01T23:01:48ZOndřej SurýRemove privileged task modeThe task privileged mode has been used only when the named was starting up and loading the zones from the disk as the "first" thing to do. The privileged task was setup with quantum == 2, which made the taskmgr/netmgr spin around the pri...The task privileged mode has been used only when the named was starting up and loading the zones from the disk as the "first" thing to do. The privileged task was setup with quantum == 2, which made the taskmgr/netmgr spin around the privileged queue processing two events at the time.
The same effect can be achieved by setting the quantum to UINT_MAX (e.g. practically unlimited) for the loadzone task, hence the privileged task mode was removed in favor of just processing all the events on the loadzone task in a single task_run().April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/2375Remove Cassandra from hammer2022-04-01T17:05:38ZFrancis DupontRemove Cassandra from hammerFollowup of #2116Followup of #2116kea2.1.5Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3245Increasing quantum for zone loading tasks has steep negative effect on perfor...2022-04-04T19:23:47ZOndřej SurýIncreasing quantum for zone loading tasks has steep negative effect on performanceCurrently, the loadtask has quantum of `2` which makes the whole world spin - it goes to netmgr, runs 2 events, schedules the task to be run again on netmgr, runs 2 events, ...
Bumping the number of quantum to higher number (`UINT_MAX` ...Currently, the loadtask has quantum of `2` which makes the whole world spin - it goes to netmgr, runs 2 events, schedules the task to be run again on netmgr, runs 2 events, ...
Bumping the number of quantum to higher number (`UINT_MAX` or `2000`) has a severe effect on the zone loading - each event takes more and more time:
```
31-Mar-2022 16:10:16.447 zone dom108240.example/IN: loaded serial 2016010101
processed event 0x7f46583e57b0 in 769us
31-Mar-2022 16:10:16.447 zone dom108241.example/IN: loaded serial 2016010101
processed event 0x7f46583e5820 in 750us
31-Mar-2022 16:10:16.447 zone dom108242.example/IN: loaded serial 2016010101
processed event 0x7f46583e5890 in 761us
31-Mar-2022 16:10:16.447 zone dom108243.example/IN: loaded serial 2016010101
processed event 0x7f46583e5900 in 761us
31-Mar-2022 16:10:16.447 zone dom108244.example/IN: loaded serial 2016010101
processed event 0x7f46583e5970 in 777us
31-Mar-2022 16:10:16.451 zone dom108245.example/IN: loaded serial 2016010101
processed event 0x7f46583e59e0 in 829us
31-Mar-2022 16:10:16.451 zone dom108246.example/IN: loaded serial 2016010101
processed event 0x7f46583e5a50 in 748us
31-Mar-2022 16:10:16.451 zone dom108247.example/IN: loaded serial 2016010101
processed event 0x7f46583e5ac0 in 761us
31-Mar-2022 16:10:16.451 zone dom108248.example/IN: loaded serial 2016010101
processed event 0x7f46583e5b30 in 762us
31-Mar-2022 16:10:16.451 zone dom108249.example/IN: loaded serial 2016010101
processed event 0x7f46583e5ba0 in 759us
31-Mar-2022 16:10:16.455 zone dom108250.example/IN: loaded serial 2016010101
processed event 0x7f46583e5c10 in 766us
31-Mar-2022 16:10:16.455 zone dom108251.example/IN: loaded serial 2016010101
processed event 0x7f46583e5c80 in 752us
31-Mar-2022 16:10:16.455 zone dom108252.example/IN: loaded serial 2016010101
processed event 0x7f46583e5cf0 in 751us
31-Mar-2022 16:10:16.455 zone dom108253.example/IN: loaded serial 2016010101
processed event 0x7f46583e5d60 in 762us
31-Mar-2022 16:10:16.455 zone dom108254.example/IN: loaded serial 2016010101
processed event 0x7f46583e5dd0 in 760us
31-Mar-2022 16:10:16.459 zone dom108255.example/IN: loaded serial 2016010101
processed event 0x7f46583e5e40 in 802us
31-Mar-2022 16:10:16.459 zone dom108256.example/IN: loaded serial 2016010101
processed event 0x7f46583e5eb0 in 749us
31-Mar-2022 16:10:16.459 zone dom108257.example/IN: loaded serial 2016010101
processed event 0x7f46583e5f20 in 764us
31-Mar-2022 16:10:16.459 zone dom108258.example/IN: loaded serial 2016010101
processed event 0x7f46583e5f90 in 760us
31-Mar-2022 16:10:16.459 zone dom108259.example/IN: loaded serial 2016010101
processed event 0x7f46583e8000 in 762us
31-Mar-2022 16:10:16.463 zone dom108260.example/IN: loaded serial 2016010101
processed event 0x7f46583e8070 in 792us
31-Mar-2022 16:10:16.463 zone dom108261.example/IN: loaded serial 2016010101
processed event 0x7f46583e80e0 in 730us
31-Mar-2022 16:10:16.463 zone dom108262.example/IN: loaded serial 2016010101
processed event 0x7f46583e8150 in 762us
31-Mar-2022 16:10:16.463 zone dom108263.example/IN: loaded serial 2016010101
processed event 0x7f46583e81c0 in 762us
31-Mar-2022 16:10:16.463 zone dom108264.example/IN: loaded serial 2016010101
processed event 0x7f46583e8230 in 1016us
```
Reducing the `quantum` to `1` (which is minimum results in):
```
31-Mar-2022 16:11:32.087 zone dom000030.example/IN: loaded serial 2016010101
processed event 0x7f69b349d9d0 in 55us
processed 1 events in 57us
31-Mar-2022 16:11:32.087 zone dom000031.example/IN: loaded serial 2016010101
processed event 0x7f69b349da40 in 55us
processed 1 events in 56us
31-Mar-2022 16:11:32.087 zone dom000032.example/IN: loaded serial 2016010101
processed event 0x7f69b349dab0 in 54us
processed 1 events in 56us
31-Mar-2022 16:11:32.087 zone dom000033.example/IN: loaded serial 2016010101
processed event 0x7f69b349db20 in 55us
processed 1 events in 56us
31-Mar-2022 16:11:32.087 zone dom000034.example/IN: loaded serial 2016010101
processed event 0x7f69b349db90 in 55us
processed 1 events in 56us
31-Mar-2022 16:11:32.087 zone dom000035.example/IN: loaded serial 2016010101
processed event 0x7f69b349dc00 in 55us
processed 1 events in 56us
```
What is interesting is that during the privileged task runs, other (non-privileged?) task starts leaking into the run:
```
31-Mar-2022 16:15:26.831 zone dom009279.example/IN: loaded serial 2016010101
processed event 0x7f189b657840 in 55us
processed 1 events in 57us
processed event 0x7f1743200770 in 1us
processed event 0x7f17432007e0 in 0us
processed event 0x7f1743200850 in 0us
processed event 0x7f17432008c0 in 0us
processed event 0x7f1743200930 in 0us
processed event 0x7f17432009a0 in 0us
processed event 0x7f1743200a10 in 0us
processed event 0x7f1743200a80 in 0us
processed event 0x7f1743200b60 in 0us
processed event 0x7f1743200bd0 in 0us
processed event 0x7f1743200c40 in 0us
processed event 0x7f1743200cb0 in 0us
processed event 0x7f1743200d20 in 0us
processed event 0x7f1743200d90 in 0us
processed event 0x7f1743200e00 in 0us
processed event 0x7f1743200e70 in 0us
processed event 0x7f1743200ee0 in 0us
processed event 0x7f1743200f50 in 0us
processed event 0x7f1743200fc0 in 0us
processed event 0x7f1743201030 in 0us
processed event 0x7f17432010a0 in 0us
processed event 0x7f1743201110 in 0us
processed event 0x7f1743201180 in 0us
processed event 0x7f17432011f0 in 0us
processed event 0x7f1743201260 in 0us
processed event 0x7f17432012d0 in 0us
processed event 0x7f1743201340 in 0us
processed event 0x7f17432013b0 in 0us
processed event 0x7f1743201420 in 0us
processed event 0x7f1743201490 in 0us
processed event 0x7f1743201500 in 0us
processed event 0x7f1743201570 in 0us
processed event 0x7f17432015e0 in 0us
processed event 0x7f1743201650 in 0us
processed event 0x7f17432016c0 in 0us
processed event 0x7f1743201730 in 0us
processed event 0x7f17432017a0 in 0us
processed event 0x7f1743201810 in 0us
processed event 0x7f1743201880 in 0us
processed event 0x7f17432018f0 in 0us
processed event 0x7f1743201960 in 0us
processed event 0x7f17432019d0 in 0us
processed event 0x7f1743201a40 in 0us
processed event 0x7f1743201ab0 in 0us
processed event 0x7f1743201b20 in 0us
processed event 0x7f1743201b90 in 0us
processed event 0x7f1743201c00 in 0us
processed event 0x7f1743201c70 in 0us
processed event 0x7f1743201ce0 in 0us
processed event 0x7f1743201d50 in 0us
processed event 0x7f1743201dc0 in 0us
processed event 0x7f1743201e30 in 0us
processed event 0x7f1743201ea0 in 0us
processed event 0x7f1743201f10 in 0us
processed event 0x7f1743201f80 in 0us
processed event 0x7f1743201ff0 in 0us
processed event 0x7f1743202060 in 0us
processed event 0x7f17432020d0 in 0us
processed event 0x7f1743202140 in 0us
processed event 0x7f17432021b0 in 0us
processed event 0x7f1743202220 in 0us
processed event 0x7f1743202290 in 0us
processed event 0x7f1743202300 in 0us
processed event 0x7f1743202370 in 0us
processed 64 events in 135us
31-Mar-2022 16:15:26.835 zone dom009280.example/IN: loaded serial 2016010101
processed event 0x7f189b6578b0 in 58us
processed 1 events in 59us
31-Mar-2022 16:15:26.835 zone dom009281.example/IN: loaded serial 2016010101
processed event 0x7f189b657920 in 87us
processed 1 events in 89us
```April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/2372Remove benchmarks - Determine what to do with benchmarks2022-04-20T19:38:05ZTomek MrugalskiRemove benchmarks - Determine what to do with benchmarksLet's discuss this between @razvan, @wlodek and @andrei. Here's my observations:
- have not been run in years
- no easy way to translate to real life parameters (like leases/sec, queries/sec etc)
- have different license (apache), which...Let's discuss this between @razvan, @wlodek and @andrei. Here's my observations:
- have not been run in years
- no easy way to translate to real life parameters (like leases/sec, queries/sec etc)
- have different license (apache), which is confusing
- haven't been updated in years. For sure they don't cover DB features that's been added in recent years
- the alternative (performance tests) have gone a very long way, are very thorough and cover many real life scenarios that resonate with customer problems
Given all of the above, we should consider removing them, unless we find a good way forward how to use them effectively.kea2.1.5Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2371update kea version in configure.ac2022-03-30T12:51:59ZWlodzimierz Wencelupdate kea version in configure.ackea2.1.5https://gitlab.isc.org/isc-projects/stork/-/issues/721systemd unit (service) files do not enable automatic restart on failure2022-05-05T11:09:14ZKevin Flemingsystemd unit (service) files do not enable automatic restart on failure**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms? YES
- Stork is in very early stages of development. If your request is not simple, it
may be a while until anyone does any...**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms? YES
- Stork is in very early stages of development. If your request is not simple, it
may be a while until anyone does anything with your request. Are you ok with that? YES
**Is your feature request related to a problem? Please describe.**
If the server or agent are unable to start normally (for example, due to failures in DNS resolution, or inability to reach other nodes), no restart will be attempted.
**Describe the solution you'd like**
The normal systemd automatic restart mechanism should be allowed to restart the service a limited number of times so that a temporary failure can be automatically repaired.
**Describe alternatives you've considered**
I'm not aware of any practical alternatives; the only option today is for the administrator to manually start the service.
**Participating in development**
I would be happy to send an MR with the relevant (small) changes, if someone from the team (@tomek @vicky @ondrej @slawek) will grant me permission to fork the repository.1.3Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3238dns_adb: the overmem cleaning is ineffective2022-12-02T12:09:13ZOndřej Surýdns_adb: the overmem cleaning is ineffectiveThe overmem cleaning process is only looking at the objects present in the current bucket - which is either nothing or very few items if the hashing is doing its thing.
I think we need to slap doubly-linked list on top of the name and e...The overmem cleaning process is only looking at the objects present in the current bucket - which is either nothing or very few items if the hashing is doing its thing.
I think we need to slap doubly-linked list on top of the name and entry buckets as LRU and clean the global oldest entries.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3234Check the OID in PRIVATEOID keys2022-04-26T10:18:15ZMark AndrewsCheck the OID in PRIVATEOID keysPRIVATEOID keys (algorithm 254) are supposed to have a valid OID at the start of the key data. Check that this is well formed. This is a prerequisite to printing out the OID with `dig +rrcomments` similarly to how the algorithm name in ...PRIVATEOID keys (algorithm 254) are supposed to have a valid OID at the start of the key data. Check that this is well formed. This is a prerequisite to printing out the OID with `dig +rrcomments` similarly to how the algorithm name in printed out for PRIVATEDNS.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/kea/-/issues/2364Changes for Kea 2.1.4 release2022-03-28T11:14:09ZWlodzimierz WencelChanges for Kea 2.1.4 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.1.4Wlodzimierz WencelWlodzimierz Wencel