KEA DHCP missing "Register DHCP leases in DNS Resolver..."
-
The current goal is to have Kea at feature parity with ISC DHCP by the end of the year, then one release with Kea being optional, another release with Kea being the default for new installs, and finally another release to completely remove ISC DHCP entirely.
-
@SteveITS I switched it back but it still wouldn't resolve. I don't know what fixed it, perhaps DNS caches just had to expire, or my poking around in DDNS options (we don't use DDNS) fixed it. I think I enabled the DDNS host registration option without overall enabling DDNS. It's not clear if that has any effect or not, but after a while things were working again. Famous last words! Without it being at feature parity I think it's fine to as for testing feedback, but there shouldn't be a nag about it being deprecated. This suggests a need to migrate. It should also warn about a lack of feature parity, IMO.
-
Oh, I think I know why it took a while to return to normal: the migration wipes the existing leases, and it takes a while for clients to discover this and renew. Until that happens the client identifiers aren't going to be injected into DNS.
-
@bson said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
This suggests a need to migrate. It should also warn about a lack of feature parity, IMO.
That's fair. The current warning definitely has a "the sky is falling" tone to it, which it certainly isn't.
-
This post is deleted! -
@cmcdonald said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
That's fair. The current warning definitely has a "the sky is falling" tone to it, which it certainly isn't.
This. 100% this. The warning gives the impression that one should update ASAP and gives zero indication that the replacement isn't feature complete.
-
Still an issue.
-
@softwareplumber said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
Still an issue.
https://www.netgate.com/blog/improvements-to-kea-dhcp
-
There is no longer a way to revert back in the GUI, so my setup is broken.
It should not have been released without better migration testing.
-
@uneventfullogs I believe you should be able to revert in System->Advanced->Networking. At least, that's where I've been able to do it in the past.
-
@noloader Thanks, just got bit by this and lost a day trying to figure out why a local server's new IP wasn't being recognized. I finally restarted the dns forwarder (to pihole) and I lost everything (local names) and my day trying to track down "what I did" before remembering yesterday I had responded to the deprecation warning.
It is now a year later and this problem persists. This is my wake up call to switch to the other guy sometime this coming year.
-
@BruceX I switched to kea after the 24.11 upgrade and don't have any problems. Before I had to revert to ISC per above.
-
@4o4rh I've not used the patches package before but I interpret your statement as applying these patches also fixes this dns not registering problem.
I'll have to wait awhile before having the courage to apply these after the last 'fix' I applied lost me a few days to debugging and fixing my system.
-
@BruceX I have now enabled the KEA DHCP server. On settings I checked both "Enable DNS registration" en "Enable early DNS registration". All seems to work now. The only thing is you still need to provide an IP address of the NTP server rather than a domain name.
-
@pvk1 do you mean in the ntp server? i don't have this problem. I am using normal country level ntp pools
-
@pvk1 said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
provide an IP address of the NTP server rather than a domain name.
Which is how it should be per the rfc.. dhcp doesn't hand the client a fqdn for ntp - it hands out an IP.
-
@johnpoz I must be understanding something different from the statement.
In my NTP Server settings, I use de.pool.ntp.org and it works fine. -
@4o4rh said in KEA DHCP missing "Register DHCP leases in DNS Resolver...":
In my NTP Server settings, I use de.pool.ntp.org and it works fine.
That's the NTP server process. It uses the WAN side.
Here this :
which has 'nothing' to do with the NTP DHCP server setting (the DJCP server operates on the LAN side of pfSense). The DHCP server can inform the DHCP clients of a known (local) NTP server, like pfSense, as it has a NTP server on board.
This DHCP (kea or ISC) 'NTP setting' needs to be an IP, and is typicality the pfSense LAN IP.Example :
-
^exactly - pfsense allowed you to put in a fqdn for the dhcp server settings before. They would just translate that to an IP for dhcp settings. They should either modify the note below the box, or allow for fqdn (that they translate for you).. But fqdn is a bad idea because something like something.pool.ntp.org can resolve to lots of different IPs - that change, and pool members come and go so if they hand out IP X, tomorrow maybe that IP is no longer valid, etc
It really was never a good idea to allow users to put in fqdn for the dhcp server ntp it hands out.
-
@Gertjan ah ok. my clients take ntp from pfsense. that's why i don't run into this problem then.
