KEA DHCP missing "Register DHCP leases in DNS Resolver..."
-
@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.
-
@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.
-
@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.
-
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 ;)
-
@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.
-
@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
-
-
@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
-
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.
-
@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.
-
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.
-
@kscrib said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
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?
As we all know, ISC phased out the classic DHCP server. They've been making a whole knew DHCP server from the ground up.
KEA already supports what consider to be API's, callbacks etc.
So : yes, and it has been said on the forum already : one of the reasons why KEA is used now :
No choice, "ISC-DHCP" is a dead end. So it's the best choice ;)
And yes : the whole idea behind all this is that KEA will transmit new host names, coming from new DHCP leases, into the revolver's internal cache.
The old mechanism, writing host names and IPs to a file, and then restart unbound to make it aware of the new device in the network, will, finally, be abandoned. -
As of this moment (Feb-2024), besides the static IP mapping approach, is there any other trick we can do to inject the KEA DHCP leases into DNS Resolver?
Even script based solution is welcomed.
I got a bunch of PC / Mac at home, and it is pretty painful to set every single computer into static IP mapping (not to mention many of them got Ethernet AND Wifi MAC address to resolve).
I am switching back to tried-and-true ISC DHCP for the moment.
-
@Slowmotion-0 Have not seen any of that in the last 5 months. I would just use ISC until 24.03 or whenever Kea is fully integrated.
-
@SteveITS I'm waiting until KEA is supported more fully. What's prompting you to make the move?
You can turn off the reminder message, if that's causing distraction. -
@ndemarco You replied to me but I am using ISC. I did use Kea for about 2 weeks because ISC had a bad bug in 23.09, and I didn't wait long enough
, but the fix was slipstreamed shortly after, and then 23.09.1 was released.A lot of people here and on Reddit are changing just because of the warning message, without researching that it's in alpha/beta/preview/whatever.
-
Same issue here - i searched nearly 2 days for a solution..... ..... and rolled back to ISC
-
I see there is a warning ISC will be removed in a future release, I looked at the features missing and see I will be affected.
Is there a chance ISC gets removed whilst the this KEA is incomplete, or will there be a stable build of pfSense that has ISC alongside a fully featured KEA to allow for transition?
-
@chrcoluk said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
Is there a chance ISC gets removed whilst the this KEA is incomplete, or will there be a stable build of pfSense that has ISC alongside a fully featured KEA to allow for transition?
You have the answer in front of you
As a picture says it all :
Way back, pfSense had a DNS solution, like most SOHO routers on planet earth : dnsmasq.
A forwarder.
You had to set it up, by pointing it to your ISP DNS servers - or any other DNS server known that day.
1.1.1.1 8.8.8.8 etc were not a thing in the past, you entered your ISP DNS and done. You were online.edit : and that's where things went pretty bad :
These days, "people" still 'have to' enter a DNS when they set up your router/firewall.
Because "it has to be done" like that.
Well, wrong. It's just a burned in old habit, as we were trained by our ISP to do so.
Like using port "25" to drop a mail on the ISP mail server : that was gore, plain wrong, and created later on massive security issues, a big mess.The real thing is : "people" don't know what DNS is, they think they know.
Some financial guys @ Google - an d others - stepped in, an somewhat 'used'/'abused' this situation and is made billions out of this old, burned in habit. And I get it : your DNS request are worth big money.
[ end edit / (actually a rant) ]
But then unbound came along : a real resolver. This was answering the question : why accepting a MITM concept as you can do what real mean do : get your DNS info from the source. This became even more important as DNS was secured with DNSSEC.
The resolver (unbound) became the default DNS solution for pfSense but dnsmasq, the forwarder is still there if needed, as some are obliged to hand over all their DNS request to some company.
So, IMHO, I'm pretty will be able to chose.
KEA will be the default, with ISC to fall back, if old quirks and bugs are essential for your setup.Btw : the same thing goes for : pfSense was using "lighttpd" as the GUI web server, as it was light weight and good enough for the task and one day, they switched over to "nginx" (and we did not have the choice ^^).
Btw : KEA is written by the guys that build ISC, so, we'll be just fine.
-
@Gertjan My question was about the DHCP server not DNS though. The message doesnt say it will be a fallback, it says it will be removed.
-
@chrcoluk I would think it highly unlikely that netgate would remove isc dhcp until such time that kea has parity with isc feature set or greater. Why would they do such a thing?
Here we are removing isc because well they have stop developing it, there is nothing wrong with it, it is mature and stable and works.. There are no known security issues with it.. Or at least none that are of any concern, but hey lets rip it out and force users to use kea, that is missing xyz, boy that will make us look great in the eyes of our users ;)
As @Gertjan pointed out with the forwarder, when they added unbound it was just a package you could install, then they integrated it and made it default, etc.. But that wasn't overnight, and to be honest that was long time ago, I don't recall if they actually stated if forwarder would be removed at future date or not.. But clearly its still here ;)
But it would be insane to think they are going to remove isc dhcp until kea more than ready to take over with all the features that isc currently supports at a min.. Even if they change over kea to be default of of the box, I bet you they leave isc in there for a few versions at least..
