Register Kea DHCP Leases (dynamic mappings) with Unbound

[mfranzil]

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/core/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/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

No, just a feature request.

Describe the solution you like

This issue extends #7307 (and PR #7362) to let Unbound support Kea dynamic leases into mappings for Unbound.

Describe alternatives you considered

The only alternative for letting unbound dynamically generate domains is by using the deprecated ISC DHCP.

Additional context

This could be achieved via a Python script similarly to what already happens in opnsense/scripts/dhcp/unbound_watcher.py. We can discuss whether to add a second script or extend the existing one.

I could give some support into implementing this feature if needed.

[fichtner]

This will be out of scope for a while. Static mappings will be supported in 24.7 (the work for it is already done).

[mfranzil]

This will be out of scope for a while. Static mappings will be supported in 24.7 (the work for it is already done).

Yes, I am aware, I was following the other issues. But - sorry for this - may I ask, why would it be out of scope? (to better specify: I didn't want to sound aggressive, just asking. Either way I can help implementing it)

[fichtner]

Tying these separate components together has been the source of large amounts of work in the past. The current re-implementation works, but still suffers from differing feature set between unbound and dnsmasq and adding a third service to the mix probably adds more challenges than it solves.

We just want to take this step by step and avoid repeating suboptimal scripting we will be fixing later on again.

Cheers, Franco

[mfranzil]

Understandable, thanks for the thorough explaination. I will still keep this open for when you will decide to work on, and probably still rely on ISC for the time being.

[h3krn]

While I don't think this will or should ever make it into main (based on reading above comments), I made an attempt to for myself to get dynamic leases from kea into unbound here: https://github.com/h3krn/opnsense-core/blob/unbound_kea_watcher/src/opnsense/scripts/dhcp/unbound_kea_watcher.py

The advantage of a script parsing the kea leases file is that it supports a HA setup. And it will register leases on both cluster nodes. I initially tried to leverage kea scripting hooks to register leases. But unfortunately these only fire on the active node, not giving me any benefit of using kea's improved cluster capabilities over dhcpd.

@fichtner If I can contribute to get this feature included (in a better way?), I'll be happy to try and help/code. Just let me know the path forward.

[avollmerhaus]

I'm in the process of evaluating a switch to Kea, and it took me a good while to find this issue and realize it wasn't some misconfiguration on my part.
Maybe there needs to be a little text on the Kea configuration page that says "registering dynamic leases with unbound is unsupported for the time being" or something.

That said, considering the understandable hesitation to support this feature due to the somewhat "hacky" nature of whipping up a custom script that parses the lease-file or something - could somebody point me to a "proper" way for achieving DNS registrations when using opnsense?
It is my understanding that the same "hacky" method is used for ISC DHCPd as well.
I guess I could switch to dnsmasq, but there has to be a "standard" way...?

[AdSchellevis]

That said, considering the understandable hesitation to support this feature due to the somewhat "hacky" nature of whipping up a custom script that parses the lease-file or something - could somebody point me to a "proper" way for achieving DNS registrations when using opnsense?

I'm afraid the proper way is to not trust the client for communicating its hostname, but pinning it statically. To be honest, I personally always found it a bit weird to trust the client for its name unconditionally. I haven't touched any windows server environment for quite a long time, but if I'm not mistaken there's some sort of trust relationship between the domain controller (with integrated dhcp server) and the client to assure name and address can not be spoofed.

[h3krn]

While I don't actively maintain any domain controllers, my (non-domain joined) Linux laptop just as nicely registers in AD dhcp/dns at work, as any other dhcp/dns system I've run into in the past years.

Just googled a bit and found AD does indeed supports "Secure dynamic update". This seems to be handled directly between "DNS Client service" on the system trying to register itself and the primary DNS service retrieved from the SOA record. It does not involve the DHCP service. Needless to say this is probably a Windows only feature?

[avollmerhaus]

While trusting the clients to provide the names is certainly not feasible in big networks full of unknown, potentially dangerous actors it sure is handy in a rather small network full of trusted clients.
In my case, that's a small VLAN of about 40 printers. With ISC DHCPd, I can simply configure the hostname in the printer's firmware and that's all that is needed for my CUPS server to address the printer by hostname without having to register every printers MAC with the DHCP and every IP with the DNS server or figuring out how to have the printer register itself with the DNS (if that's even possible with the printer firmware).

[fichtner]

To be frank I'd like to say that these discussions are a bit pointless: it's a feature we do want to support, but there is no resource to be used to make it happen in a way that is more future proof than what we currently have. If you'd like to see it that's ok, but arguing the benefits after the fact is not helpful.

Cheers, Franco

[avollmerhaus]

Oh, okay, sorry then. I was under the impression that supporting the static mappings was decided while support for including the dynamic leases was still under discussion.

That said, thanks for the great work! I've been a user since the m0n0wall days and really love OPNsense.

[AdSchellevis]

A more future proof option is fine, I'm just honestly wondering if we are trying to fix the issue in the right area. Usually these hostnames originate from somewhere, which very often isn't the client machine in my experience.

This might also be a reason why integrations like these don't seem to exist in the related projects (unbound/kea), I haven't seen similar options in other products either (which doesn't mean they don't exist).

[Monviech]

To add to here, there is a very simple reason why its a bad idea (in Windows) environments to allow all hosts to register their own hostnames (choosing the insecure host register option that doesn't use the safe ipconfig /registerdns to register the domain).

If a host impersonates the hostname of the domaincontroller (or any host), they can impersonate it (at least break the function of the domain since when impersonating the hostname of all domain controllers, there is no real one left to answer.)

From a security standpoint having static leases with static hostnames is the best choice.

[PixelPingin]

If a host impersonates the hostname of the domaincontroller (or any host), they can impersonate it (at least break the function of the domain since when impersonating the hostname of all domain controllers, there is no real one left to answer.)

From a security standpoint having static leases with static hostnames is the best choice.

I wouldn't blame dynamic hosts registration to the DNS to be an security issue rather than not ideal network architecture. Static hostnames for important services, with no way to conflict them on your own DNS, sure.

Dynamic registration for well...dynamicly changing devices, why not. The other point of view are today's devices trying to hide themselves. Still gives me some kind of nice overview what kind/type of device that could be based on the reverse DNS check.