This is actually fairly big news. This will impact many consumer routers/firewalls and some Wifi access points that are using ISC's DHCPD. They appear to suggest an alternative that uses a RDBMS backend and implements API's. That will be an interesting migration for those that incorporate DHCP and DHCP network relays into Puppet, Chef, Ansible, Cobbler, etc... I've seen some fairly complex setups. I suppose that makes sense in a corporate/production environment but may be a bit overkill for small networks and network devices.
What alternatives [1] are others switching to? udhcpd? I believe some here already use dnsmasq. I want to say I've run into problems on some alternatives with some of the more obscure dhcp vendor options but it's been a while.
It was observed a long time ago that if you don't outcompete yourself, somebody else will. ISC has their own competitive replacement KEA (https://www.isc.org/kea/)
The linked repo is a protocol lib for dhcp written in Rust, internally we are working on a dhcp server but it is not open sourced at the moment. It is a ground up rewrite of dhcp, it does not share code with ISC DHCP.
I know this is not as elegant/clean as the ISC solution, but most servers should have some form of scripting capability like kea and dnsmasq. I can't talk about systemds or udhcpcds implementation, but dnsmasq can "solve" your problem, although clunky.
* You must first specify a dhcp optsfile that your script is able to modify.
* Create a hook either as script or lua and make it able to modify the optsfile.
* After successfully modifying the optsfile send a SIGHUP to the dnsmasq process and the optsfile will be reread.
Like I said this is not really feasible in larger networks (maybe it is I only use something like this for my cluster), but it kind of works and like I said there are many dhcp servers and many support scripting of some sort.
(edit) PS in the announcement it was said that security fixes will still be issued, but the code base is too old/large to modify safely. I doubt that the fork will add much to what the EOL code offers, but I can be wrong.
you say “… many DHCP server and many support scripting”. This is what Ive been searching for … for decades … on a replacement DHCP server … to little avail.
These wannabes have all fallen short and this will remain a problem for as long as many of those top-15 ISPs continues to use these esoteric settings of Juniper Network for their custom Network Management System (NMS) and in-house provisioning setups.
All of those Wannabe DHCP server replacements are an expensive proposition in terms of time, money, and resources.
Mostly likely, this will further solidify the deployment of ISPs’ in-house gateway boxes thus preventing any custom gateways from replacing them.
oh wait, I wonder how much ISC was paid … to do exactly this EOL … by these major ISPs?
Plausible future: I can envision a special DHCP vendor-specific OPTION to use time-based blockchain hash to further solidify their in-house gateway deployment hold.
Ok here is my followup. I didn't go into detail about kea hooks [0] because I didn't write any kea hook before, but from what I can tell it should cover all your needs. You have to write c code which I find absurd tbh, but if it has the functionality you are looking for it could be a solution.
I already posted my dnsmasq "solution" so I will skip this. If you want a code example I could whip you one up.
Then there is coredhcp [1] and you can write plugins written in go for it.
From time to time some hobby dhcp server pop up, but most fade away since (I guess) the existing solutions are "good enough". I for instance implement a automatic provisioning and configurating dhcp setup with tftp and pxe boot using dnsmasq. It automatically creates pxe configs based on the mac address and some other stuff (tm). Kea seemed overkill for this usecase and I'm quite happy with what I got.
Your use case of automatically fixing hostnames through ISC seems a bit overkill to me as well to be frank. My home network has a few VLANs and every device in it is managed manually. It's a one time setup and most automation is unnecessary (and some devices in my network flatout ignore some dhcp options....). Aaaaanyway I still think that most dhcp servers out there support some form of scripting (heck even udhcpcd has a lease notify script that could be hacked to offer some of that functionality even though this gets only executed after the fact so a bit useless [2]).
> oh wait, I wonder how much ISC was paid … to do exactly this EOL … by these major ISPs?
I don't know. Nothing?
> Plausible future: I can envision a special DHCP vendor-specific OPTION to use time-based blockchain hash to further solidify their hold.
Reading your cynic banter I'm quite happy of not having your DHCP problems. Looking through your github repositories I can find a bunch of configuration files for dhclient, but not much in form of ISC configs (only the nintendo fix you posted in your first post). Would be really interested in your setup.
FWIW, apparently the OpenBSD devs maintain their own fork of ISC's server, which is available at least on FreeBSD via ports/pkg. So if just want to keep using the good ole DHCP server you have grown used to while also receiving updates, you might want to look into that.
Kea has worked great for me, for quite a few years now. Few hundred various devices tops. I tried dnsmasq as well, but that caused anomalies I couldn't solve.
What alternatives [1] are others switching to? udhcpd? I believe some here already use dnsmasq. I want to say I've run into problems on some alternatives with some of the more obscure dhcp vendor options but it's been a while.
[1] - https://en.wikipedia.org/wiki/Comparison_of_DHCP_server_soft...