Kea implementation
-
@dennypage We'll need to clarify that. Hostnames in static leases aren't supported either currently.
-
I think you mean client IDs? Static mappings appear to resolve as expected. With host names.
-
As above, hostnames work without issue and the static/reservations seem to register correctly with DHCP.
I don't register DHCP leases in the DNS resolver, so that bit I have not tested with Kea.
️ -
I do and can confirm they don't work yet. Which is expected.
I didn't realise how much I was relying on that feature.
-
@stephenw10 Just to ensure I am not misunderstanding, what I am hearing is that configuration is currently expected to work with Kea. Is this correct?
-
Yes, that's correct.
It's trivial to switch back to ISC if you do hit some issue that's unworkable.
Steve
-
@stephenw10 Thank you Steve. Much appreciated.
-
After further digging it appears that static mappings from kea are not actually supported.
However if you switch from ISC to Kea existing mappings will still be resolvable as the hosts file still contains them. Any additional mappings added will not be though.
-
@stephenw10
Ok, that is a gotcha for now.️ -
@stephenw10 said in Kea implementation:
However if you switch from ISC to Kea existing mappings will still be resolvable as the hosts file still contains them. Any additional mappings added will not be though.
That kinda kills it for me. DHCP is the source of almost all hostname/ipaddr mapping for my network.
-
@dennypage
I hope it is an easy fix...️ -
It's not really a fix, it's more like adding a feature. Ultimately we should end up with something much better using Kea and Unbound that what we have currently. Something something dhcpleases....
I'm not sure when we will have that. The introduction of Kea in 23.09 is to find whatever issues will inevitably be present by exposing it to far more users. But that will probably require dhcp leases resolvable for many test long term.
Steve
-
@stephenw10 said in Kea implementation:
The introduction of Kea in 23.09 is to find whatever issues will inevitably be present by exposing it to far more users. But that will probably require dhcp leases resolvable for many test long term.
If that is the reason then in my opinion Kea should be labeled as "Experimental" in the UI and ISC should not be labled as "Deprecated". "Deprecated" means that the functionality is still present and is no longer supported. It doesn't mean we plan to get rid of it when its replacement is ready.
-
@jaltman said in Kea implementation:
"Deprecated" means that the functionality is still present and is no longer supported.
That is exactly what the situation is -- the ISC daemon is still present, but no longer supported (by ISC in this case).
It doesn't mean we plan to get rid of it when its replacement is ready.
Anything marked "deprecated" is eligible for eventual removal. Such things are not left in place indefinitely. There is no hard ETA on when ISC will be removed, however, just at some future time after Kea is feature complete.
So far FreeBSD hasn't marked the port deprecated or given it a removal date, so there isn't any upstream pressure there (yet) from FreeBSD, but it would be nice to only have to worry about the currently supported daemon (Kea) sooner rather than later.
-
@jimp I appreciate that ISC DHCP Server has reached EOL and as a result they do not expect to release any additional updates. I also understand from their announcement that ISC recommends that new users consider Kea DHCP over ISC DHCP.
My concern is that in the context of pfSense the integration of Kea DHCP is not yet complete. pfSense end users do not view ISC DHCP as a separate product or feature. My suggestion is that pfSense hold off on advertising ISC DHCP as deprecated until after the pfSense development team believes that the integration is feature complete and all of the transitional issues have been exposed. Once the pfSense integration is declared stable; then begin issuing "deprecation warnings" to push administrators to switch over.To assist in finding outstanding issues I suggest that any state which is generated by ISC DHCP or Kea DHCP be wiped when administrators switch between the two implementations. For example, any DNS entries created for static or temporary DHCP leases should be removed. Otherwise, if Kea DHCP doesn't support the generation of DNS entries the administrator won't discover there is a problem until the DHCP configuration changes. At that point chasing down why a DNS entry wasn't created or why a DNS entry for the wrong address exists will be quite painful.
Thanks for listening even if you disagree with my point of view.
-
G Gertjan referenced this topic on
