puzzled by the ISC/KEA DHCP direction

[tessus]

In the release notes for 24.7, I found this:

ISC DHCP will no longer reload DNS services on static mapping edits. This is for feature parity with Kea DHCP and avoiding cross-service complications. If you expect your static mappings to show up in a DNS service please restart it manually.

I am a bit puzzled as to how the DHCP system is handled. The only feature that was missing for ISC DHCP to assign/remove static mappings via an API. (It's important when using Terraform and Ansible to deploy VMs.)

Then KEA came along with half of the features of ISC missing and without an upgrade path. I have at least 50 static mappings that I would have to manually enter in KEA, so this makes a migration not a happy one. Especially if you need features in ISC that are no available im KEA.

The fact that a reload is done when applying changes to static mappings is a basic feature. This should not be removed from ISC but added to KEA.

I wrote this post, because I do not understand the direction of development. It makes no sense to me.

DHCP is a crucial component of a Firewall/Router and it seems to me that not only the replacement is worse when it comes to features and usability, the "old" system is now made worse to be as bad as KEA.
Can someone please explain the logic of this?

[doktornotor]

As discussed at https://forum.opnsense.org/index.php?topic=40899.0 - there is no integration available in ISC DHCP / Kea and Unbound for this (unlike e.g. dnsmasq which can be used as DNS and DHCP server, though not in OPNsense; or Active Directory with secure DNS updates). The things implemented are just hacks.

ISC DHCP is abandoned upstream.

[tessus]

> there is no integration available in ISC DHCP / Kea and Unbound for this

What are you referring to? I was talking about multiple things. The discussion you referenced does not apply to any of them. Or at least I don't see the connection.

[doktornotor]

I am referring to this:

The fact that a reload is done when applying changes to static mappings is a basic feature. This should not be removed from ISC but added to KEA.

Kea is a DHCP server. It does NOT handle any DNS registration and integration. Neither does ISC. I'd hazard to guess that OPNsense developers are not willing to waste time inserting more glue such as "if Kea is in use, do not reload Unbound because nothing changed there regarding DNS when some (static) leases got configured, only do it for ISC. And perhaps when switching the implementations from ISC to Kea but not the other way round... and... perhaps in this case also. And not in this one."

As for the rest - ISC is EOL-ed upstream. You need to start somewhere when replacing it. The functionality in that's currently there is more than enough for majority of uses and simple use cases. If you need something else, well, perhaps you should use something else as your DNS server. In corporate environment, you'd run the AD-integrated DNS normally, nor Unbound as your authoritative DNS for your LAN domains.

Additionally - noone is forcing you to migrate anything right now. 🤷‍♂️

[Patrick M. Hausen]

Kea is a DHCP server. It does NOT handle any DNS registration and integration. Neither does ISC.

But ISC does via RFC 2136 dynamic updates. If only someone would implement that ... too late, now.

Maybe some time in the future. It needs the matching feature on the DNS server side, of course. I don't know if that is present in Unbound. It definitely is in BIND.

[doktornotor]

Maybe some time in the future. It needs the matching feature on the DNS server side, of course. I don't know if that is present in Unbound. It definitely is in BIND.

It does not exist in Unbound and is explicitly something out of the scope of its development.

RFC 1995, 1996, 2136: not authoritative, so no AXFR, IXFR, NOTIFY or dynamic update services are appropriate.

https://github.com/NLnetLabs/unbound/blob/master/doc/FEATURES

[tessus]

I do understand that KEA is a bare DHCP server.

However, when I use an ASUS router or a fritzbox (or any router out there) and use the DHCP, the hostnames are registered and thus reachable via its DNS. I think I should be able to hope for the same functionality in OPNsense.

I seriously do not want to setup my own DHCP/DNS in my home network when it was working fine until now with ISC DHCP and unbound.

[kozistan]

what about kea-dhcp-ddns? Based on kea docs they have solution for this to be done.

https://kea.readthedocs.io/en/kea-2.4.0/arm/ddns.html

I'm running samba-ad-dc with bind9 dlz backend integration and need in production authoritative dns updates of kea dhcp leases.

[kozistan]

Just wanted to add that I completely understand your intention, I started exploring KEA on Debian today and the result so far is that it is buggy and unstable. I have no concerns that it will be replaced in the production version anytime soon.

[tessus]

I still would appreciate if a dev could chime in. Am I so off base, asking for a feature that every router out there has?
The issue is that I remember that a dev mentioned that KEA might never reach feature parity with ISC.

I don't need this now. What I would kindly ask though is that before ISC is removed from OPNsense, a true replacement is available and working. And I do include registering DHCP hostnames in the DNS subsystem in this conversation.

[GreenMatter]

 I'm puzzled too - I don't understand implementing KEA when it doesn't match functionalities in ISC. Issues in 24.7 with OpenVPN UDP server (at least in my case) plus removing functionality in ISC dhcp in 24.7 made me reverting upgrade back. to version 24.1.10...

[doktornotor]

I'm puzzled too - I don't understand implementing KEA when it doesn't match functionalities in ISC.

https://www.isc.org/blogs/isc-dhcp-eol/

[julsssark]

Being an open-source developer is truly a labor of love. If KEA was implemented in a big-bang a year from now, people would complain that it was taking too long. If KEA is implemented in phases, then people complain that it is not feature complete.

I trust the OPNsense devs to make the right calls. I doubt ISC is going to be removed until KEA is at or near feature parity. In the meantime, keep using ISC until KEA has the features you need. I switched over to KEA this week and it is working without problems.

[Patrick M. Hausen]

@julsssark I could not agree more.

But for the sake of proper terminology: it is not KEA that is lacking features compared with ISC-DCHPd, it is the integration of KEA into OPNsense which is not yet feature complete.

Both ISC-DHCPd and KEA are third party products. If there really are features entirely lacking in KEA we could complain and argue on the forum all we want, nothing would be going to change. The feature set of KEA is decided by a semi-open source (they have paid closed source modules if I am not mistaken) project entirely independent from OPNsense.

Kind regards,
Patrick

[julsssark]

Thanks Patrick for clarifying my comment. That is what I intended.