core icon indicating copy to clipboard operation
core copied to clipboard

Kea DHCP Not honoring the order of the list of DNS ip's that shuld be provided to DHCP Clients

Open ArturRuta opened this issue 8 months ago • 4 comments

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

  1. Go To Services --> Kea DHCP --> Kea DHCPv4 --> Select the tab Subnets
  2. Select for configuration any subnet serviced by key (as a sample 192.168.5.0/24)
  3. Verify that the option "Autocollect option data" is unchecked (we are going to explicitely set the desired ip for the DNS's)
  4. 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.
  5. Save and Apply
  6. 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
  7. 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.

ArturRuta avatar Mar 07 '25 11:03 ArturRuta

I can confirm this issue present in my environment too - Kea v2.6.1_2 running under OPNSense v25.1.3

TheBengaBenga avatar Mar 17 '25 15:03 TheBengaBenga

If any additional info needs to be collected just let me know. Tks.

ArturRuta avatar Mar 23 '25 16:03 ArturRuta

Upgraded to 25.1.6_2-amd64 unfortunately the issue persists

ArturRuta avatar May 11 '25 16:05 ArturRuta

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.

Z3r0Auth avatar May 30 '25 16:05 Z3r0Auth

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.

OPNsense-bot avatar Sep 03 '25 10:09 OPNsense-bot

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" },

mdcayton avatar Sep 15 '25 01:09 mdcayton

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

ArturRuta avatar Sep 16 '25 19:09 ArturRuta

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.

ArturRuta avatar Sep 23 '25 17:09 ArturRuta