ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-09-14T15:43:09Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/401Add STAG to the new public BIND docker image2021-09-14T15:43:09ZVicky Riskvicky@isc.orgAdd STAG to the new public BIND docker imageWe are trying to create a BIND docker image that will be useful both to meet <ISC customer> requirements and possibly, as a public Docker image. Ondrej has published an experimental BIND docker image here: https://hub.docker.com/orgs/int...We are trying to create a BIND docker image that will be useful both to meet <ISC customer> requirements and possibly, as a public Docker image. Ondrej has published an experimental BIND docker image here: https://hub.docker.com/orgs/internetsystemsconsortium/repositories and he asked me to ask if someone on the Stork team could add the STAG agent for BIND to the Docker.
I assume this also includes making sure that the bind image also supports any pre-conditions for the STAG to work. I can give anyone who is working on this access permissions to the ISC Docker repo.backlogMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/377RPZ qname triggers are always searched even if can be skipped2024-03-27T13:41:20ZCathy AlmondRPZ qname triggers are always searched even if can be skippedNot sure if this is a bug or not - but noticed by a customer who reported:
```
I happen to notice a minor possible glitch in RPZ query handling.
When loading an RPZ, the corresponding bit for 'rpzs->have.qname' is
always set as the exis...Not sure if this is a bug or not - but noticed by a customer who reported:
```
I happen to notice a minor possible glitch in RPZ query handling.
When loading an RPZ, the corresponding bit for 'rpzs->have.qname' is
always set as the existence of the origin name is regarded as the
existence of a QNAME trigger for the root name (.). So the following
check in rpz_rewrite_name() is pointless unless 'allowed_zbits' clears
some of the bits in case of "qname-wait-recurse yes":
zbits = rpz_get_zbits(client, qtype, rpz_type);
zbits &= allowed_zbits;
if (zbits == 0)
return (ISC_R_SUCCESS);
Since the root name is never subject to RPZ rewrite, we could actually
optimize it a bit by not setting have.qname for the RPZ's origin
name. This may be a minor optimization, though, since
dns_rpz_find_name() should be relatively cheap, and I guess it's quite
unlikely that we use RPZs that don't have any QNAME triggers. So you
may or may not want to "fix" it.
I primarily checked it for 9.11.3-S2, but I believe it's the same for all recent versions including 9.10.x.
```https://gitlab.isc.org/isc-projects/stork/-/issues/406add raising new events2022-11-16T11:54:51ZMichal Nowikowskiadd raising new events- [x] monitoring enabled/disabled
- [x] kea config change detected
- [ ] ha status change
- [ ] cross threshold of pool utilization
- [x] Kea reconfiguration (config-set)
maybe some more- [x] monitoring enabled/disabled
- [x] kea config change detected
- [ ] ha status change
- [ ] cross threshold of pool utilization
- [x] Kea reconfiguration (config-set)
maybe some morebackloghttps://gitlab.isc.org/isc-projects/stork/-/issues/407automate combining ChangeLog into release notes2021-03-02T18:22:51ZMichal Nowikowskiautomate combining ChangeLog into release notesoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/382Propagate lease updates between HA peers2022-11-02T15:08:41ZMarcin SiodelskiPropagate lease updates between HA peersHigh Availability setup includes at least two servers paired to provide reliable service. We have the lease_cmds hooks library which is utilized by the HA hooks library to send lease updates between the peers. Sometimes, though, an admin...High Availability setup includes at least two servers paired to provide reliable service. We have the lease_cmds hooks library which is utilized by the HA hooks library to send lease updates between the peers. Sometimes, though, an administrator may want to update lease information via the control channel, e.g. remove stale lease. Currently, he'd need to send appropriate command to all HA peers that (potentially) share the lease information. It is useful to be able to send the command to only one of the HA peers and let it propagate it down to other servers. For that, the HA peer would need to somehow identify that the command has been sent by the administrator rather than the HA peer, otherwise it would trigger circular updates.
The details how to implement it are TBD.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/383Add CA support to netconf.2022-11-02T15:22:00ZFrancis DupontAdd CA support to netconf.Finish the model and write translators.
More urgent that the similar ticket for D2 because it gives for free a test for kea-netconf over HTTP.Finish the model and write translators.
More urgent that the similar ticket for D2 because it gives for free a test for kea-netconf over HTTP.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/410stork should not use colors in logs if it is running as a service without ter...2022-02-04T09:07:57ZMichal Nowikowskistork should not use colors in logs if it is running as a service without termnalCurrently people copy/paste logs with ANSI escape codes for colors.
This should not happen.
```
Sep 21 14:46:22 bind_server stork-agent: #033[33mWARN#033[0m[2020-09-21 14:46:22] bind9.go:284 cannot parse BIND 9 statistics-c...Currently people copy/paste logs with ANSI escape codes for colors.
This should not happen.
```
Sep 21 14:46:22 bind_server stork-agent: #033[33mWARN#033[0m[2020-09-21 14:46:22] bind9.go:284 cannot parse BIND 9 statistics-channels clause
Sep 21 14:46:32 bind_server stork-agent: #033[33mWARN#033[0m[2020-09-21 14:46:32] bind9.go:91 cannot parse BIND 9 inet configuration: no match (controls {
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/384Add D2 support to netconf.2022-11-02T15:22:26ZFrancis DupontAdd D2 support to netconf.Finish the model and write translators.Finish the model and write translators.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/414Partner down in Kea HA is reported awkwardly2022-11-16T11:54:51ZTomek MrugalskiPartner down in Kea HA is reported awkwardlyHere's what I did:
1. started demo as usual `rake docker_up`
1. added agent-kea-ha1, agent-kea-ha2
1. used traffic generator to stop kea-dhcp4 on agent-kea-ha2
1. After a while this was shown in the dashboard:
![stork-partner-down](/up...Here's what I did:
1. started demo as usual `rake docker_up`
1. added agent-kea-ha1, agent-kea-ha2
1. used traffic generator to stop kea-dhcp4 on agent-kea-ha2
1. After a while this was shown in the dashboard:
![stork-partner-down](/uploads/8c3fa57bbcb46f66136c670cb172648b/stork-partner-down.png)
The problem is "Detected failure w/HA" for agent-kea-ha2. It says "never".
This is not a major problem, more like confusion. The HA state correctly says "partner down", so there's indication. It's just one column contradicts another.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/415Basic access control Stork user -> Kea access2022-11-03T14:54:25ZVicky Riskvicky@isc.orgBasic access control Stork user -> Kea accessThe Kea administrator would like to be able to control who can access Kea. This includes individual Stork users, as Stork is just one channel for accessing Kea.
At the moment Stork is read-only, but it won't always be, and even control...The Kea administrator would like to be able to control who can access Kea. This includes individual Stork users, as Stork is just one channel for accessing Kea.
At the moment Stork is read-only, but it won't always be, and even controlling read-only access is important.
So it would be desirable if Stork would forward the userID of the authenticated Stork user to the Stork agent, and for this userID to be used to control the user's access to Kea, based on the privileges assigned to that user in Kea.
It is also as important as controlling access to log that access, with a time/date stamp, and what commands/api calls were executed. When there is write access (in the future) via Stork to make configuration changes, it will be particularly critical to identify who changed the configuration at what time.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/390doubled log message on debug level during HA sync2022-11-02T15:08:44ZWlodzimierz Wenceldoubled log message on debug level during HA syncduring HA sync testing I found little quirk `DHCPSRV_MEMFILE_GET_ADDR6` message is logged twice:
```
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address 2001:db8:1::b7 and le...during HA sync testing I found little quirk `DHCPSRV_MEMFILE_GET_ADDR6` message is logged twice:
```
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address 2001:db8:1::b7 and lease type IA_NA
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_ADD_ADDR6 adding IPv6 lease with address 2001:db8:1::b7
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address 2001:db8:1::b7 and lease type IA_NA
```backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/422Report an error when stork-agent uses interface which is down2022-11-16T11:54:50ZMarcin SiodelskiReport an error when stork-agent uses interface which is downAs pointed out in the following comment: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160900, it may be desired to report an error when the stork-agent is started with the `host` parameter set to the IP address on the non ...As pointed out in the following comment: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160900, it may be desired to report an error when the stork-agent is started with the `host` parameter set to the IP address on the non running interface. One way to deal with this would be to refuse starting the stork agent. At very least, the agent should log a warning message and then when the interface is up it should start functioning.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/152Add a rebuild-test target for CA, D2 and NETCONF2022-11-02T15:08:43ZFrancis DupontAdd a rebuild-test target for CA, D2 and NETCONFand of course Netconf. Currently a rebuild-test target is available only for DHCPv4 and DHCPv6: it should be adapted to anything using a flex/bison JSON syntax.and of course Netconf. Currently a rebuild-test target is available only for DHCPv4 and DHCPv6: it should be adapted to anything using a flex/bison JSON syntax.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/428HA reports incorrect IP address for remote peer2022-11-16T11:54:50ZTomek MrugalskiHA reports incorrect IP address for remote peerAs reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169306 by @godfryd:
![image](/uploads/11c8c2e8ebb90feae6df7a4f05908065/image.png)
Kea HA status, in case of remote party, displays CA address (127.0.0.1) inst...As reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169306 by @godfryd:
![image](/uploads/11c8c2e8ebb90feae6df7a4f05908065/image.png)
Kea HA status, in case of remote party, displays CA address (127.0.0.1) instead of Stork Agent address.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/440add webui unittests for changes from !2372022-03-01T14:19:02ZMichal Nowikowskiadd webui unittests for changes from !237backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/414Use new lease user contexts in RADIUS accounting2024-03-21T16:21:16ZFrancis DupontUse new lease user contexts in RADIUS accountingMigrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load...Migrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load to a CSV file is implemented but never tested.
- eraseCreateTimestamp() is called only when a STOP event is sent so the timestamp stays in memory without more control
+ obviously using an user-context is the right way: extent following the lease one, save in stable storage, etc.
If memory leak on RADIUS accounting experiments are not conclusive this should be tried.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/420Decrease CPU workload for low traffic condition in perfdhcp2022-11-02T15:10:19ZTomek MrugalskiDecrease CPU workload for low traffic condition in perfdhcp#283 implemented support for optional threaded support in perfdhcp. The code behaves better when generating high volume traffic on multi-core systems. However, it does not handle well situations where there is only one core and little tr...#283 implemented support for optional threaded support in perfdhcp. The code behaves better when generating high volume traffic on multi-core systems. However, it does not handle well situations where there is only one core and little traffic is needed.
During discussions on !135 and related it became apparent that the approach to slip for 1 us is not the right solution. The code should behave adaptively and calculate time to the next action rather than check it a million times per second.
Related MR: !165backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/421Add support-status command to rndc2021-10-15T22:01:55ZOndřej SurýAdd support-status command to rndcWhile reading https://www.ubuntu.com/info/release-end-of-life I came to an idea that it would be a good to have a `rndc support-status` command that would print the support status of the current version and the current release branch.
A...While reading https://www.ubuntu.com/info/release-end-of-life I came to an idea that it would be a good to have a `rndc support-status` command that would print the support status of the current version and the current release branch.
As it doesn't get automatically executed, it could easily just call home to ask.
@vicky @cathya What do you think?Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/430Disable case preservation when case-sensitive compression is disabled [ISC-su...2021-10-04T13:02:38ZBrian ConryDisable case preservation when case-sensitive compression is disabled [ISC-support #13227]### Description
ISC Support Customer reports significant performance impact in some situations caused by case preservation.
Specifically:
>>>
- allocation of a new dns_name_t and name copy in dns_compress_add()
- name copy in rdataset....### Description
ISC Support Customer reports significant performance impact in some situations caused by case preservation.
Specifically:
>>>
- allocation of a new dns_name_t and name copy in dns_compress_add()
- name copy in rdataset.c:towiresorted() and call to dns_rdataset_getownercase()
>>>
### Request
>>>
Admittedly these should be generally minor overhead, but in scenarios where the overall query processing is relatively cheap the performance drop can be non-negligible. Right now it exceeds the acceptable level of performance regression in our release engineering standard. If we suppress the above change the performance is (still worse than before but) acceptable.
Meanwhile, trying to preserve the case of the owner name is quite moot in practice if, for example, case-sensitive name compression is disabled. So we wonder if the case-preserving feature can be configurable at least when responding to normal queries. I'm attaching a patch (for 9.11.3-S2) that implements this idea, by disabling case-preserving when case-sensitive name compression is disabled (this could also be a separate configuration option).
>>>
### Links / references
[case.diff](/uploads/657d56eaf8595854ae83c892f438d714/case.diff)https://gitlab.isc.org/isc-projects/kea/-/issues/435A design for "backends in hooks"2022-04-21T10:39:03ZTomek MrugalskiA design for "backends in hooks"We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically...We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically, rather than included during compilation time.
The overall intention is to have a directory where hooks could be loaded from. This is similar to Apache modules. They have 2 directories: mods-available and mods-enabled. The first one contains a list of modules (hooks). The second one has symlinks to those modules (hooks) that will be loaded. This approach is super easy to understand and use. Also, very extensible, because you can package backends and other hooks in independent RPM or DEB packages.
It's different than what we do now and several things have to be changed before we get there:
1. When Kea parses configuration, it has to know what lease-database and hosts-database backends are supported. Right now it's hardcoded* (but see below). We'd need to load the hooks first and they would register available backends, then we'd process rest of the configuration.
1. RADIUS is implemented as a hook and it does provide hosts backend. Before doing anything, please investigate how it registers "radius" hosts-backend type. This is not exactly a ready to use solution (because you can't configure "radius" backend in the config yet), but they underlying implementation of backend type registration is good.
1. we need to develop a code that would load all the hooks from a directory
Things to consider:
1. name the directory properly (people complained that the hooks have incorrect name libdhcp- and also are placed in incorrect directory)
2. perhaps we could have hooks that are loaded always (call them permanent hooks maybe?). Those would be put in the hooks-enabled directory and would be loaded at kea startup and not unloaded during reconfiguration? This would be most useful for parameter-less hooks (such a config backends)
3. apache allows having a separate config file for each module. IMHO this is a bit too much, but maybe it's something to look at after all?
The goal of this ticket is to write a design. It should conclude with w written design and a list of tickets needed to implement it.outstanding