The Hacker News discussion expresses several key themes regarding the Kea DHCP server and its context within the networking landscape.
Kea's Identity and Purpose
The primary theme is the clarification of what Kea is. Many users initially express confusion, leading to a consensus that Kea is a DHCP server developed by ISC (Internet Systems Consortium). It's positioned as the successor to the long-standing ISC DHCP (dhcpd), which has reached its end-of-life and is no longer supported.
- "I’ll google it in a moment, but skimming those notes, I have no idea what Kea is." (dgfitz)
- "A DHCP server? for those who are wondering" (lousken, digitalPhonix)
- "As others have said, Kea is a DHCP server. More than that, it is an ISC project, is the successor to ISC DHCP (now end-of-life & unsupported for a few years), and weirdly started out as part of BIND 10." (gertrunde)
Advantages and New Features of Kea
Several users highlight the intended benefits and advancements Kea brings over its predecessor. These include improved scalability, support for large and complex installations, multithreading, database backends, and plugins for specialized use cases. The ability to reload configurations without a full restart is also mentioned as a significant improvement.
- "Kea's new thing is scaling up for very large/complex installations (multithreading, database backends, a fair amount of plugins for specialized use cases)." (Sesse__)
- "One rather annoying thing that ISC dhcpd couldn't do was reload its config file without a full restart (and I believe Kea can)." (Sesse__)
Criticisms and Perceived Drawbacks
A significant portion of the discussion revolves around criticisms and concerns about Kea's design and implementation. A prominent critique, spearheaded by user JdeBP, is that Kea appears to be repeating architectural mistakes made by older software like BIND and Sendmail. This includes running as a superuser while serving requests from potentially hostile clients, rather than fully leveraging unprivileged daemons or systemd's socket activation for dropping privileges. The complexity of Kea's multi-daemon architecture and the difficulty in ensuring the security of its configurations are also points of concern.
- "It yet again runs as the superuser serving requests from potentially hostile clients. In fairness, a lot of DHCP servers do this; but Kea development was in a position to have learned the ideas about using unprivileged dæmons, having started years later than them. Instead, its documented approach to running as some other account is to add some of the superuser's privileges to Kea, completely missing the point of running large complex programs without privileges, which was a major long-standing criticism of BIND and Sendmail that didn't just come from Daniel J. Bernstein." (JdeBP)
- "My problem (well, one of my problems) with Kea is more that it's too many different daemons that you have to configure separately and get to talk to each other, and it's not immediately obvious if any given configuration is secure or not (e.g., can others open a socket of the same name?)." (Sesse__)
- "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." (JdeBP)
Integration with Other Systems (pfSense, OPNsense)
The discussion also touches upon Kea's integration and adoption within popular firewall/router distributions like pfSense and OPNsense. Users share mixed experiences, with some reporting buggy transitions and others finding it stable. OPNsense, in particular, is noted for rapidly adopting Kea while also offering Dnsmasq as a default option, signaling a potential shift away from ISC DHCP. The preference for stability over bleeding-edge features in firewall software is also stated.
- "I wonder when this will make it into pfsense... The transition to kea has been a bit of a mess with tons of bugs. Thankfully it's controlled by an option, and it seems like 2.8.0 knocked out quite a few of them" (kayson)
- "We are going to make Dnsmasq DHCP the default in new installations starting with 25.7, too. ISC DHCP will still be around as a core component in 25.7 but likely moves to plugins for 26.1 next year." (v5v3, quoting OPNsense release notes)
- "For a firewall, I prefer stability over features. Jumping to the newest releases every month can have tradeoffs." (Helmut10001)
- "Anyway, at the time Kea (at least in pfSense) wasn't able to do that, which caused things to break for me for a bit. It's a small thing (and, I mean, totally fair with free software) but the fact that they pushed an update to Kea before Kea (again, at least in pfSense) was at feature parity rubbed me the wrong way and has kept me from using it since then." (sjm-lbm)
- "I've tried a few times to switch to Kea in PFsense but it crashes my network fiercely." (blamazon)
Historical Context and Comparisons to DJB
The conversation also delves into historical context, drawing parallels with the critiques leveled against BIND by Daniel J. Bernstein (DJB). This comparison is used to underscore the perceived philosophical and architectural issues some developers have with widely used network services. The discussion acknowledges DJB's highly critical stance and his development of alternative, simpler tools, while also noting that his criticisms were often extremely detailed.
- "I remember Dan Bernstein (djb) being scathing about BIND. To the extent of writing his own DNS suite. Is that all ancient history now?" (kjellsbells)
- "Most of the criticisms were accurate, if often very, very, very detail-oriented. DJB has always had a few settings: either you're on his level, on his wavelength, or he treats you as maybe bright enough to tie your own shoelaces on a good day." (simtel20)
- "No. Kea is making several of the same mistakes all over again, despite being in a good position to have learned from them." (JdeBP)