KEA DHCP Dont resolve a.ntp.br
-
@johnpoz said in KEA DHCP Dont resolve a.ntp.br:
@alfredudu said in KEA DHCP Dont resolve a.ntp.br:
In the configuration of the firewall itself, it mentioned hostname.
Where did it say that?
https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv4.html#servers
Hello. Sorry for the delay. The information I'm referring to is in the print. It wasn't within the documentation that I saw, but in the firewall when I went to put the NTP address, it showed me, IP or Host.
-
@alfredudu, time servers have to be provided by ip address, not hostnames. See RFC 2132, Section 3.6, https://datatracker.ietf.org/doc/html/rfc2132#section-3.6.
(In my case, KEA DHCP would not start when I used hostnames. I had to switch to ip addresses to get KEA DHCP to start. It is the first time in about 35 years I encountered a problem. KEA is not ready for production. It belongs on an experimental or unstable branch; not stable release branch at this point in time).
-
I think I'm sticking up for Alfred here.
General use would assume local IPs doled out in the DHCP service. NTP server config itself extremely common to use hostname. Probably the source of the error in the mouseover text.
-
@skogs said in KEA DHCP Dont resolve a.ntp.br:
Probably the source of the error in the mouseover text.
Or the GUI, when error checking and preparing is done o the user entered config values.
If it permits to enter a host name here, it should 'resolve' the entered text, a host name, into an IP that creates an acceptable entry in config file for the service, KEA.
If the resolve failed, the GUI would have to show a classic 'wrong value entered' message. -
@Gertjan said in KEA DHCP Dont resolve a.ntp.br:
If the resolve failed,
This could very well be it, I just put a.ntp.br into ntp server spot with kea set as my dhcp and got no such error.
I just put in some gibberish for the fqdn, and got the exact same error
Nov 29 05:17:32 kea-dhcp4 41717 ERROR [kea-dhcp4.dhcp4.0x30d32b612000] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/usr/local/etc/kea/kea-dhcp4.conf': option data does not match option definition (space: dhcp4, code: 42): Failed to convert string to address 'ljssdf.shdfosldf.tld': Invalid argument (/usr/local/etc/kea/kea-dhcp4.conf:628:33)
So yeah seems just not able to resolve that which is why problem. I would suggest using dns lookup under diagnostics - does pfsense show that a.ntp.br resolves?
-
@johnpoz not OP but I get the same problem. I set the NTP server as time.apple.com and I can resolve it with dns lookup:
I never had a problem with ISC DHCP backend, but Kea throws this error and it can't start:
-
@Spaylia Your not even asking unbound..
What I can tell you is if I switch over to kea, and set time.apple.com I have the same problem.. The difference I see with time.apple.com vs a.ntp.br is that a.ntp.br returns single IP.. but time.apple.com points is a cname and returns 3 different IPs.
;time.apple.com. IN A ;; ANSWER SECTION: time.apple.com. 675 IN CNAME time.g.aaplimg.com. time.g.aaplimg.com. 124 IN A 17.253.6.125 time.g.aaplimg.com. 124 IN A 17.253.26.125 time.g.aaplimg.com. 124 IN A 17.253.26.123;; QUESTION SECTION: ;a.ntp.br. IN A ;; ANSWER SECTION: a.ntp.br. 86223 IN A 200.160.0.8Do you have such problems using isc dhcpd? Seems to work here fine with time.apple.com - Not sure what part people don't actually understand with kea being preview and some stuff not working.. If something doesn't work in kea that you use, then switch back to isc.. I personally would never in a million years put in a fqdn for what I hand out via dhcp.. It sure isn't getting handed to the client as a fqdn, so that fqdn is converted to IP.. So just put in an IP as the rfc for dhcp states..
NTP in dhcp is an option - doesn't it say in the release notes that custom options don't work.. So not even sure if ntp options would be handed to a client or not..
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml
Another thing - when you set some fqdn for your ntp - did you even validate that the client was using it.. Because for example windows doesn't even ask for that option in its discover so its not going to be sent to the client that did the discover..
On left is the discover, you can see what got asked for, ntp not on it.. So look what is sent in the offer.. Again no ntp on it..
So even if it resolved what is put the IP for the dhcp option to be sent to the client (if the client asks for it) and even if the client asked for it is going to use it.. Most of the time clients never use ntp that is handed to them via dhcp.. So all of this discussion is pretty pointless if you ask me..
I would have to look at if anything running on my network even leverages the IPs I have set in dhcp (set there out of habit and hey if something does use ntp in dhcp it says what they should use).. But normally anything I want to use to use ntp, I set on the client.
Shoot many a IOT device has the ntp hard coded.. Ran into some wifi lights, that wanting to resolve uk.pool.ntp.org they sure and the hell were not made in the UK, or meant for UK use.. So setup a host override to poink uk.pool.ntp.org to my local ntp
If you want to play with kea as your dhcpd - simple solution for it not starting when you have a fqdn in your ntp settings is put in an IP.. your clients most likely not using what you put in there anyway.. Or don't use kea as of yet..
Now on the other hand if they you can put in a fqdn via mouse over - then hey the dhcpd should resolve that, if it can - if not then it should rightly fail.. But if it does resolve the fqdn never going to be handed to the client anyway. Maybe there is some issue with cnames and multiple IPs.. And yeah should be a redmine about maybe.. Maybe there is already.. But might be simpler to just edit the mouse over and put in an IP, like the docs say.. and what the rfc says..
https://www.rfc-editor.org/rfc/rfc2132.html
8.3. Network Time Protocol Servers OptionThis option specifies a list of IP addresses indicating NTP [18]
servers available to the client. Servers SHOULD be listed in order
of preference.The code for this option is 42. Its minimum length is 4, and the
length MUST be a multiple of 4.Maybe it resolving to IPv6 is causing it to have a brain fart on what to put into the option? Would have to find a fqdn for ntp that resolves only A and not AAAA and see it doesn't balk at you for that.
-
@johnpoz said in KEA DHCP Dont resolve a.ntp.br:
Do you have such problems using isc dhcpd?
No, as I said, it's working.
Not sure what part people don't actually understand with kea being preview and some stuff not working..
If that's the case, then Kea should be labelled as "experimental" instead of ISC being labelled as "deprecated" with a warning message
Most of the time clients never use ntp that is handed to them via dhcp..
I didn't know that, I thought everything handed was used
So setup a host override to poink uk.pool.ntp.org to my local ntp
Haven't thought about that, thank you!
8.3. Network Time Protocol Servers Option
This option specifies a list of IP addresses indicating NTP [18]
servers available to the client. Servers SHOULD be listed in order
of preference.That's good to know too, I didn't know that either.
-
@Spaylia said in KEA DHCP Dont resolve a.ntp.br:
No, as I said, it's working.
Most likely because is no code to even check for isc. I just put in some gibberish and isc dhcp starts just fine - clearly it didn't resolve that to a IP address
If that's the case, then Kea should be labelled as "experimental" instead of ISC being labelled as "deprecated" with a warning message
It is labelled as "preview" and warning.. Not sure how long you been around IT stuff.. But the term "preview" has never meant for anything to do with IT, hey this is good you should start using it now ;) hehehe
This warning/statement in the release notes seems pretty clear ;)
"Kea is not yet feature complete."Could the wording been better - sure, not going to disagree.. Wording on anything once posted could most always have been worded better, or someone will find something in it that could of been said different..
But honest question, did you read the release notes? Or did you see the warning about isc being end of life shown on the dhcp server page and just clicked to use kea.. Personally I just turned off the warning ;) For one because I use options in my dhcpd that clearly said not going to work yet, and I do static reservations.
But yeah this warning - could of had maybe a warning right below it, hey this is preview some stuff might not work ;)
-
Just to drop my 10c worth. I saw the banner message at the top of the page, and also changed to KEA. Words like "end-of-life" equal unsupported in my experience, and the clear instruction to switch backends left me with no choice but to select KEA. To add a warning that effectively states that KEA isn't fully functional is not helpful. It did not occur to me to read the change logs as the apparent intent of banner message was clear to me, "you have no choice - do this now."
That the ISC version does not map to an IP address in the ntp field suggests that there is a gap in testing capability.
-
@xxup said in KEA DHCP Dont resolve a.ntp.br:
unsupported in my experience, and the clear instruction to switch backends left me with no choice but to select KEA
Too bad all the people that were running and still running version of 2.3 after 2 years warning that it was going away couldn't of felt that way. Wonder how the people still running windows 7 feel about that? ;)
https://www.isc.org/blogs/isc-dhcp-eol/
Does this mean ISC DHCP won’t work anymore?
No. The existing open source software will continue to function as it has, and current operators do not need to stop using ISC DHCP. Many networks with stable DHCP systems that are well-isolated from the open Internet can continue using ISC DHCP as long as their current systems function. However, it is time to start thinking about a migration plan to a more modern system that is actively maintained.
Network and system administrators deploying DHCP in new environments should look beyond ISC DHCP for a solution, as it would be irresponsible to invest in new deployments of this software which is now end-of-life. Naturally, ISC suggests new users consider our Kea DHCP server, but there are alternatives.
--
We can debate the wording all you want - but ISC dhcp isn't going away. Warning states will be removed at some future version - I would bet a HUGE amount of cash that isn't 24.03 or 2.8 ;) Shoot I would prob even wager my left nut ;) hahah
Wonder if they are taking book on fanduel or draftkings? ;)
So 2.6 is no longer supported, so everyone is on 2.7 now? I saw a thread just the other day someone asking about his 2.4.5 version of pfsense and upgrading it.. Not like 2.5 hasn't been out for going on 3 years now.
-
@johnpoz said in KEA DHCP Dont resolve a.ntp.br:
prob even wager my left nut ;) hahah
oh man dont do that
