ISC DHCP server is EOL

Phishfry

Phishfry

Wow. I never thought I would see an established open source software go EOL.
What a strange decision.

ISC DHCP Server has reached EOL

What is changing? The 4.4.3-P1 and 4.1-ESV-R16-P2 versions of ISC DHCP, released on October 5, 2022, are the last maintenance versions of this software that ISC plans to publish.
www.isc.org www.isc.org

Thank Goodness for DNSMasq.

Dnsmasq - network services for small networks.

thekelleys.org.uk thekelleys.org.uk
 
Ran Kea v1.6 at work a while ago and it had a nasty bug in its db section that corrupted the database and it started giving out duplicate IP addresses. They did fix it later on but that was enough to switch to something else.
 
Datapanic said:
Ran Kea v1.6 at work a while ago and it had a nasty bug in its db section that corrupted the database and it started giving out duplicate IP addresses. They did fix it later on but that was enough to switch to something else.
Click to expand...
What exactly did u chose ?
 
It's nice to see the link to the alternatives. Anyone else noticed it has "yes" in the BSD column for every alternative?

Comparison of DHCP server software - Wikipedia

en.wikipedia.org en.wikipedia.org

Unfortunately many of them don't appear to have a port for it.
dhcpy6d - no port?
dibbler - no port?
dnsmasq - dns/dnsmasq
ISC DHCP - net/isc-dhcp44-server
FreeRADIUS - net/freeradius3 I'm not sure if this version actually has DHCP support
Jagornet DHCP - no port?
Kea DHCP - net/kea
udhcpd - no port?
WIDE-DHCPv6 - net/dhcp6

I also found these, that aren't mentioned in the 'alternatives' list:
net/dhcpcd
net/dhcpd

There might be a few other ports I missed.
 
I don't like Dnsmasq, because it's not compliant with the UNIX philosophy: do one job only, and do that well!

Aside being a DHCP server it is also a DNS server/forwarder, and that's something which should be definitely not part of a DHCP server.
 
hardworkingnewbie said:
Aside being a DHCP server it is also a DNS server/forwarder, and that's something which should be definitely not part of a DHCP server.
Click to expand...
Maybe, maybe not. Many people (including myself) have their DHCP and DNS linked (so resolving actually works for dynamic hosts). So it certainly makes sense to combine them in this case. The combination RADIUS and DHCP doesn't make sense to me though but I'm sure there's a use-case for that too (ISP/Hosting perhaps?).
 
SirDice said:
I also found these, that aren't mentioned in the 'alternatives' list:
net/dhcpcd
Click to expand...
This is a DHCP client only (Dynamic Host Configuration Protocol Client Daemon). I know it well from my days using Gentoo. Another great project from former Gentoo (now Netbsd) dev Roy Marples (Uberlord).
SirDice said:
net/dhcpd
Click to expand...
This is a port of the Openbsd DHCP daemon. It appears to be a fork of ISC-DHCPD. It unfortunately does not appear to do failover or load balancing, but does support Bootp.
SirDice said:
The combination RADIUS and DHCP doesn't make sense to me though but I'm sure there's a use-case for that too (ISP/Hosting perhaps?).
Click to expand...
I think you need Radius for 801.2X authentication, which you might want to perform before you hand out an IP address.

hardworkingnewbie said:
I don't like Dnsmasq, because it's not compliant with the UNIX philosophy: do one job only, and do that well!
Click to expand...
Unfortunately Freeradius does not do Bootp. I'm going to need a combo of Freeradius and something that does support that. Maybe Openbsd dhcpd.
 
Jose said:
I think you need Radius for 801.2X authentication, which you might want to perform before you hand out an IP address.
Click to expand...
Right, completely forgot about 801.2x. Haven't actually dealt with that in any of my contracting jobs.

I think I'm going to give net/kea a go. Don't need HA or fail-over on my home network, or use a database. I'm hoping it links to BIND in the same way as ISC DHCPd did. I really don't want to switch BIND to something else too.
 
Alain De Vos said:
We have an end. Why shouldn't software.
Click to expand...
This may be true in a Windows dominated world but I don't need constant software upgrading.
Make a product and polish until great. Then put in maintenance mode.
Don't try and add the kitchen sink with fireworks.

dnsmasq and isc dhcpd both had nearly identical have similar configuration syntax.
That is groovy.
 
I installed Kea on one of my home network servers a year ago and today, I went ahead and switched over my isc-dhcpd setup to Kea. Kea is actually pretty nice and integrates with isc-bind and mysql server with no problems. The configuration takes some time. It also can integrate with Stork for a Bind and Kea Dashboard but it has problems with FreeBSD.
 
I took a look at Kea some time ago as an alternative to the aging isc-dhcpd, unfortunately my personal experience with it was a rather unpleasant one. Building Kea from source took ages compared to isc-dhcpd, the configuration file uses JSON and did not even allow for comments which makes it rather error prone and hard to maintain. Also running Kea, even in a rather minimal setup, seemed to be quite resource hungry in comparison to isc-dhcpd. I also remember that there were some features I use with isc-dhpd that could not (at that time) be (easily) done with Kea, but don't remember the specifics. Back then I decided not to go down the Kea road, but with isc-dhcpd going EOL that might not leave much of a choice.

As for some of the alternatives, I agree that having one software do one job right is the logical choice, even if there might be use cases where such combined solutions might make some sense.
 
I have been running ISC dhcpd and I want to cut over to "kea" on my next server swap. I'm finding it very painful. One gotcha that I've been fortunate enough to avoid by a random search hit is that you CANNOT specify the interface to listen to on the command line, it has to go in the JSON config file. There's some question of whether I need it at all or whether it can infer it from the subnet declaration, which would be totally cool. You could use FQDN in dhcpd, but you need the actual MAC address for kea, but that is one thing that the migration tool is really nice for. My current problem, however, is the "dhcp-client-identifier" conversion. Has anyone found a way for kea to handle this? The kea migration tool does not consider this option an error, but it interprets it totally wrong and simple specifies the host name as a string of hexadecimal digits, which has no value that I can see. Also - is there like a GIT hub forum for this thing? Or something on ISC's web site? I'm not that interested in getting a subscription for my 6-server network...
 
Steinhelten said:
I have been running ISC dhcpd and I want to cut over to "kea" on my next server swap. I'm finding it very painful. One gotcha that I've been fortunate enough to avoid by a random search hit is that you CANNOT specify the interface to listen to on the command line, it has to go in the JSON config file. There's some question of whether I need it at all or whether it can infer it from the subnet declaration, which would be totally cool. You could use FQDN in dhcpd, but you need the actual MAC address for kea, but that is one thing that the migration tool is really nice for. My current problem, however, is the "dhcp-client-identifier" conversion. Has anyone found a way for kea to handle this? The kea migration tool does not consider this option an error, but it interprets it totally wrong and simple specifies the host name as a string of hexadecimal digits, which has no value that I can see. Also - is there like a GIT hub forum for this thing? Or something on ISC's web site? I'm not that interested in getting a subscription for my 6-server network...
Click to expand...
I switched to kea for IPv4 in December 2024. So far it seems to be running fine on my home network with 10 VLANs. Yes, it took some doing and I initially did all my experimenting in a Windows-hosted, VirtualBox VM running FreeBSD v14.2. Yes, the listen interface(s) are specified in the JSON config file; each VLAN having its own interface (igb1, igb1.10, igb1.20, etc). I prefer to declare most everything rather than letting kea try to infer anything.

I only invoke MAC addresses in the JSON config file when setting up reservations. You should still define a FQDN in kea so the dhclient program can grab it for the resolvconf program to write out the /etc/resolv.conf file.

You are using some terms I'm not familiar with, such as "6-server network..." - do you mean an IPv6 network? I'm still working on kea for IPv6 stateful dhcp - slow going due to issues my Windows desktop has with doing DNS lookups (defaults to trying IPv6 first). Not sure what this means, "dhcp-client-identifier".

I used the kea migration tool to get an idea of what kea wants to see in the JSON config file, then after reading and rereading the kea documentation through the month of November and starting/restarting kea while watching the various logfiles was able to get rid of all the errors. I found the lease file migration tool to be fairly useless. The migration tool for IPv6 configuration was completely worthless.

The kea documentation is worlds better than is the documentation for isc-dhcpd. I don't have a subscription for kea.

Found one Youtube video done by one of the kea team members. It had a little useful info in it (by then I'd read the kea documentation several times.) Found a number of blogs about kea, most with non-helpful info and some with frankly wrong info.

Oh, I should add that my primary reason for switching to kea was because of the vastly superior handling of the lease files. My isc-dhcpd lease files were pushing 50k in size (running many years) and kea's "lease file cleanup" routine is wonderful.

HTH.
 
Sorry to be confusing. By "6-server network" I only meant to give a feeling for the size of the very small operation I am managing. I am only using IPv4 so far, except that my CenturyLink uplink as an IPv6 but I never use it.

Perhaps I am blaming kea for problems that are really only in the keama program. The keama program changed all of my FQDNs to fixed IP addresses with the FQDNs and in the options the FQDNs appear as comments and simply disappear in MAC-based ("hardware ethernet"/hw-address) reservations. Here's an option:
Code: 
option time-servers tid.starfire.mn.org;
became
JSON: 
      {
        "space": "dhcp4",
        "name": "time-servers",
        "code": 4,
//      "original-data": "tid.starfire.mn.org",
        "data": "192.168.1.1"
      },

Here's a reservation:
Code: 
host fawkes { fixed-address fawkes.starfire.mn.org;
        hardware ethernet 00:13:20:93:dd:55;
        }
became
JSON: 
      {
        "hostname": "fawkes",
        "ip-address": "192.168.1.54",
        "hw-address": "00:13:20:93:dd:55"
      },

The thing that's really driving me bats, though, are the reservations that relied on dhcp-client-id instead of "hardware ethernet". Such a reservation changed from
Code: 
host twister {
        fixed-address twister.starfire.mn.org;
        option dhcp-client-identifier "twister";
        }
to this
JSON: 
      {
        "hostname": "twister",
        "ip-address": "192.168.1.51",
        "option-data": [
          {
            "space": "dhcp4",
            "name": "dhcp-client-identifier",
            "code": 61,
//          "original-data": "\"twister\"",
            "csv-format": false,
            "data": "74776973746572"
          }
        ]
      },
(Note that the "data" is a series of hex bytes that are the same as the "original data"
I have NO confidence that this has done what I think I want it to do, which is to identify what IP address to assign to a system based on the system identifying itself rather than using any particular MAC address.

Where did you start with the kea documentation? I have found a lot of information, but it's not clear to me where I want to start this reading project.
 
Steinhelten said:
Where did you start with the kea documentation? I have found a lot of information, but it's not clear to me where I want to start this reading project.
Click to expand...
Well I think that your understanding of the isc-dhcp-server program far-and-wide exceeds mine. I don't recognize most of those incantations. :(

I started reading the kea documentation from page one and went straight through, several times. Started here: https://kea.readthedocs.io/en/latest/ Once I was convinced I understood the basic structure I found this bit of documentation helpful: https://kb.isc.org/docs/kea-configuration-for-small-office-or-home-use I liked this brief Youtube presentation by one of the kea documentarians:
View: https://www.youtube.com/watch?v=AIbh5IcQfXo


I found the keama program only useful insofar as the output showed me what the general structure of the JSON config file should look like. While reading the documentation I made sure to take notes about items I specifically wanted to include in my final configuration. It took me many starts-stops of kea while watching what the various log files complained about before I got it straightened out. Sometimes a Google search was required to see if someone else had solved a particular problem or desire that I wanted. I also learned a lot about how dhcp servers in general work and what dhclients are seeking when they are first started. For example, I found out that trying to run two dhcp servers on the same subnet at the same time didn't give the results I was expecting.

I'm a hobbyist so not pressed for time to get anything done but wanted to be reasonably sure that the finished product on my test platform could be transferred to my live, production server environment without bringing me down. Fortunately I was rewarded with it working directly and consistently since December 19. I've been tweaking some of the lease time options since then.

In short I'm glad I made the switch to kea despite it taking quite some time and effort. I think you'll be glad you did as well.
 
I played with kea for two evenings, about a year ago. I found the configuration file awful. After that I decided that I will stick to ISC-DHCPD until the wheels fall off it. Then I'll either try to move to Kea again (like many problems, the configuration file might be soluble in alcohol), or try to find another solution.
 
ralphbsz said:
... (like many problems, the configuration file might be soluble in alcohol) ...
Click to expand...
configuration by 2-4 (i.e. flat of beer) or 26oz - user discretion is advised.

Coming to this party really late, it appears. Totally missed the EOL announcement from 2022.

Ugly that open source gets abandoned because of "market share". That's not why stuff was written decades ago. It was done to "scratch an itch". We've forgotten that with time.

Power users may think Kea is "cat's meow", but us mere mortal-home users need something "that just works". SirDice has pointed to options in ports/pkgs. And the reading goes on...
 
You must log in or register to reply here.
Back
Top