core
core copied to clipboard
Kea DHCP Not honoring the order of the list of DNS ip's that shuld be provided to DHCP Clients
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [x] I have read the contributing guide lines at https://github.com/opnsense/src/blob/master/CONTRIBUTING.md
- [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/src/issues?q=is%3Aissue
Describe the bug
When Kea DHCP is configured to serve a list of DNS IP's (primary & fallback) instead of just a single IP the order in which the ip's are entered is not honored. Instead the IPs are sorted in ascending order.
Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)
To Reproduce
- Go To Services --> Kea DHCP --> Kea DHCPv4 --> Select the tab Subnets
- Select for configuration any subnet serviced by key (as a sample 192.168.5.0/24)
- Verify that the option "Autocollect option data" is unchecked (we are going to explicitely set the desired ip for the DNS's)
- In the DNS servers field enter the desired values. As a sample 192.168.5.20 (that vould be a pihole dns) and 192.168.5.1 (that would be the unbound dns in opnsense itself which is used as fallback in case pihole is not available). Note that the values are entered in this order: 192.168.5.20 192.168.5.1 This is done so that pihole should be the primary dns for the clients and unbound the fallback one.
- Save and Apply
- Error 1: If we open again the configuration of the subnet we can see that the ip's have been reordered and are listed as 192.168.5.1 192.168.5.20
- Error 2: If we have a client in the subnet release and renew its configuration we see that it has received 192.168.5.1 as first DNS and 192.168.5.20 as second Therefore it becomes impossible to configure dhcp to serve a configuration where a dns in the lan is the main one and have unbound be the backup one.
Expected behavior The order of the list of ip's to be served as DNS should be honored as entered. They should not be reordered.
Describe alternatives you considered For the time beign I'm stuck with giving the DHCP clients just one DNS (the pihole) and keeping manual configuration for the ones where I cannot risc lack of service if pihole is inavailable.
Screenshots
I believe it's not necessary with the explanations given, but if you think it can be of use I'll provide them
Relevant log files
Not applicable.
Additional context
The issue can be reproduced at will. It's not transient. Also, I guess this effect can be due to the GUI collecting the info and reordering it before passing it for saving...but of course it's only a guess, it may as well bee how kea stores or retrieves it.
Environment
OPNsense 25.1.2 (amd64) Intel® I7-1355U Network Intel® I226-V
Thank you a lot for helping.
I can confirm this issue present in my environment too - Kea v2.6.1_2 running under OPNSense v25.1.3
If any additional info needs to be collected just let me know. Tks.
Upgraded to 25.1.6_2-amd64 unfortunately the issue persists
Confirmed this is still present on OPNsense 25.1.7_4 I reviewed the kea config, and the DNS servers are written to it in the wrong order.
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
Enter your primary dns server, save, and apply. Then go back in and add the secondary dns server, save, and apply again. It looks like it keeps the correct order. You could also edit the config file:
"option-data": [ { "name": "domain-name-servers", "data": "10.0.0.5,10.0.0.1" },
Thank you!!!. Will give it a full try during the weekend (crazy week this one).
In the meanwhile some quick testing...looked for the config file...but is config.xml and the entries inside looks like xml as expected. Like the following.....
<domain_name_servers>ip of dns server for a given vlan</domain_name_servers> <domain_name_servers>same for another vlan</domain_name_servers> etc.
Looks promising. Will update.
Thanks again
Unexpected things arose during the weekend but have managed to give a try to the bypass above and can confirm it works nicely. Anyone interested...this is an easy bypass of the issue. For me...it's a bit late. Due to this issue I just setup blocking lists in unbond witch give a very similar outcome while running out of the same box wher the unbound dns is and therefore saves the need for setting up a pi-hole container. Reporting exists in unbound but is not as nice as pi-hole one, this I've to admit.
Thanks for the hint !!!
Best regards.