kea

ve had systemd doing the privileged opening of the sockets with low-numbered UDP ports, and the dropping of privileges, before starting up Kea. But Kea (again, like many of the pre-systemd DHCP servers like the WIDE one or the BusyBox one) opens and listens on sockets itself, and has no attempt at enabling use of systemd's mechanism in this regard. There is still the old flawed mechanism of PID files liberally sprinkled around, too. * https://github.com/isc-projects/kea/blob/048b1e9b1acbb0ff962... And of course, Kea took some of the BIND 10 code. There is a lot of continuation of long standing BIND Think in Kea, alas. There's so much promise to the idea of having DHCP servers use shared database back-ends, but it's spoiled by all of the continued BIND Think and things like having an HTTP server with JSON parser in all of these superuser-privileged dæmons. One of these days, someone will actually run with the idea that I mentioned somewhen in the early 2000s: a DHCP server that shared a common database with a content DNS server. No notification messages for mapping updates, no little shim dæmons, just serving out the information in the shared database directly, complete with (say) TTLs that match the lease expiry times. People have danced around this idea for a long time, but never quite fully hit it. PowerDNS can use custom database back ends, for example, but people still have not fully run with that and instead ended up with a DHCP server with a database sending potentially dropped notifications over a terrible protocol to a content DNS server also with its own separate database back end. * http://tuxad.com/txdyn-doc.html * https://holland-consulting.net/tech/dhcp-dns.html * https://github.com/AliveDevil/pdns-dhcp * https://gitlab.isc.org/isc-projects/kea/-/issues/1409 Microsoft Windows Server's DNS server with AD integration perhaps came the closest, but even with that the out-of-the-box setup had things like DHCP clients sending (some of) the update notifications.