ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-10-13T23:32:53Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3102Possible bug for not pure option containers2023-10-13T23:32:53ZFrancis DupontPossible bug for not pure option containersHere the word pure means empty type, and container an option with sub-options. This ticket is from a dicussion in #2881 which fixed pure option containers.
The goal is to verify that toElement o parse gives back cvs-format and data entr...Here the word pure means empty type, and container an option with sub-options. This ticket is from a dicussion in #2881 which fixed pure option containers.
The goal is to verify that toElement o parse gives back cvs-format and data entries. If it is not the case Option::toBinary should be extended with a new parameter to not include sub-options.next-stable-2.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3100Support array of OPT_RECORD_TYPE for Option definition2024-01-09T11:40:57ZPiotrek ZadrogaSupport array of OPT_RECORD_TYPE for Option definitionWhile working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.While working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3096No error message when I apply a different subnet with the same subnet id2023-10-05T20:40:41ZSandeep 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,
Sandeepnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3094Support for IPv6-only networks with RFC 8925 (v6-only-preferred)2023-09-28T14:31:07ZBrian CandlerSupport for IPv6-only networks with RFC 8925 (v6-only-preferred)**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on ...**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on kea-users or kea-dev mailing lists? Yes: https://lists.isc.org/pipermail/kea-users/2023-July/004207.html
**Is your feature request related to a problem? Please describe.**
In APRICOT 2024 next year, there will be a separate IPv6-only wifi network (in parallel with the main conference SSID). There's nothing new about that.
However, this year we want to ensure that clients will gracefully fall back to IPv6-only operation *and* make use of a NAT64 device to access the IPv4-only Internet via the client's embedded CLAT. MacOS, Android and iOS support this mode of operation. Full details are in the article here: https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/
In summary, these clients will request option 108 in their (DHCPv4) discover request. The server should respond with yiaddr 0.0.0.0 and option 108. The client will then activate their CLAT, as long as they also get the NAT64 prefix from a separate field (PREF64) in the RA's.
Running ISC-KEA or ISC-DHCPD for the DHCPv4 service doesn't currently work well here. Well, it *does* work for those clients which support option 108. But for clients which don't, they will be offered an IPv4 address, and will configure their interface with it. This is supposed to be an IPv6-only network, and hence we don't want machines to pick up an IPv4 address. They will find they have failing connectivity when they try to use their IPv4 address.
*Not* running a DHCPv4 server at all is not an option, because the clients won't enable their CLAT unless they've successfully done the option 108 dance.
**Describe the solution you'd like**
I would like KEA to implement the following:
- Allow IPv4 subnets to have no pool
- Allow IPv4 subnets to have a flag for enabling v6-preferred
- In such a subnet, if a client requests option 108, then return yiaddr 0.0.0.0 with option 108
- (Optionally: if I client sents option 116, then return yiaddr 0.0.0.0 with option 116)
- Otherwise, if there's no pool, then do whatever you'd normally do when the pool is exhausted (presumably either send no response, or send a NAK)
(Option 116 is RFC 2563: it also returns yiaddr 0.0.0.0. It lets you tell a client *not* to configure a global v4 address, and also to tell it whether or not to configure a link-local address. In principle, it could also reduce DHCPv4 discovery chatter in networks without v4. However I mark this support "optionally" because I've not actually found a client which makes use of this option yet)
**Describe alternatives you've considered**
There's a discussion in the list at https://lists.isc.org/pipermail/kea-users/2023-July/004207.html
The key thing I need to make sure is that *no* IPv4 address is returned to a client unless it requests option 108.
Note that the client doesn't actually *send* option 108, it puts 108 in its parameter request list, and it seems to be quite tricky to handle this in KEA. The best I could come up with was:
```
"client-classes": [
{
"name": "rfc8925",
// We need to test whether option 108 is in the client's parameter request list (option 55).
// That's not the same as "option[108].exists"
// https://kea.readthedocs.io/en/latest/arm/classify.html#using-expressions-in-classification
"test": "substring(option[55].hex, 0, 1) == 0x6c
or substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2, 1) == 0x6c
or substring(option[55].hex, 3, 1) == 0x6c or substring(option[55].hex, 4, 1) == 0x6c
or substring(option[55].hex, 5, 1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c
or substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8, 1) == 0x6c
or substring(option[55].hex, 9, 1) == 0x6c or substring(option[55].hex, 10, 1) == 0x6c
or substring(option[55].hex, 11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
},
],
```
(it's ugly and incomplete - what if the client send more than 13 options?)
Then avoid sending any response to clients which *don't* provide this option:
```
"pools": [
{
// Only give OFFERs to devices which support RFC 8925
"pool": "10.12.65.2 - 10.12.65.254",
"client-class": "rfc8925"
}
],
"option-data": [
{
"name": "v6-only-preferred",
"data": "0"
}
],
```
That kind-of works. It's still not entirely RFC 8925 compliant as it *should* set the yiaddr to 0.0.0.0 (I couldn't see how to do that with the non-commercial plugins) and it *shouldn't* need to consume an address from the pool, although I can make that pool arbitrarily large.
As described before: the option of *not* running DHCPv4 service doesn't work, because the clients won't activate their CLAT without having received option 108.
What I have ended up doing is writing some custom DHCPv4 server modules for a standalone Go DHCP server:
https://github.com/coredhcp/coredhcp/pull/170
**Additional context**
This is a demonstration network at a conference, so it's not exactly "production" but more is a technology demonstrator of how well an IPv6-only network with NAT64 could work.
When I've tested this locally, I find that IPv4 access via the NAT64 works nicely, even when using IPv4 literals. For example, "ping 8.8.8.8" or browse to https://1.1.1.1 work fine (except from Safari). The traffic is actually IPv6 across to the NAT64. No DNS64 is required.
We'd like to demonstrate this so people can evaluate the feasibility of real deployment of single-stack IPv6 networks now or in the future.
**Funding its development**
Only in-kind development contributions
**Participating in development**
Yes, willing to contribute to discussions and/or testing.
**Contacting you**
brian@nsrc.orgnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3090Move the krb5.conf config file in hammer2023-10-05T13:49:05ZFrancis DupontMove the krb5.conf config file in hammerWhen a Kerberos V library is installed a kerb5.conf config file is installed. Often it interferes with the gss_tig hook unit tests making some of them to fail. As documented in the ARM the default setting from this config file can be inc...When a Kerberos V library is installed a kerb5.conf config file is installed. Often it interferes with the gss_tig hook unit tests making some of them to fail. As documented in the ARM the default setting from this config file can be incompatible with these tests. The solution is to remove or rename it: this ticket is about doing this in hammer.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3064performance drop during 2.3 release cycle for mysql2023-09-21T13:53:17ZWlodzimierz Wencelperformance drop during 2.3 release cycle for mysqlWe observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at...We observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at_09.57.01](/uploads/d9fb7fbabb11d49faa3e40efbd6f4bac/Screenshot_2023-09-14_at_09.57.01.png)
Please check [report on master](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html), during this work I was testing migration to binary addresses in mysql and this did not show performance degradation in [the report](https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/performance/108/artifact/qa-dhcp/kea/performance-jenkins/report.html)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3062Any interface created while retrying sockets are used unfiltered2024-02-08T14:35:31ZEfe Can İçözAny interface created while retrying sockets are used unfiltered
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in conf...
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in configuration file.
**To Reproduce**
Steps to reproduce the behavior:
1. Set a dummy interface and ensure that it's down.
`ip link add dummy0 type dummy`
`ip addr add 192.168.1.1/24 dev dummy0`
`ip link set dummy0 down`
2. Run Kea dhcp4 server with the following config
{
"Dhcp4": {
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"interfaces-config": {
"interfaces": [ "dummy0/192.168.1.1" ],
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 1000
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/dhcp4.leases"
},
"subnet4": [
{
"subnet": "192.168.1.0/24",
"interface": "dummy0",
"pools": [
{
"pool": "192.168.1.4 - 192.168.1.254",
}
]
}
]
}
}
3. At this point Kea will print `DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface dummy0 is down` messages.
4. Add another interface with
`ip link add dummy1 type dummy`
`ip addr add 10.10.1.1/24 dev dummy1`
`ip link set dummy1 up`
5. Set dummy0 online to let Kea run
`ip link set dummy1 up`
6. Check open sockets by Kea
`netstat -tulpan | grep kea` which is
udp 0 0 192.168.1.1:67 0.0.0.0:* 694387/kea-dhcp4
udp 0 0 10.10.1.1:67 0.0.0.0:* 694387/kea-dhcp4
**Expected behavior**
Server should only listen _dummy0_ interface.
**Environment:**
- Kea version: 2.2.0
- OS: Ubuntu 22.04.3 x64
**Additional Information**
This issue happened also on our custom yocto build on imx8qxp with aarch64next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3057Update Template Classes in the ARM2024-03-22T06:23:10ZPeter DaviesUpdate Template Classes in the ARMTo save duplicating work in updating two sources of documentation it has been
suggested the the KB article about [template](https://kb.isc.org/docs/facilitating-classification-with-template-classes) classes could be moved to the ARM. ...To save duplicating work in updating two sources of documentation it has been
suggested the the KB article about [template](https://kb.isc.org/docs/facilitating-classification-with-template-classes) classes could be moved to the ARM.
The "Facilitating Classification with Template Classes" KB article contain the
following use case examples:
Example. OUI Vendor
Use case 1. Reference the spawned class directly in configuration
Use case 2. Have a class dependency on the template class or spawned class
Use case 3. Define the spawned class
Use case 4. Lease limiting and rate limiting ok
The following examples are not found in the ARM:
Use case 1. Reference the spawned class directly in configuration
Use case 2. Have a class dependency on the template class or spawned classnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3056libdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) pack...2023-09-23T09:04:56ZEddict NLlibdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) package in Cloudsmith---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
libdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) package in Cloudsmith
**To Reproduce**
Steps to reproduce the behavior:
1...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
libdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) package in Cloudsmith
**To Reproduce**
Steps to reproduce the behavior:
1. Add ISC Kea 2.4 Cloudsmith repository (https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian bookworm InRelease)
2. apt install (isc-kea and) isc-kea-hooks
3. there are 8 .so files in /usr/lib/x86_64-linux-gnu/kea/hooks/
4. libdhcp_user_chk.so is missing
**Expected behavior**
libdhcp_user_chk.so is installed as well
**Environment:**
- Kea version: 2.4.0 installed from repository
- OS: Debian GNU/Linux 12 (bookworm)
- Which features were compiled in: N/A
- If/which hooks where loaded in
**Additional Information**
N/A
**Contacting you**
How can ISC reach you to discuss this matter further? herenext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3040failure to start up with ppp interfaces2024-02-08T14:35:31ZJaco Kroonfailure to start up with ppp interfaces2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed...2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed to bind socket 20 to fe80::e/port=547: Cannot assign requested address
```
26: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1350 qdisc tbf state UNKNOWN group default qlen 3
inet6 fe80::14e4:139f:8862:3dfd peer fe80::e/128 scope link
valid_lft forever preferred_lft forever
```
Obviously we should bind to the local link-local, not the remote one.
kea 2.4.0. 2.5.1 segfaults on my configuration:
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "ppp0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea6-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"option-data": [
{
"name": "dns-servers",
"data": "2c0f:f720::..., 2c0f:f720::..."
}
],
"subnet6": [
{
"subnet": "2c0f:f720:fcf0::/44",
"pd-pools": [
{
"prefix": "2c0f:f720:fcf0::",
"prefix-len": 44,
"delegated-len": 56
}
]
}
],
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea/kea-dhcp6.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
Strace from a re-run (so socket number is different):
```
bind(19, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
getsockname(19, {sa_family=AF_NETLINK, nl_pid=6688, nl_groups=00000000}, [12]) = 0
sendto(19, [{nlmsg_len=20, nlmsg_type=RTM_GETLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_DUMP, nlmsg_seq=1, nlmsg_pid=0}, {ifi_family=AF_PACKET, ...}], 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
recvmsg(19, {msg_name={sa_family=AF_NETLINK ...
ifa_index=if_nametoindex("ppp0")}, [[{nla_len=20, nla_type=IFA_LOCAL}, **inet_pton(AF_INET6, "fe80::14e4:139f:8862:3dfd")], [{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::e")],** [{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=168714876, tstamp=168714876}], [{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT]]], [{nlmsg_len=72, nlmsg_type=RTM_NEWADDR, nlmsg_flags=NLM_F_MULTI, nlmsg_seq=2, nlmsg_pid=6688}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK,
...
close(19) = 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 19
ioctl(19, SIOCGIFINDEX, {ifr_name="ppp0", ifr_ifindex=26}) = 0
close(19) = 0
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 19
fcntl(19, F_SETFD, FD_CLOEXEC) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(19, {sa_family=AF_INET6, sin6_port=htons(547), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "**fe80::e**", &sin6_addr), sin6_scope_id=if_nametoindex("ppp0")}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
close(19) = 0
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3035Expose interface-id in dhcpv6 hook points2023-09-21T13:22:34ZSorin EsanuExpose interface-id in dhcpv6 hook pointsHello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!Hello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3024Post audit: Write KB article/ARM section about securing DB connection2023-09-21T10:10:03ZTomek MrugalskiPost audit: Write KB article/ARM section about securing DB connectionAs pointed out in [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#12-secure-db-connection), we should have a kind of tutorial or step by step guide how to secure Kea and MariaDB/Postgres connect...As pointed out in [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#12-secure-db-connection), we should have a kind of tutorial or step by step guide how to secure Kea and MariaDB/Postgres connection.
I think this would be best achieved by having a config example in the ARM + a KB article explaining how to do the changes in Maria/Postgres installations.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3022Post audit: retire MD5 and SHA12023-09-21T10:10:13ZTomek MrugalskiPost audit: retire MD5 and SHA1By using MD5 in particular and SHA1 to some degree, we risk getting more complaints, even if those are used in contexts that are not security related. Some procurement processes might simply ask if obsolete and broken algorithms are in u...By using MD5 in particular and SHA1 to some degree, we risk getting more complaints, even if those are used in contexts that are not security related. Some procurement processes might simply ask if obsolete and broken algorithms are in use. If they are, the software might be determined not suitable.
In one case, we had an interaction with a user who had those explicitly disabled in their deployment for security reasons.
If we decide to keep those, there should be a very good explanation in the ARM why keeping those is acceptable. "because getting rid of them is a lot of work" is not a good explanation.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3021Post audit: update ARM to show how to confirm source code integrity2023-09-21T10:09:54ZTomek MrugalskiPost audit: update ARM to show how to confirm source code integrityAnother proposal by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). We should document how to check the integrity of the source code ...Another proposal by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). We should document how to check the integrity of the source code (and packages, too).
With the SBOM being increasingly focused, this is an important aspect. Fortunately, it's very easy doc update.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3020Post audit: investigate if basic auth with http could be discouraged2023-09-21T10:09:47ZTomek MrugalskiPost audit: investigate if basic auth with http could be discouragedAnother [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth o...Another [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth over plain HTTP. It's insecure, but maybe in some experiments it might be useful, so we probably shouldn't forcibly abort.
But perhaps print a warning with a link to ARM section explaining why it's wrong would do?next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3015Post audit: update docs2023-09-21T10:10:46ZTomek MrugalskiPost audit: update docs@manu completed an audit and pointed the following problems [in his report](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023):
- [ ] 2. Elaborate more about \[meta\] package, in particular how to run only selec...@manu completed an audit and pointed the following problems [in his report](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023):
- [ ] 2. Elaborate more about \[meta\] package, in particular how to run only selected service. Looks like a good idea also to update the security section and point out that one should only run the services that are strictly needed.
- [ ] 3. Elaborate more about `interface` requirement for making the service running in [ARM QuickStart section](https://kea.readthedocs.io/en/kea-2.2.0/arm/quickstart.html#quick-start-guide-for-dhcpv4-and-dhcpv6-services) - this should be easy, a sentence or two pointing out that binding address is by default set to defensive 127.0.0.1.
- [ ] 4. Correct references in configs
- [ ] 5. Clarify sentence in DDNS (it's `dhcp-ddns` in `Dhcp4` or `Dhcp6`)
- [ ] 6. Clarify about sockets open by default (add something like this "While Kea doesn't open any sockets by default on its own, the default configs shipped with packages do define some socket and Kea opens them).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3005ddns CHG_ADD before CHG_REMOVE2023-11-16T18:46:52Zphilip-smartbitddns CHG_ADD before CHG_REMOVE---
name: ddns add nsupdate before remove nsupdate
---
**Describe the bug**
we updated kea to 2.4.0 and set ddns-update-on-renew to true. Since the update we noticed that some hosts lost their dns records (but had a correct lease). fr...---
name: ddns add nsupdate before remove nsupdate
---
**Describe the bug**
we updated kea to 2.4.0 and set ddns-update-on-renew to true. Since the update we noticed that some hosts lost their dns records (but had a correct lease). from around 13:00 07/aug/2023 until now we had 6 hosts losing their dns record. we updated to kea 2.4.0 on 13:00 07/aug/2023
In the kea ddns log we noticed that the problem hosts all showed a CHG_ADD before a CHG_REMOVE:
2023-08-07 18:07:36.634 INFO [kea-dhcp-ddns.d2-to-dns/1587] DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [host01.internal.]
IP Address: [10.20.30.40]
DHCID: [000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3]
Lease Expires On: 20230807161112
Lease Length: 216
Conflict Resolution: no
2023-08-07 18:07:36.674 INFO [kea-dhcp-ddns.d2-to-dns/1587] DHCP_DDNS_REMOVE_SUCCEEDED DHCP_DDNS Request ID 000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3: successfully removed the DNS mapping addition for this request: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [host01.internal.]
IP Address: [10.20.30.40]
DHCID: [000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3]
Lease Expires On: 20230807154204
Lease Length: 216
Conflict Resolution: no
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcp4 with the following settings enabled:
"ddns-update-on-renew": true,
"ddns-use-conflict-resolution": false
2. A few hunderd vm's doing a renew every 1800 seconds
3. wait and randomly some hosts lose their dns record's
4. See error above
**Expected behavior**
we expect that kea ddns *always* does a CHG_REMOVE before a CHG_ADD
**Environment:**
- Kea version: 2.4.0 with default multithreading on, package installed via cloudsmith debian repo
- OS: Debian 11
- ha is enabled with default multithreading on, hot-standby
- auth dns server is powerdns 4.8.1
**Additional Information**
we only use dhcp4, no dhcp6
we configured powerdns with distributor-threads=1 and reuseport=no
The kea and (power)dns vm's didn't have high cpu usage or iowait, they weren't overload in any way.
**Contacting you**
contact via gitlab or emailnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2981"make coverage" doesn't work2023-08-10T13:44:47ZAndrei Pavelandrei@isc.org"make coverage" doesn't workThe coverage job in our internal Jenkins test environment started failing, when we upgraded Fedora from 36 to 38, likely because of a new gcovr version. That job uses an out-of-band set of actions to build the coverage report. While look...The coverage job in our internal Jenkins test environment started failing, when we upgraded Fedora from 36 to 38, likely because of a new gcovr version. That job uses an out-of-band set of actions to build the coverage report. While looking for alternatives, it was noticed that `make coverage` doesn't work either:
```
$ make coverage
[... goes on to run unit tests, but when the report needs to be made aka "make report-coverage" ...]
/bin/sh: -c: line 9: syntax error: unexpected end of file
make: *** [Makefile:1126: report-cpp-coverage] Error 2
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2974New localize DHCP server command2023-09-01T14:23:21ZFrancis DupontNew localize DHCP server commandThe idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.The idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2961Remove support for the deprecated auto-generated subnet IDs feature2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated auto-generated subnet IDs feature[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ipv4-subnet-identifier):
> It is one of the reasons why auto-generated subnet identifiers are deprecated starting from Kea version 2.4.0.
The deprecatio...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ipv4-subnet-identifier):
> It is one of the reasons why auto-generated subnet identifiers are deprecated starting from Kea version 2.4.0.
The deprecation happened in Kea 2.4. Kea 2.4 shipped with the deprecation warning in the ARM. Kea 2.5 can have the feature removed.next-stable-2.6