KEA DHCP missing "Register DHCP leases in DNS Resolver..."

[w_bufffet]

This post is deleted!

[tiny122]

@SteveITS Thanks for the feedback Steve, I struggle to see the value of Kea DHCP for anyone using an internal DNS resolver. Without the 2 hooked up together where DHCP registrations get registered in DNS can only be a backward step. I assume features are going to be added to Kea DHCP to support this sort of functionality before ISC DHCP is discontinued.

[Gertjan]

@tiny122

Exact.
Kea has very extended possibilities to act upon every DHCP related events.
A future pfSense release will use (I guess) fire up this one so it will use unbound-control in its turn to 'insert' DNS info into the resolver (unbound) without the need for unbound restarts as it was the case with ISC DHCP.

[rds3]

I had the same but slightly different issue when I upgraded to Kea DHCP - I was finding that it would resolve some of my devices and not others and this was very confusing. As a test, I added the default domain name (localdomain in my case) in DHCP Server setting for each network (although the text says that it would do this by default anyway and I should not have to enter it if using the default domain configured in System > General Setup > Domain Name). As soon as I applied this change, DNS resolver was able to resolve all my devices. Just thought I'd share it in case it helps anyone, although one shouldn't need to do this and is a workaround at best. Looking forward to seeing this fixed and the option to register DHCP leases being made available in the next release.

[frankz]

@noloader Hi, I have the same need as yours. Is there a way to make a rolback for isc?

[johnpoz]

@frankz said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":

Is there a way to make a rolback for isc?

Click use ISC where you changed it to use KEA

[frankz]

@Johnpoz Thank you , I had focused on the menu of the dhcp server .!!!!! Thank you .

[manny.tew]

the fact that Kea DCHP doesn't have this feature is a deal breaker. I too have reverted to ISC.

I wish this lack had been communicated better that this feature was missing. It was very disruptive to many as they didn't know what was causing DNS to fail.

The deprecation warning should have mentioned Kea isn't at parity with ISC.

[johnpoz]

@manny-tew said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":

I wish this lack had been communicated better that this feature was missing

You mean like in the release notes that goes over what is not working yet.. With the big Warning box ;)

https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#rn-2-7-1-kea
https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#rn-23-09-kea

And also notice in the same place tells you how to just switch back there at the bottom, etc..

[noloader]

@johnpoz said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":

I wish this lack had been communicated better that this feature was missing

You mean like in the release notes that goes over what is not working yet.. With the big Warning box ;)

A small nit... The GUI does not provide the information before, during or after an upgrade. And there is no link to the release notes document.

On the Home page, there's just a "Version X.X.X is available," with a little cloud (download) button to click. On the System Updates page, there's just a version number and confirm button to click.

So I think it is fair to say "better communicated" since no communication is going on at the moment for those who are upgrading using the GUI.

[SteveITS]

@noloader I understand your point and don't disagree about Kea, but your example is for pfSense itself and upgrading that doesn't change the DHCP server in use. I would say the page to change DHCP servers needs the warning/link. For versions, I think it's assumed people read the release notes as those cover other breaking changes, e.g. OpenSSL/OpenVPN.

[noloader]

@SteveITS said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":

For versions, I think it's assumed people read the release notes as those cover other breaking changes

Actually, no. I did not know there was a official document maintained until this thread.

But then again, I probably would not have read it since I'm on a Stable branch, and not an Experimental branch. I expect Stable to be stable.

[manny.tew]

@johnpoz Thank you for correcting me. Reading the warning however, I'm not sure I would have connected what it meant. As developers we consider warnings (wrongfully) as something to address 'soon' ...NOT something that is actually breaking functionality.

Perhaps the whole warning box being on the Advanced Networking page (system_advanced_network.php) would have helped?

The sentence there now which says "ISC DHCP has reached end-of-life and will be removed from a future version of Netgate pfSense Plus. Kea DHCP is the newer, modern DHCP distribution from ISC that includes the most-requested features." encouraged me to switch without reading the release notes as I never imagined that Netagate would deprecate it without feature parity.

A link to the docs/release notes directly from that sentence above would be good to consider. Secondly, just as ISC DHCP now has (deprecated), perhaps Kea DHCP should have Kea DHCP (Opt-in Preview). If it did, it would have encouraged me to investigate etc. before jumping in.

PS: also, the system should have known that I have a feature enabled that Kea doesn't support. A quick config check should have put a warning that DNS will break.

[johnpoz]

I am not saying it couldn't of done better or worded different. What I am saying is the info was provided, the problem is users rarely actually read release notes.

A quick config check should have put a warning that DNS will break.

That would be slick to be honest.. But that seems like a large amount of extra coding for something that is "preview"

I would rather the developers spend time on actual implementation of final product, vs working on code to check if user is using something that is not yet enabled ;)

[manny.tew]

@johnpoz agree it is too much for this...but as a design pattern it should be something the devs ought to consider...as I doubt this will be the last subsystem to be deprecated.

[JonathanLee]

@manny-tew Hello Happy New Year,

I wanted to chime in on this again as I like to test and report issues on redmine all the time.

@manny-tew said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":

PS: also, the system should have known that I have a feature enabled that Kea doesn't support. A quick config check should have put a warning that DNS will break.

It really does take a massive amount of time to code, test, and develop new features like this. With that said not everything works as expected at times but this community always makes it happen. I personally love the flexibility of customizations that pfSense provides its users. pfSense must have a million possible customizations and configurations users can have, each being different by needs.

• Users are able to go back to ISC at the push of a button. Many vendors do not allow backwards compatibility.

• Boot environments exist if an update is not to user liking. I use them all the time.

• Kea fixes many issues that ISC has had for years like VLAN hopping issues if I remember right. ICS passes out addresses facing the full network and it can leak into vlans, and Kea is modular and granular.

Some Info from the Kea's website

"How is the Kea DHCP server different from the older ISC DHCP?
Modular Component Design, Extensible with Hooks Modules. The Kea distribution includes separate daemons for a DHCPv4 server, a DHCPv6 server, and a dynamic DNS (DDNS) module. Many optional features are enabled with dynamically-loaded “Hooks Modules,” which you need run only if you are using them. You can write your own hooks modules (in C++) or try some of the hooks we offer.

On-line Re-configuration with REST API. Kea uses a JSON configuration file that can be modified remotely via set commands and reloaded without stopping and restarting the server, an operation that could take quite a while with ISC DHCP.

Designed to Integrate with Your Existing Systems. Kea allows you to separate the data from the execution environment, enabling new deployment options. Your network data - leases, host reservation definitions, and most configuration data - can be located separately from the DHCP server itself, using a Kea “backend.”

Web-based graphical dashboard. Kea now has a graphical dashboard for monitoring multiple Kea servers. This system, called Stork, uses agents deployed on the Kea servers to relay information to a centralized management platform, providing the administrator with an easy-to-use quick view of system status and activity" (KEA).

I applaud Netgate for taking on such a massive change. Netgate has provided users the hypothetical ability to dip their feet into Kea DHCP waters right now, provide warning about ISC's future depreciation, and simplify some understanding to why it's needed.

@manny-tew said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":

The sentence there now which says "ISC DHCP has reached end-of-life and will be removed from a future version of Netgate pfSense Plus. Kea DHCP is the newer, modern DHCP distribution from ISC that includes the most-requested features." encouraged me to switch without reading the release notes as I never imagined that Netagate would deprecate it without feature parity.

@manny-tew said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":

A link to the docs/release notes directly from that sentence above would be good to consider. Secondly, just as ISC DHCP now has (deprecated), perhaps Kea DHCP should have Kea DHCP (Opt-in Preview). If it did, it would have encouraged me to investigate etc. before jumping in.

Not only do we have more understanding about KEA dhcp you are more ready for when it is fully deployed. KEA has not been forced on us as ISC is still accessible.

"The Internet Systems Consortium (ISC) has released security advisories that address vulnerabilities affecting multiple versions of the ISC’s Berkeley Internet Name Domain (BIND) 9. A remote attacker could exploit these vulnerabilities to potentially cause denial-of-service conditions and system failures.

CISA encourages users and administrators to review the following ISC advisories CVE-2022-3094, CVE-2022-3488, CVE-2022-3736, and CVE-2022-3924 and apply the necessary mitigations"(CISA).

KEA is the necessary risk mitigation. I am grateful and thankful to be able to work with it.

Works Cited:
Consortium, I. S. (n.d.). Kea DHCP. https://www.isc.org/kea/

ISC releases security advisories for multiple versions of BIND 9 | CISA. (2023, January 27). Cybersecurity and Infrastructure Security Agency CISA. https://www.cisa.gov/news-events/alerts/2023/01/27/isc-releases-security-advisories-multiple-versions-bind-9

[Squish]

@rds3 There is definitely some workaround there.
I set the default domain explicitly to default value. Which did nothing, so I removed the explicit value and applied changes.
Then I went to DNS Resolver / General Settings and it prompted to apply changes, even though I had not made any additional changes. As soon I applied, DNS lookups began resolving correctly.

This is on 2.7.2 fwiw

[kscrib]

I read the release notes and was aware that the change to KEA would no longer register local DHCP leases in DNS.

My question is will KEA ever register DHCP leases in the local DNS in future releases, or is that a functionality that will never be available? In other words, is the functionality being worked on in development? I changed to KEA and also am using the development branch of pfsense. As of 24.03.a.20240117.0600, the functionality does not exist.

[SteveITS]

@kscrib I would think so; phrasing like "After Kea integration is complete" and "Basic functionality is present, but not all features are supported at this time," indicate future development.

Until then there's not a reason to move off the default server, IMO.

[NickyDoes]

I was just bitten by this one. I had read the release notes when upgrading, I had forgotten about that later when presented with multiple, reasonably strongly worded warnings that I was using a deprecated package.

Balance the warning message a bit more. "...most-requested features" is a bit strong.