-
Notifications
You must be signed in to change notification settings - Fork 753
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Register Kea DHCP Leases (dynamic mappings) with Unbound #7475
Comments
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? |
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, |
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. |
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. |
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. 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. |
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? |
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. |
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, |
Oh, okay, sorry then. That said, thanks for the great work! |
A more future proof option is fine, I'm just honestly wondering if we are trying to fix the issue in the right area. 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). |
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 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. 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. |
I just migrated everything to kea (100+ reservations...) just to realize that this feature is missing and undoing everything. Please add a message in the UI to inform users about this feature (currently?) missing. I get that it's an ongoing topic and if this feature is coming or not, just inform the users like avollmerhaus proposed in the mean time:
|
I can see a lot of people staying on ISC due to this decision. I need this feature myself mainly for Esphome devices. |
Fixed it for you. :) |
Nothing to fix as I said it correctly. :) |
No. You see, only ISC wants you to use Kea. https://www.isc.org/blogs/isc-dhcp-eol/ People still use ISC over Kea. OPNsense still uses ISC by default. We merely made sure to give you access to Kea. |
That's not what the decision is about, ISC vs Kea. Most users can care less what it is called underneath the hood. They just care about how it works at the end of the day. |
Fine, I also care about users knowing that care takes effort from someone else eventually. |
But seriously. We admins, who are incapable of real programming, consider some developers almost like gods. Gracious thanks for your work. For the work without which we wouldn’t have our livelihoods. Thank you. |
I think this misses the point. Please use what works for the time being. There are much bigger things to take care of right now especially since the world has not bought into Kea as much as Kea developers wanted. |
Happy to understand the security reason, and I agree that this can be an issue. But Opnsense should trust the network admin who knows what he is doing and gives the ability to enable/disable, based on the scenario if this can be or not an issue. |
My Impression to add. I have lots of fix entries, but certainly not all. Because I had so lots of fixed reservations, which worked (more than 80% of the leases) i actually did recognize it weeks after the transition and cleanup... maybe also because of the following thing: |
and yes.. in Business I didn't do the transition. ##added later: |
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
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.
The text was updated successfully, but these errors were encountered: