8 ms·

ISC DHCP Server has reached EOL

61 points by apple4ever 4y ago

LinuxBender 4y ago
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_software https://en.wikipedia.org/wiki/Comparison_of_DHCP_server_soft...
- uselpa 4y ago
  dnsmasq is great for reasonably small setups.
  - allarm 4y ago
    We’ve used it in quite large setups as well, works great. Though their documentation is far from ideal.
- apple4ever 4y ago
  I was wondering what others are going with too. Kea looks interesting, but haven't looked hard at anything after running ISC for years.
- tinus_hn 4y ago
  The database server is optional, you can also use local csv files. A terrible format but it is just text.
ckdarby 4y ago
At BlueCat we're looking at offering a DHCP replacement, here is the GitHub of where we're at: https://github.com/bluecatengineering/dhcproto https://github.com/bluecatengineering/dhcproto Disclaimer: I work there. My own opinions.
- egberts1 4y ago
  How do they differ from OpenBSD fork of ISC DHCP?
  - leshow 4y ago
    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.
m3047 4y ago
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/ https://www.isc.org/kea/)
vfclists 4y ago
krylon 4y ago
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.
nigma1337 4y ago
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)
egberts1 4y ago
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 https://github.com/egberts/isc-dhcp-server-nintendo 3] https://github.com/openbsd/src/blob/master/usr.sbin/dhcpd/dhcpd.c https://github.com/openbsd/src/blob/master/usr.sbin/dhcpd/dh...
- BlackLotus89 4y ago
  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.
  - egberts1 4y ago
    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.
4oo4 4y ago
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?
- Avamander 4y ago
  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.
Gordonjcp 4y ago
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.

61 points by apple4ever 4y ago

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_software https://en.wikipedia.org/wiki/Comparison_of_DHCP_server_soft...

uselpa 4y ago
dnsmasq is great for reasonably small setups.
- allarm 4y ago
  We’ve used it in quite large setups as well, works great. Though their documentation is far from ideal.
apple4ever 4y ago
I was wondering what others are going with too. Kea looks interesting, but haven't looked hard at anything after running ISC for years.
tinus_hn 4y ago
The database server is optional, you can also use local csv files. A terrible format but it is just text.

ckdarby 4y ago

At BlueCat we're looking at offering a DHCP replacement, here is the GitHub of where we're at: https://github.com/bluecatengineering/dhcproto https://github.com/bluecatengineering/dhcproto Disclaimer: I work there. My own opinions.

egberts1 4y ago
How do they differ from OpenBSD fork of ISC DHCP?
- leshow 4y ago
  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.

m3047 4y ago

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/ https://www.isc.org/kea/)

vfclists 4y ago

krylon 4y ago

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.

nigma1337 4y ago

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)

egberts1 4y ago

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 https://github.com/egberts/isc-dhcp-server-nintendo 3] https://github.com/openbsd/src/blob/master/usr.sbin/dhcpd/dhcpd.c https://github.com/openbsd/src/blob/master/usr.sbin/dhcpd/dh...

BlackLotus89 4y ago
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.
- egberts1 4y ago
  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.

4oo4 4y ago

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?

Avamander 4y ago
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.

Gordonjcp 4y ago

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.