KEA not respecting DNS changes in subnet

[Foowy]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

When setting custom dns servers in dns field, kea is set to gateway address when "Auto collect option data" is enabled. Un-setting "Auto collect option data" and reloading custom DNS servers corrects the GUI to show custom dns server addresses, but leases are still being handed out original gateway address for dns.

To Reproduce

Steps to reproduce the behavior:

1. Go to Services > Kea DHCP [new] > Kea DHCPv4
2. Click on Subnets
3. Create subnet with option Auto collect option data enabled
4. Enter custom DNS servers that firewall is not using
5. From device refresh interface/reconnect/renew IP
6. Assigned DNS from DHCP will be that of the firewall
7. Disable Auto collect option data
8. Correct DNS server ip's in subnet
9. From device refresh interface/reconnect/renew IP
10. Assigned DNS from DHCP will still be that of the gateway and not of manually set dns addresses

Expected behavior

Disabling Auto collect option data should cause kea to use custom values entered into dns field

Describe alternatives you considered

Deleting and re-creating subnet at this time without "Auto collect option data" being enabled properly respects manually entered DNS addresses for client DHCP

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.1-amd64
Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (2 cores, 4 threads)
Using Unbound for gateway/firewall dns

*Edit

Words are hard and proper sentence structure is harder

[AdSchellevis]

Missed apply? the running config can be found in /usr/local/etc/kea/kea-dhcp4.conf, apply restarts the service, which means you can check the pid in top as well (should change after apply).

[Foowy]

Sorry, forgot to add the step apply in reproduce. But yes, changes were applied and clients were still receiving gateway as dns.

Example:

created subnet 192.168.1.0/24 > loaded 192.168.1.40 as dns > left default enable of Auto collect option data > disabled isc dhcp4 > enabled kea > renewed client > client gets ip in scope but shows 192.168.1.1 as dns

Without reverting to isc dhcpv4, modified subnet 192.168.1.0/24, notice dns IP is now showing 192.168.1.1 instead of .40

Removed check from Auto collect option data, changed dns back to 192.168.1.40, applied settings, restarted KEA dhcp service to be safe, renewed client system. System receives IP in scope, but still receives 192.168.1.1 as DNS and not .40

Editing subnet again shows the correct dns address of .40 in gui

Deleting subnet and creating again, this time without enabling Auto collect option data and using .40 for dns on creation, renewing client shows correct dns as .40

Further System Info:

system was upgraded from 23.7.12 > 23.7.12-5 (Maybe incorrect version, but was the preload update that installed morning of 1/30/2024) > followed by direct update to 24.1

Repeated failing process still nets me the same results as initial post, only upon recreation of subnet does the issue clear

I did not clear reservations, but noticed in below configs and testing, that if reservations exist for subnet, recreating the subnet does not bring forward the reservations. This is an entirely different issue, but wanted it to be known. Not sure how opnsense team would like me to handle that issue.

Logs report warning of

			2024-01-31 04:41:36.326 WARN [kea-dhcp4.dhcp4/42682.0x83125a000] DHCP4_CONFIG_SYNTAX_WARNING configuration syntax warning: /usr/local/etc/kea/kea-dhcp4.conf:50.10: Extraneous comma. A piece of configuration may have been omitted.

and can be seen in below .conf at last bracket before final 2 braces

Conf Data with currently working settings:

"Dhcp4": {
    "valid-lifetime": 4000,
    "interfaces-config": {
        "interfaces": ["bridge0"]
    },
    "lease-database": {
        "type": "memfile",
        "persist": true
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/var/run/kea4-ctrl-socket"
    },
    "loggers": [
        {
            "name": "kea-dhcp4",
            "output_options": [
                {
                    "output": "syslog"
                }
            ],
            "severity": "INFO"
        }
    ],
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.168.1.0/24",
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "data": "192.168.1.20,192.168.1.40"
                },
                {
                    "name": "routers",
                    "data": "192.168.1.1"
                },
                {
                    "name": "ntp-servers",
                    "data": "192.168.1.1"
                }
            ],
            "pools": [
                { "pool": "192.168.1.100-192.168.1.245" }
            ],
            "reservations": [
            ]
        }
    ],
}

}

[Foowy]

looks like it is possibly related to the same issue with applying config changes reported by Ronin in #7183

Negative :)

Clicked apply in all three tabs - without making a change - verified after each with tail -- comma still present.

Restarted Kea, went through the same steps once more - no change.

So it's picky enough to not touch the file, even if restarted in the meantime, unless a config change needs to be committed.

Found another cosmetic bug tinkering with it: the Trash Can in Reservations is not visible on 1366x768 laptop screens, it's replaced with ... and non clickable. It only appears if I remove all columns except Commands (I'll try to open an issue later, mentioning it here in case I forget)

[AdSchellevis]

this one #7183 should be fixed, when option data is configured as expected, it might be the client giving you a hard time, that's not something we can fix from our end unfortunately.

[KaiKimera]

I confirm the error. DNS is not installed on clients with the "Auto collect option data" option enabled.

[AdSchellevis]

@KaiKimera best read the ticket and responses to help you debug your issue, the warning is harmless and is already fixed in the master branch as communicated earlier and your claim is the exact opposite as reported in this ticket. If the configuration file is correct, there's not much to look at from our perspective.

[Foowy]

@AdSchellevis thank you for checking this over, i will see what i can find on the client side as to the addressing failure then. In regards to the reservations, i will tinker with that later today to see if it is still an issue.

Going to close issue at this time as not to pollute the open issues queue.