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.
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.
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.
1 reply →
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.
4 replies →
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?