KEA DHCP - lacking features

[maverickws]

Thank you all for your replies.

Ok will be looking forward for the final product and stick to ISC for now, but notice there's deprecation warnings everywhere suggesting people to migrate, it makes one believe it is already a matured implementation. Cheers

[RobbieTT]

@maverickws

Well we may question veracity of the warnings but they did provide a check-box to disable it.

️

[maverickws]

@RobbieTT well yeah, I mean if it still needs so much polishing, and that's fine, just don't push the warnings like that just yet. Announce it some other way, have the January release put the warnings (if hopefully the implementation is more advanced).
That'd be a strategy I'd understand.

[RobbieTT]

@maverickws - Yep.

[jimp]

There is a bit of confusion above. Static mappings/"reservations" in Kea work. It's the DNS resolution/integration that does not work yet.

And yes there are several missing features yet but bear in mind a significant portion of users don't use all of the available features. Most just use the basic functionality.

[RobbieTT]

@jimp

No real confusion, just an absence of formal documentation. Other than the release notes I have not seen anything substantive on the subject. There is nothing in the pfSense online documentation and there is no mention of Kea under DHCP. If there was a white-paper / technical paper on the subject I have yet to find it.

The only concern I was aware of in the dev/beta stage was the inclusion of a warning banner encouraging a switch away from ISC. As the release notes for v23.09 make clear, Kea on pfSense is only in 'Feature Preview' Stage and gaps are expected.

As we stand, there is a GUI warning about continuing to use ISC and a warning in the release notes about using Kea. I'm not sure having a warning in place for both ISC and Kea is appropriate in production software.

️

[jimp]

The docs don't mention Kea because the goal is eventually to have feature and UI parity and having to keep all the docs updated as things are addressed would be quite a lot more work that would just be undone in a couple months. Once it's complete there won't be many differences in the UI between ISC/Kea.

The warnings are both accurate. ISC is EOL and people should consider switching. The features needed for the bulk of users are there and work and many if not most users could switch and barely notice a difference in behavior. However, since it isn't feature complete, the warning about that in the release notes/blog/etc is necessary and accurate.

The users who post on the forum/social media in general tend to be more advanced and sure they may want/need some features that aren't there yet, but you have to remember they are not necessarily representative of the hundreds of thousands of other users.

[RobbieTT]

@jimp said in KEA DHCP - lacking features:

ISC is EOL and people should consider switching. The features needed for the bulk of users are there and work and many if not most users could switch and barely notice a difference in behavior.

Thanks Jim and a 'note' in the GUI that reflected the above quote is close to ideal. To avoid startling any non-technical folk you could soften it further by stating that "ISC remains fully supported but is nearing EOL and...".

I can testify that it is indeed remarkably easy and painless to switch between the two; something I commented positively on during the dev stage.

️

[michmoor]

@jimp said in KEA DHCP - lacking features:

The users who post on the forum/social media in general tend to be more advanced and sure they may want/need some features that aren't there yet, but you have to remember they are not necessarily representative of the hundreds of thousands of other users.

This is a fair point.
Follow up - Do we need to wait for 24.03 to get the feature complete Kea or can it be delivered in an update prior?

[jimp]

@michmoor said in KEA DHCP - lacking features:

Follow up - Do we need to wait for 24.03 to get the feature complete Kea or can it be delivered in an update prior?

Most likely it will take enough time to implement that it will be close to the release before it's ready anyhow, but if it's ready before then, we are considering different methods of distribution (e.g. as a system patches update if possible). Though it will likely require additional binaries/daemons to manage the DNS API integration which would limit the viable methods. But we're keeping our options open for the moment.

[JonathanLee]

@maverickws said in KEA DHCP - lacking features:

DHCP option 26.
Also . . .

Option 252 WPAD
Option 42 NTP
Option 3 Gateway
Option 6 DNS

[mcury]

@JonathanLee said in KEA DHCP - lacking features:

@maverickws said in KEA DHCP - lacking features:

DHCP option 26.
Also . . .

Option 252 WPAD
Option 42 NTP
Option 3 Gateway
Option 6 DNS

I only use DHCP 43, I use it to adopt Unifi switch Mini to Unifi controller, but since it is already adopted, I don't need it anymore, so I'm already testing KEA and so far, so good..

[maverickws]

I guess we'll end up realising that there are more users using "advanced" options that initially thought.

[RobbieTT]

Option 6 was the first one I noticed. Missing Option 42 was ok as everything I currently have points to an internal IP address.

️

[JonathanLee]

@RobbieTT do you also use 252 for wpad?

[maverickws]

@RobbieTT have to ask, why manually adding option 6 instead of using the section under DHCP Server:
Server Options > DNS Servers ?

I actually only use this when using high availability in order to put the VIP address there, but works fine tho.

[RobbieTT]

@JonathanLee said in KEA DHCP - lacking features:

@RobbieTT do you also use 252 for wpad?

Not currently, at least not on my home network. I don't think I have anything looking for wpad.

@maverickws said in KEA DHCP - lacking features:

@RobbieTT have to ask, why manually adding option 6 instead of using the section under DHCP Server:
Server Options > DNS Servers ?

I'm not sure I understand you?

️

[maverickws]

@RobbieTT when you configure the DHCP Service you go to

Services (Top Menu) > DHCP Server
Then you get the different interfaces where you're able to activate (enable) the DHCP Server service, correct?

When in here, you have a few configuration blocks:

"General DHCP Options"
"Primary Address Pool"
"Server Options"
"Other DHCP Options" (where we'd configure the extra DHCP options)

The "Server Options" block here already asks for DNS Servers, which correspond to DHCP option 6.

So, on normal operation I leave this blank and let the interface address be the DNS server (as I'm using unbound resolver, so the firewall is the DNS server).
On situations where HA is enabled, I put the shared virtual IP here.
So my question is, why adding manually option 6 with the DNS servers, instead of using the DNS Servers fields under "Server Options". Like could be a specific case and I was curious.

[RobbieTT]

@maverickws

Still confused on your distinctions.

I leave Services/DHCP Server/LAN/Server Options/DNS Servers on the default setting (ie interface address).

What gets pushed out to clients is this option (plus the IPv6 equivalent and Search Domains aka option 119, suitably redacted):

With Kea, the options do not seem to go out (6, 119, whatever) so from the client end you end up with this:

This is less than ideal.

️

[maverickws]

@RobbieTT Ok so this machine is still on Monterey but the same gist.

This is my pfSense config here at home with KEA currently going. But this section "Server Options" is exactly the same for ISC or KEA.

The default option is greyed out because I'm not entering anything manually.

So it will provide the clients with a DNS Server - pfSense itself - and passes the interface address, both IPv4 and IPv6:

My question again is trying to understand why to use (in ISC) a custom option "6" to pass the DNS servers, if you already have a GUI section for that?