Kea DHCP Feature Roadmap

johnpoz

@cmcdonald that is sweet, and long time in the coming - thanks for the heads up!

hughbiquitous

@cmcdonald I would love to hear that ISC won't go away until something like this ships.

As it stands today (2.7.2-RELEASE), switching to KEA currently represents a significant regression because non-static DHCP clients cannot be resolved through DNS.

If I'm mistaken on that point, being corrected would be welcome good news.

mwierowski

@hughbiquitous said in Kea DHCP Feature Roadmap:

@cmcdonald I would love to hear that ISC won't go away until something like this ships.

As it stands today (2.7.2-RELEASE), switching to KEA currently represents a significant regression because non-static DHCP clients cannot be resolved through DNS.

If I'm mistaken on that point, being corrected would be welcome good news.

This is correct as documented by Netgate here: Netgate Adds Kea DHCP to pfSense Plus Software Version 23.09

Basic functionality is present in version 23.09, but the Kea implementation lacks the following DHCP server features:

Local DNS Resolver/Forwarder Registration for static and dynamic DHCP clients

Remote DNS server registration

DHCPv6 Prefix Delegation

High Availability Failover

Lease statistics/graphs

Custom DHCP options

Antibiotic

@keyser What kind of benefits from this?

johnpoz

@Antibiotic said in Kea DHCP Feature Roadmap:

What kind of benefits from this?

Of what KEA over ISC - well for starters, they have pretty much stated that they will no longer be developing on the isc dhcpd.. So kind of have to move. Do you have to move today, or even tmrw or shoot next year? No prob not - but at some point yeah going to have to move away from a product that is no longer developed or supported.

Do you still run windows 95?

Currently this is no point to switching to be honest, unless you want to be an early adopter with lots of features not yet implemented in pfsense.. I would wait... I turned it on to see - yup hands out IPs.. Ok back to isc for now, because it does not have same features as of yet that isc does.

But if all you do is hand out IPs, you could prob switch now.

Antibiotic

@johnpoz I mean what benefits from this for home users?
Narrowing the gap between dhcpd and kea is on the list for 24.07. In fact, this week I've started writing a plugin for Kea that allows it to talk directly to Unbound over the unbound control socket to insert, update, and remove host entries. It will be fast, require no additional processes to be running and won't require Unbound to be restarted each time an update occurs.

This is coming.

Antibiotic

@johnpoz said in Kea DHCP Feature Roadmap:

Currently this is no point to switching to be honest

I'm already here)))

johnpoz

@Antibiotic I have no idea what your asking to be honest? Doesn't matter if home user or enterprise user - there are benefits to moving to kea.. But there is little point to do so currently unless your not using any of the features currently not implemented.

If you are just handing out ips with no options and no need for any of the other integrations.. Have at it - I wouldn't spend any time writing anything.. Unless your going to submit to pfsense to be included because whatever you work up now, may or may not be viable as the integration into pfsense changes.

Antibiotic

@johnpoz Foggy, but OK))) will wait

imark77

@johnpoz wait what's wrong with windows 95 that's what I'm replying to from! Partially kidding but I do have a windows 98 virtual machine and a few of them.

Yes going to have to update at some point and looks like we're gonna get some new features too.
Although the flashing banner with no information Link really is a freak out like sky falling nuclear disaster global financial reset Global civil war conspiracy freak out.

--
In case anybody's wondering I disabled it, went back and now ALL systems are getting DHCP. So I don't know if I have a weird edge case. But I'm also noticing domain name resolution ( AP1.MyNet ) isn't working either now. But I can't necessarily confirm that with the new hardware as it was working with the old hardware and I can only think? that it was working with the new hardware but can't confirm my memory on that.

aligator638

@mwierowski I agree with you that netgate should tell us what is to be expected. For example I have AD dsn servers and non windows clients, since ISC DHCP was not GSS-TSIG, I had to implement some scripts to manually register these clients in DNS.

Now with kea this is possible as the plugin exists out of the box:
https://kea.readthedocs.io/en/latest/arm/integrations.html#gss-tsig

The use case is simple, you have pfsense giving out addresses, to windows and linux clients and a separate dns server running on your AD , with ISC you are left off to have clients register themselves, which is not ideal.

With Kea and the plugin DHCP will register the IPs in AD DNS, and life will be better ;-)

Now when will this implemented ?

Eric

thermo

@aligator638 GSS-TSIG is part of ISC's premium "enterprise" subscription, and not something Netgate can implement and hand out to everyone.

cmcdonald

Progress update:

Unbound registration can be enabled/disabled for DHCP and DHCPv6 independently (yes this new integration supports v6). Updates occur asynchronously and never restart Unbound. In fact, enabling/disabling registration doesn't even restart Unbound. Instead, we work out what records need to be added/removed, make those changes via unbound-control and then write out a snippet of Unbound configuration that is used to "seed" Unbound with a set of lease records if Unbound is restarted for whatever reason.

We try several options for determining the domain name. In order of precedence:

domain-name option set in the response packet? (only applicable to v4)
first search domain set in the response packet? (the first option for v6)
finally, the system domain as a last resort

The record ttl is one-third the lifetime of the lease. So if the lease has a lifetime of 7200 seconds, the record ttl is 2400 seconds.

So if you have multiple address pools with different options, those leases could potentially have different domains used in the registration.

Note: These final UI details are subject to change

Here is the DHCPv4 global setting:

Per-subnet overrides:

Use server default tracks the server policy
Enable unconditionally enables registration, regardless of default policy
Disable ... does the obvious thing.

keyser

@cmcdonald This is REALLY excellent ChristianVery good work and a simple/easy to understand UI to configure it.
Exactly what have been severely missing in the pfSense DNS solution for years ️

mcury

Hello, thanks for the hard work, it is getting awesome indeed =)

Let me ask,
Will be possible to run DHCP relay on one interface but not the other ?
I mean, run pfSense's DHCP for a guest VLAN and DHCP relay for another ?

keyser

@mcury Yeah, that would be a VERY nice feature indeed. ESPECIALLY if the DHCP relay could be brought to work properly with DHCP servers at the other end of IPSec S2S tunnels

mcury

@keyser said in Kea DHCP Feature Roadmap:

@mcury Yeah, that would be a VERY nice feature indeed. ESPECIALLY if the DHCP relay could be brought to work properly with DHCP servers at the other end of IPSec S2S tunnels

I had to restore a laptop image through Synology ACB and I couldn't use PXE boot because of this.. The only way was to disable DHCP for all networks in pfSense, then use DHCP relay through the tunnel.

cmcdonald

@mcury I've explored this and actually made some pretty decent progress on it. Though, that was a year or two ago. Once I complete the Kea integration I will look into this again. It is something I too have wanted in pfSense.

Technically speaking, it is possible. However, the ISC dhcpd server and relay were not originally written with this use-case in mind. In fact, they share quite a bit of code. Along that same vein, the current dhcp relay in pfSense is still based on the EOL dhcpd code, so we are actively exploring alternatives here as well. One idea is to write a relay plugin for Kea and actually run the relay directly inside Kea. Another is to just write a new relay in something like Go. DHCP relaying isn't technically complicated, the hardest part is just parsing the packets. Everything else is just packet transforms. There is no active state to maintain as all the state needed to do DHCP relaying is self-contained in the DHCP packets themselves...so you could say DHCP relaying is a stateless operation from the perspective of the relay agent.

Regardless of the direction we choose, I will make sure that we can run DHCP server and relay simultaneously on the same box (albeit on different interfaces of course).

mcury

@cmcdonald That would be great
Really thanks for all the efforts, if you need someone to help testing, just ping