ISC DHCP Server has reached EOL | Hacker News Reader

ISC DHCP Server has reached EOL

isc.org

61 pointsapple4ever20 comments

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.

[1] - https://en.wikipedia.org/wiki/Comparison_of_DHCP_server_soft...

dnsmasq is great for reasonably small setups.

We’ve used it in quite large setups as well, works great. Though their documentation is far from ideal.

I was wondering what others are going with too. Kea looks interesting, but haven't looked hard at anything after running ISC for years.

The database server is optional, you can also use local csv files. A terrible format but it is just text.

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/)

At BlueCat we're looking at offering a DHCP replacement, here is the GitHub of where we're at:

https://github.com/bluecatengineering/dhcproto

Disclaimer: I work there. My own opinions.

How do they differ from OpenBSD fork of ISC DHCP?

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.

This will be a MAJOR problem when trying to incorporate the DHCP Vendor OPTION message fields … programmatically.

It is easily done in ISC DHCP but not available in systemd, udhcpcd, nor dnsmasq.

Looking at you ISPs who use Juniper Network concentrators and routers.

Also I use ISC DHCP to help compensate for Nintendo DS handhelds who have brokenly incorporated a space into its DHCP hostname.[2]

Now going to look at OpenBSD fork of ISC.[3]

2] https://github.com/egberts/isc-dhcp-server-nintendo

3] https://github.com/openbsd/src/blob/master/usr.sbin/dhcpd/dh...

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.

[0] https://kea.readthedocs.io/en/latest/arm/hooks.html

[1] https://github.com/coredhcp/coredhcp

[2] https://github.com/mirror/busybox/blob/master/examples/udhcp...

yeah, i am unable to post server-side config made under contracts. However, client-side is everchanging for my gateway that replaced my ISP gateway.

Good writeup. Great re-starting point after my 5-year hiatus.

Kea can replace forbidden characters in DHCP hostnames, maybe that solves the problem you're having.

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.

I've been using dnsmasq [1] instead of DHCPD, and it's been fairly easy for me (the built in TFTP server made PXE super easy)

Huh, ISC dhcpd is still on the go? Interesting!

Anyway this thing called "dnsmasq" has been around for about 20 years, you should take a look some time. It's pretty good.

Shame on me for not keeping up with this, has anyone transitioned off it already, and if so, what's your deployment like and what did you go with?

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.

Reply on news.ycombinator.com