I observe how so many of these kinds of release announcements do not start the text with a brief line introducing the project. I had never heard of Kea and clicked through out of curiosity, but that info is yet another click away: Kea is a "Modern, open source DHCPv4 & DHCPv6 server".
Right? I find submissions titles like this so frustrating: it's simply not possible to be aware of every project out there. Please, please provide me some context in the title. This would be way better with a title something like "ISC releases KEA DHCP server 3.0 as LTS"
Copy paste that phrase on every piece of content to save you a click? Why would you describe a project on a > v1 release announcement? After v1 the project has been introduced, no reason to continuously reintroduce it because someone might eventually add it to their zeitgeist.
I have a positive ending Kea story. We deployed 20,000 PS5 APUs (AKA: AsRock BC-250) each is a individual blade computer that was PXE booted.
We started to see strange behavior on the network and it took a bit of trial and error to figure out what was going wrong. Eventually, we traced it down to dnsmasq being unable to keep up with all the DHCP UDP traffic regardless of how we tuned the kernel/networking buffers.
Switched to Kea and all of our problems magically went away.
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.
Would be nice if Infoblox used Kea instead of dhcpd, that way you could change DHCP reservations without having to restart the services to have it take effect.
That sort of thing is why I wrote my own DHCPv4 server that is directly integrated with the core product at $DAYJOB. 10 years ago. Having the DHCP server determine how to handle PXE requests straight from the machine database made my life so much simpler.
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.
That said, if you want to run a dns server and don't have huge scalable business to run on it, you can just run tinydns for a couple of decades and not worry about security issues, it just runs. BIND is more complex, and has evolved a lot more to do more because new features are implemented it as the reference, and so it needs to both scale up and out, and also change a lot, and for that, you get https://kb.isc.org/docs/aa-00913. So anyway, you can make up your mind, but my impression as a greying beard is that ISC has always been a risk you usually just need to accept if you need their tools since no-one else is doing anything to dethrone them.
No. Kea is making several of the same mistakes all over again, despite being in a good position to have learned from them.
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.
It's interesting that systemd is mentioned there, because a socket unit would have 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.
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.
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.
> It's interesting that systemd is mentioned there, because a socket unit would have had systemd doing the privileged opening of the sockets with low-numbered UDP ports, and the dropping of privileges, before starting up Kea.
Can systemd give you the raw sockets you need to answer DHCP on a local network?
One rather annoying thing that ISC dhcpd couldn't do was reload its config file without a full restart (and I believe Kea can). That's pretty hard to do if you insist on someone else opening sockets for you, although you could of course demand a restart in this case.
TBH 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?).
> Instead, its documented approach to running as some other account is to add some of the superuser's privileges to Kea [...]
Not disagreeing, just want to mention that Kea can run fine without privileges, which is also documented at the link provided. Key is to use DHCP relaying, a technique which becomes relevant quickly in larger setups anyways because you cannot (or don't want to) give the DHCP server access to all subnets: Instead of the DHCP server(s) processing local requests, DHCP relaying agents encapsulate and unicast-forward the whole DHCP request-response traffic to centralized DHCP instance(s). Those relaying agents (on switches/routers) do require privileges but potentially posing a smaller attack surface due to being much simpler. Sadly, ISC has not made a successor dhcprelay as part of Kea, but luckily systemd-networkd implements the RelayTarget parameter, adding this capability (at least for IPv4).
Does systemd socket activation even work with broadcast packets? One of the things a dhcp server needs to do is respond to DHCPDISCOVER packets, which are sent to the all-broadcast 255.255.255.255 .
There's nothing stopping it. systemd doesn't do anything particularly special when opening a datagram socket that magically prevents it from receiving broadcast datagrams. There's no difference between Kea opening the socket and systemd opening the socket, except that systemd can do it and then drop privileges before Kea is loaded and run.
Or could do it.
If it weren't that Kea has no mechanism for taking and just using an already-open socket.
Remember that Accept in a socket unit has no meaning for ListenDatagram sockets. There's no waiting for incoming connections before activation going on.
If you're asking about the detailed internals of what systemd does with BPF and how that meshes with what Kea does, then I leave that to be answered by the systemd and Kea people. (-:
Kea's new thing is scaling up for very large/complex installations (multithreading, database backends, a fair amount of plugins for specialized use cases). Which almost nobody really needs to do, so it's a shame ISC dhcpd was discontinued before Kea was at full feature parity.
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
I have been using Kea on pfSense CE for a long time — I think it was version 23.0.x. Or you mean 3.0 in particular? I also have OPNsense and I am not completely convinced of their aggressive update strategy yet. For a firewall, I prefer stability over features. Jumping to the newest releases every month can have tradeoffs.
Note: in general, both OPNsense and pfSense are excellent. I have never had any problems with either one.
I use pfSense CE, and rely on DNS entries to be automatically created for DHCP addresses. That worked fine for more than a decade, until they made Kea the default a couple of years ago (or did they just put a bunch of notices in the interface that old DHCPd was deprecated? It's been long enough that I don't remember).
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.
(edit: on the off chance anyone cares, I decided to check and it looks like this issue has been fixed as of pfSense CE 2.8.)
I don't follow pfsense too much but my understanding is OPNsense typically brings in package updates faster as they have a more frequent update cycle. I can't speak too much to bugs as I haven't migrated to Kea but imo some core functionality wasn't there until recently. And Dnsmasq seems like a better fit for me anyway, which is where I'll migrate to.
From the 25.1.6 OPNsense May update notes:
> Last but not least: Kea DHCPv6 is here. And with it full DHCP and router advertisement support in Dnsmasq to bridge the gap for ISC users who do not need or want Kea. 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.
I've been using it on opnsense since the first version it was released in. I aggressively switched because wanted to ditch my weird setup to do multi subnets (forwarding though a l3 switch). Haven't had any issues.
Great to see the hook libraries being mostly open sourced!
I was quite ok with paying the $500 or so to license the features, but the friction to get that through procurement processes also ended up killing it.
Kea is perfect for integrating with zero touch provisioning automation processes.
Back then, I used ISC's DHCP server, but nowadays you have other options like AdGuard Home which includes a nice web UI that is simpler to manage than just a daemon implementation.
I observe how so many of these kinds of release announcements do not start the text with a brief line introducing the project. I had never heard of Kea and clicked through out of curiosity, but that info is yet another click away: Kea is a "Modern, open source DHCPv4 & DHCPv6 server".
Right? I find submissions titles like this so frustrating: it's simply not possible to be aware of every project out there. Please, please provide me some context in the title. This would be way better with a title something like "ISC releases KEA DHCP server 3.0 as LTS"
The HN guidelines state to use the original title "unless it is misleading or clickbait", which is why this happens.
Copy paste that phrase on every piece of content to save you a click? Why would you describe a project on a > v1 release announcement? After v1 the project has been introduced, no reason to continuously reintroduce it because someone might eventually add it to their zeitgeist.
> Copy paste that phrase on every piece of content to save you a click?
Yes please.
I have a positive ending Kea story. We deployed 20,000 PS5 APUs (AKA: AsRock BC-250) each is a individual blade computer that was PXE booted.
We started to see strange behavior on the network and it took a bit of trial and error to figure out what was going wrong. Eventually, we traced it down to dnsmasq being unable to keep up with all the DHCP UDP traffic regardless of how we tuned the kernel/networking buffers.
Switched to Kea and all of our problems magically went away.
Wow, I didn't know the BC250s were used at such scale. I bought two to play with for dirt cheap, but haven't gotten around to it yet.
Are they primarily used for mining?
We used them for mining ethereum, but no longer.
There is a good fairly easily discovered discord out there for enthusiasts.
Can one run mainline Linux on these boards?
Information on running the AMD BC-250 powered ASRock mining boards as a desktop
https://github.com/mothenjoyer69/bc250-documentation
We ran Linux (Ubuntu) on them, PXE booted with a minimal image.
ISC DHCPd is (being) EOLed.
Kea is ISC's new DHCP server.
Has been. It was done two and a bit years ago, and the change has even reached Debian now. (-:
* https://packages.debian.org/source/trixie/isc-dhcp
* https://isc.org/blogs/isc-dhcp-eol/
I’ll google it in a moment, but skimming those notes, I have no idea what Kea is.
The submitted link might be better changed to the actual release notes: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Note... which start with this information.
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.
Ref: https://www.isc.org/dhcphistory/#the-kea-dhcp-server
(And I vaguely recall it's used as the DHCP component in a few other things, like maybe Infoblox).
Would be nice if Infoblox used Kea instead of dhcpd, that way you could change DHCP reservations without having to restart the services to have it take effect.
That sort of thing is why I wrote my own DHCPv4 server that is directly integrated with the core product at $DAYJOB. 10 years ago. Having the DHCP server determine how to handle PXE requests straight from the machine database made my life so much simpler.
I was wondering that too. A DHCP server, apparently: https://www.isc.org/kea/
(This is one place where I think a little editorializing to the page title to add context would be helpful.)
A DHCP server for those who are wondering
Won't take long, ISC doesn't do 'much' but they do it well
I remember Dan Bernstein (djb) being scathing about BIND. To the extent of writing his own DNS suite. Is that all ancient history now?
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.
That said, if you want to run a dns server and don't have huge scalable business to run on it, you can just run tinydns for a couple of decades and not worry about security issues, it just runs. BIND is more complex, and has evolved a lot more to do more because new features are implemented it as the reference, and so it needs to both scale up and out, and also change a lot, and for that, you get https://kb.isc.org/docs/aa-00913. So anyway, you can make up your mind, but my impression as a greying beard is that ISC has always been a risk you usually just need to accept if you need their tools since no-one else is doing anything to dethrone them.
[dead]
I'll let everyone make their own judgement :) https://en.wikipedia.org/wiki/Djbdns
Find something as popular that hasn't been scathed-about; I'll wait
No. Kea is making several of the same mistakes all over again, despite being in a good position to have learned from them.
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.
* https://kea.readthedocs.io/en/latest/arm/install.html#runnin...
It's interesting that systemd is mentioned there, because a socket unit would have 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.
> It's interesting that systemd is mentioned there, because a socket unit would have had systemd doing the privileged opening of the sockets with low-numbered UDP ports, and the dropping of privileges, before starting up Kea.
Can systemd give you the raw sockets you need to answer DHCP on a local network?
One rather annoying thing that ISC dhcpd couldn't do was reload its config file without a full restart (and I believe Kea can). That's pretty hard to do if you insist on someone else opening sockets for you, although you could of course demand a restart in this case.
TBH 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?).
> Instead, its documented approach to running as some other account is to add some of the superuser's privileges to Kea [...]
Not disagreeing, just want to mention that Kea can run fine without privileges, which is also documented at the link provided. Key is to use DHCP relaying, a technique which becomes relevant quickly in larger setups anyways because you cannot (or don't want to) give the DHCP server access to all subnets: Instead of the DHCP server(s) processing local requests, DHCP relaying agents encapsulate and unicast-forward the whole DHCP request-response traffic to centralized DHCP instance(s). Those relaying agents (on switches/routers) do require privileges but potentially posing a smaller attack surface due to being much simpler. Sadly, ISC has not made a successor dhcprelay as part of Kea, but luckily systemd-networkd implements the RelayTarget parameter, adding this capability (at least for IPv4).
Does systemd socket activation even work with broadcast packets? One of the things a dhcp server needs to do is respond to DHCPDISCOVER packets, which are sent to the all-broadcast 255.255.255.255 .
There's nothing stopping it. systemd doesn't do anything particularly special when opening a datagram socket that magically prevents it from receiving broadcast datagrams. There's no difference between Kea opening the socket and systemd opening the socket, except that systemd can do it and then drop privileges before Kea is loaded and run.
Or could do it.
If it weren't that Kea has no mechanism for taking and just using an already-open socket.
Remember that Accept in a socket unit has no meaning for ListenDatagram sockets. There's no waiting for incoming connections before activation going on.
If you're asking about the detailed internals of what systemd does with BPF and how that meshes with what Kea does, then I leave that to be answered by the systemd and Kea people. (-:
they certainly made some memorable CVEs well
Next gen reference DHCP server. IIRC it's new thing is IPv6 support.
Not really; ISC dhcpd supported DHCPv6 just fine.
Kea's new thing is scaling up for very large/complex installations (multithreading, database backends, a fair amount of plugins for specialized use cases). Which almost nobody really needs to do, so it's a shame ISC dhcpd was discontinued before Kea was at full feature parity.
DHCP server?
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
I have been using Kea on pfSense CE for a long time — I think it was version 23.0.x. Or you mean 3.0 in particular? I also have OPNsense and I am not completely convinced of their aggressive update strategy yet. For a firewall, I prefer stability over features. Jumping to the newest releases every month can have tradeoffs.
Note: in general, both OPNsense and pfSense are excellent. I have never had any problems with either one.
I use pfSense CE, and rely on DNS entries to be automatically created for DHCP addresses. That worked fine for more than a decade, until they made Kea the default a couple of years ago (or did they just put a bunch of notices in the interface that old DHCPd was deprecated? It's been long enough that I don't remember).
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.
(edit: on the off chance anyone cares, I decided to check and it looks like this issue has been fixed as of pfSense CE 2.8.)
I've tried a few times to switch to Kea in PFsense but it crashes my network fiercely.
Is opnsense ahead for this then? Or same
I don't follow pfsense too much but my understanding is OPNsense typically brings in package updates faster as they have a more frequent update cycle. I can't speak too much to bugs as I haven't migrated to Kea but imo some core functionality wasn't there until recently. And Dnsmasq seems like a better fit for me anyway, which is where I'll migrate to.
From the 25.1.6 OPNsense May update notes:
> Last but not least: Kea DHCPv6 is here. And with it full DHCP and router advertisement support in Dnsmasq to bridge the gap for ISC users who do not need or want Kea. 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.
https://docs.opnsense.org/releases/CE_25.1.html#may-08-2025
I've been using it on opnsense since the first version it was released in. I aggressively switched because wanted to ditch my weird setup to do multi subnets (forwarding though a l3 switch). Haven't had any issues.
What is this? Kea 3.0 has been out for years already :D https://keajs.org/blog/kea-3.0
(I'm the author of a JS framework with the same name)
but is it LTS?
It's a "JS framework" - it's sorta forbidden to be LTS in JS world
Good news releasing the commercial extensions as open source too. It opens up new ways of automating operations.
Great to see the hook libraries being mostly open sourced!
I was quite ok with paying the $500 or so to license the features, but the friction to get that through procurement processes also ended up killing it.
Kea is perfect for integrating with zero touch provisioning automation processes.
Back then, I used ISC's DHCP server, but nowadays you have other options like AdGuard Home which includes a nice web UI that is simpler to manage than just a daemon implementation.