Comparison of DHCP service options

[kbreit]

Like many of you, I use DHCP on my OPNsense. Due to "it's what I've always done" I'm using ISC DHCP. However, Kea DHCP and DNSMasq DHCP are both options. Are there any comparisons between the three and when I would want to use them with OPNSense?

[meyergru]

The story is quite short:

ISC DHCP is at the end of its lifetime and will eventually get pushed to plugins section. This means it will not be so well supported any more - well, it isn't by ISC, either. Yet, there is no rush to end using it, but if you just start out, you should consider the alternatives.

Kea DHCP is the strategic replacement product from ISC, but feature-wise, it is not quite up to par with ISC. Also, not everything that Kea offers is supported by the OpnSense GUI (at least when I looked at it the other day).

Deciso has decided to add DNSmasq as an easy alternative. It is quite fresh (first release of the DHCP-relevant parts was just in some of the last updates), so not all features worked as expected, but today's release 25.1.7 adds many bugfixes and additions to what was missing.

The documentation now has a big section on how to use it. Its charm is that it addresses DHCP, DNS and RA in one product. The only thing missing is a DNS resolver and DoT / DoH, but that can easily be added by an upstream DNS service, as is depicted in the docs.

[qarkhs]

@kbreit
Like you I'm still on ISC DHCP. When Kea appeared as an option I was going to switch but decided to wait. Now I think my switch will be to DNSmasq, as that is now what is recommended for my type of small, simple setup. Up to this point, at least, I have no regrets waiting for the various alternatives to appear and cook a little within OPNsense. As Meyergru says, "there is no rush". But at some point, maybe soon, maybe when it becomes a plug-in, it's going to make more sense to switch than stick with ISC.

[kbreit]

Thanks for the information. I'll need to compare manually but I'm assuming either DNSmasq or Kea will have the features I need. Are there steps for how to do the migration in a seamless manner? I'm thinking it's something like...

1. Download static leases (or manually record them)
2. Import or manually enter them into the new DHCP server
4. Migrate any other settings
3. Turn off the old DHCP server and enable the new one

[meyergru]

Since the configuration differs a lot between these servers, it has to be carried out manually.
The tedious part is mostly to carry over the reservations, esp. if you have many of them.

This may help in doing the latter:

https://github.com/meyergru/iscdhcp_to_kea
https://github.com/meyergru/iscdhcp_to_dnsmasq

[kbreit]

I did notice Kea seems to lack the ability to do two things (which are probably the same thing):

- Custom DHCP options
- Set a DNS server

Am I missing a setting in the UI?

[passeri]

I switched from ISC to Kea. Unbound listens on all ports and I have a redirection rule for DNS. Kea is not involved.

[kbreit]

I switched from ISC to Kea. Unbound listens on all ports and I have a redirection rule for DNS. Kea is not involved.

I agree Kea isn't normally involved in DHCP. But how does a DHCP client know where to send DNS requests to?

[Patrick M. Hausen]

Services > Kea DHCP > Kea DHCPv4 > Subnets > edit a subnet and either

- check "auto collect option data" --> interface IP of OPNsense will be sent as gateway and DNS server or
- uncheck it, manually enter settings

[marjohn56]

I switched to KEA IPv4 when it first became available and have waited on IPv6 to be added, that's now available too. The reason I'm going with KEA is Prefix Delegation, that is the only reason. Most of my devices have reservations, so I do not really need the ability to add dynamics to Unbound, though there is a modified unbound_watcher.py out there that does appear to work, maybe something like that may be added in the future. However, as I said I run a test router down stream from the primary and need to be able to delegate a v6 prefix to that.

[miken32]

I did notice Kea seems to lack the ability to do two things (which are probably the same thing):

- Custom DHCP options
- Set a DNS server

Am I missing a setting in the UI?

We are stuck on ISC until the Kea interface supports multiple arbitrary DHCP options. I looked at doing a PR to add this but the config syntax for Kea is very byzantine.

[Patrick M. Hausen]

Which options exactly do you need?

[meyergru]

At least for the DNS server, you can uncheck "Auto collect option data" and then set it.

I am with Patrick here: As for "arbitrary DHCP options", the way it is done in DNSmasq now, is complete, but confusing. Actually, it were better if specific options were explicitely offered in the GUI than to just list all of them and let the user fill in the blanks. As an example as to why:

This was much easier in ISC DHCP, because often-used options like these (and some more) were summarized nicely on one page per interface. Maybe tabs for each interface would be a nice addition. It is also easier to have strong types for the most-often fields. As an example, consider the IPv6 DNSSL feature of RADVD (domain-search (24)), which should give DNS search domains in this syntax as seen with radvdump:

    DNSSL lan iot guest dmz
    {
            AdvDNSSLLifetime 86400;
    }; # End of DNSSL definition

where the original GUI input was "lan;iot;guest;dmz" and which is correct for the "domain-search (119)" option for DHCPv4.
You have to specifiy "lan;iot;guest;dmz" for IPv4 but "lan iot guest dmz" for IPv6, or else you will end up with:

    DNSSL lan;iot;guest;dmz
    {
            AdvDNSSLLifetime 86400;
    }; # End of DNSSL definition

ISC DHCP and RADVD did this automagically by using "lan;iot;guest;dmz" in the GUI only in one input field.

Other options are problematic because of type, e.g. the Unifi option (43). It should be specified as a hex string with colons, but if you accidentally use quotes around that, it will get interpreted as string and fail to work. Thus, it was better if the specific Unifi option was present in the GUI with an IP and the real configuration was then adapted to prevent such user errors.