[HN Gopher] Kea 3.0, our first LTS version
___________________________________________________________________
Kea 3.0, our first LTS version
Author : conductor
Score : 112 points
Date : 2025-06-26 20:26 UTC (1 days ago)
(HTM) web link (www.isc.org)
(TXT) w3m dump (www.isc.org)
| dgfitz wrote:
| I'll google it in a moment, but skimming those notes, I have no
| idea what Kea is.
| lousken wrote:
| DHCP server?
| digitalPhonix wrote:
| A DHCP server for those who are wondering
| CBLT wrote:
| 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.
| a_e_k wrote:
| 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.)
| gertrunde wrote:
| 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).
| bc569a80a344f9c wrote:
| 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.
| vlowther wrote:
| 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.
| somerandomqaguy wrote:
| Next gen reference DHCP server. IIRC it's new thing is IPv6
| support.
| Sesse__ wrote:
| 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.
| bravetraveler wrote:
| Won't take long, ISC doesn't do 'much' but they do it well
| kjellsbells wrote:
| I remember Dan Bernstein (djb) being scathing about BIND. To
| the extent of writing his own DNS suite. Is that all ancient
| history now?
| bravetraveler wrote:
| 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
| simtel20 wrote:
| 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.
| JdeBP wrote:
| 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 daemons,
| 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#run
| nin...
|
| 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 daemons. 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 daemons, 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.
| Sesse__ wrote:
| > 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?).
| tremon wrote:
| 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 .
| JdeBP wrote:
| 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. (-:
| tok1 wrote:
| > 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).
| bpbp-mango wrote:
| they certainly made some memorable CVEs well
| throw0101c wrote:
| ISC DHCPd is (being) EOLed.
|
| Kea is ISC's new DHCP server.
| JdeBP wrote:
| 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/
| kayson wrote:
| 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
| v5v3 wrote:
| Is opnsense ahead for this then? Or same
| mortos wrote:
| 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
| seany wrote:
| 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.
| Helmut10001 wrote:
| 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.
| sjm-lbm wrote:
| 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.)
| latchkey wrote:
| 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.
| kaladin-jasnah wrote:
| 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?
| latchkey wrote:
| We used them for mining ethereum, but no longer.
|
| There is a good fairly easily discovered discord out there
| for enthusiasts.
| a012 wrote:
| Can one run mainline Linux on these boards?
| voxadam wrote:
| _Information on running the AMD BC-250 powered ASRock mining
| boards as a desktop_
|
| https://github.com/mothenjoyer69/bc250-documentation
| latchkey wrote:
| We ran Linux (Ubuntu) on them, PXE booted with a minimal
| image.
| ExoticPearTree wrote:
| Good news releasing the commercial extensions as open source too.
| It opens up new ways of automating operations.
| kraftomatic wrote:
| 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.
| rapnie wrote:
| 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".
| joh6nn wrote:
| 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"
| cmeacham98 wrote:
| The HN guidelines state to use the original title "unless it
| is misleading or clickbait", which is why this happens.
| righthand wrote:
| 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.
| hu3 wrote:
| > Copy paste that phrase on every piece of content to save
| you a click?
|
| Yes please.
| mariusandra wrote:
| 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)
| fuziontech wrote:
| but is it LTS?
___________________________________________________________________
(page generated 2025-06-27 23:01 UTC)