KEA DHCP missing "Register DHCP leases in DNS Resolver..."
-
@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..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
@johnpoz said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
I wish this lack had been communicated better that this feature was missingYou 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.
-
@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.
