In the release notes for 24.7, I found this:
ISC DHCP will no longer reload DNS services on static mapping edits. This is for feature parity with Kea DHCP and avoiding cross-service complications. If you expect your static mappings to show up in a DNS service please restart it manually.
I am a bit puzzled as to how the DHCP system is handled. The only feature that was missing for ISC DHCP to assign/remove static mappings via an API. (It's important when using Terraform and Ansible to deploy VMs.)
Then KEA came along with half of the features of ISC missing and without an upgrade path. I have at least 50 static mappings that I would have to manually enter in KEA, so this makes a migration not a happy one. Especially if you need features in ISC that are no available im KEA.
The fact that a reload is done when applying changes to static mappings is a basic feature. This should not be removed from ISC but added to KEA.
I wrote this post, because I do not understand the direction of development. It makes no sense to me.
DHCP is a crucial component of a Firewall/Router and it seems to me that not only the replacement is worse when it comes to features and usability, the "old" system is now made worse to be as bad as KEA.
Can someone please explain the logic of this?
As discussed at https://forum.opnsense.org/index.php?topic=40899.0 - there is no integration available in ISC DHCP / Kea and Unbound for this (unlike e.g. dnsmasq which can be used as DNS and DHCP server, though not in OPNsense; or Active Directory with secure DNS updates). The things implemented are just hacks.
ISC DHCP is abandoned upstream.
> there is no integration available in ISC DHCP / Kea and Unbound for this
What are you referring to? I was talking about multiple things. The discussion you referenced does not apply to any of them. Or at least I don't see the connection.
I am referring to this:
Quote
The fact that a reload is done when applying changes to static mappings is a basic feature. This should not be removed from ISC but added to KEA.
Kea is a DHCP server. It does NOT handle any DNS registration and integration. Neither does ISC. I'd hazard to guess that OPNsense developers are not willing to waste time inserting more glue such as "if Kea is in use, do not reload Unbound because nothing changed there regarding DNS when some (static) leases got configured, only do it for ISC. And perhaps when switching the implementations from ISC to Kea but not the other way round... and... perhaps in this case also. And not in this one."
As for the rest - ISC is EOL-ed upstream. You need to start somewhere when replacing it. The functionality in that's currently there is more than enough for majority of uses and simple use cases. If you need something else, well, perhaps you should use something else as your DNS server. In corporate environment, you'd run the AD-integrated DNS normally, nor Unbound as your authoritative DNS for your LAN domains.
Additionally - noone is forcing you to migrate anything
right now. 🤷♂️
Quote from: doktornotor on July 28, 2024, 01:53:11 PM
Kea is a DHCP server. It does NOT handle any DNS registration and integration. Neither does ISC.
But ISC does via RFC 2136 dynamic updates. If only someone would implement that ... too late, now.
Maybe some time in the future. It needs the matching feature on the DNS server side, of course. I don't know if that is present in Unbound. It definitely is in BIND.
Quote from: Patrick M. Hausen on July 28, 2024, 01:56:53 PM
Maybe some time in the future. It needs the matching feature on the DNS server side, of course. I don't know if that is present in Unbound. It definitely is in BIND.
It does not exist in Unbound and is explicitly something out of the scope of its development.
Quote
RFC 1995, 1996, 2136: not authoritative, so no AXFR, IXFR, NOTIFY or dynamic update services are appropriate.
https://github.com/NLnetLabs/unbound/blob/master/doc/FEATURES
I do understand that KEA is a bare DHCP server.
However, when I use an ASUS router or a fritzbox (or any router out there) and use the DHCP, the hostnames are registered and thus reachable via its DNS. I think I should be able to hope for the same functionality in OPNsense.
I seriously do not want to setup my own DHCP/DNS in my home network when it was working fine until now with ISC DHCP and unbound.
what about kea-dhcp-ddns? Based on kea docs they have solution for this to be done.
https://kea.readthedocs.io/en/kea-2.4.0/arm/ddns.html
I'm running samba-ad-dc with bind9 dlz backend integration and need in production authoritative dns updates of kea dhcp leases.
Just wanted to add that I completely understand your intention, I started exploring KEA on Debian today and the result so far is that it is buggy and unstable. I have no concerns that it will be replaced in the production version anytime soon.
I still would appreciate if a dev could chime in. Am I so off base, asking for a feature that every router out there has?
The issue is that I remember that a dev mentioned that KEA might never reach feature parity with ISC.
I don't need this now. What I would kindly ask though is that before ISC is removed from OPNsense, a true replacement is available and working. And I do include registering DHCP hostnames in the DNS subsystem in this conversation.
I'm puzzled too - I don't understand implementing KEA when it doesn't match functionalities in ISC. Issues in 24.7 with OpenVPN UDP server (at least in my case) plus removing functionality in ISC dhcp in 24.7 made me reverting upgrade back. to version 24.1.10...
Quote from: GreenMatter on July 29, 2024, 04:36:20 PM
I'm puzzled too - I don't understand implementing KEA when it doesn't match functionalities in ISC.
https://www.isc.org/blogs/isc-dhcp-eol/
Being an open-source developer is truly a labor of love. If KEA was implemented in a big-bang a year from now, people would complain that it was taking too long. If KEA is implemented in phases, then people complain that it is not feature complete.
I trust the OPNsense devs to make the right calls. I doubt ISC is going to be removed until KEA is at or near feature parity. In the meantime, keep using ISC until KEA has the features you need. I switched over to KEA this week and it is working without problems.
@julsssark I could not agree more.
But for the sake of proper terminology: it is not KEA that is lacking features compared with ISC-DCHPd, it is the integration of KEA into OPNsense which is not yet feature complete.
Both ISC-DHCPd and KEA are third party products. If there really are features entirely lacking in KEA we could complain and argue on the forum all we want, nothing would be going to change. The feature set of KEA is decided by a semi-open source (they have paid closed source modules if I am not mistaken) project entirely independent from OPNsense.
Kind regards,
Patrick
Thanks Patrick for clarifying my comment. That is what I intended.
Except that we tried to add e.g. DHCP option support but it did not work as documented by Kea. The code is on GitHub, maybe somebody knows.
Cheers,
Franco
Still using ISC on 24.1.10-x here.
I'm still a bit confused by all this, as OPNSense abstracts enough of it away I suppose I'm not sure what's going on under the hood when I do the following:
- Find a host in the leases list that I want to assign a static DHCP reservation.
- Assign that reservation by hitting the [ + ] button on that row and adding the IP, description, etc.
- Save changes
- On list of leases, heed the warning to hit the [ APPLY ] button to make the changes take effect.
I have always assumed that last step restarts ISC or reloads the config for ISC. All I know is that when I do the above, my static reservation now works as expected as soon as I do a DHCP refresh on the client.
What is going to change, if anything, in the above process when switching to Kea?
Nothing changes with DHCP functionality with either Kea or ISC. What changes is that ISC will no longer forcefully restart DNS services which dates back to code written many many years ago before common subsystems existed for lease registration purposes, but this edge case is highly conditional leading to an unconditional interruption of everone's DNS service capability of resolving.
Kea never restarted DNS services. So now ISC was forced into feature parity. If you edit static mappings and use DHCP registration in DNS services Unbound or Dnsmasq simply restart your DNS service at the earliest convenience to allow your new static lease(s) to be resolved by clients.
Cheers,
Franco
Thanks!
I use the default unbound. Just to clarify:
> If you edit static mappings and use DHCP registration in DNS services Unbound or Dnsmasq simply restart your DNS service at the earliest convenience to allow your new static lease(s) to be resolved by clients.
I didn't have to manually restart unbound before when setting up a static mapping for a lease. I assume ISC/some other component restarted Unbound when I hit the [ APPLY ] button in the GUI?
Quote from: Sinister Pisces on July 29, 2024, 10:14:45 PM
I didn't have to manually restart unbound before when setting up a static mapping for a lease. I assume ISC/some other component restarted Unbound when I hit the [ APPLY ] button in the GUI?
Yes it did. And it doesn't anymore, because interrupting DNS service for the entire office when the admin adds a new static DHCP mapping is (reasonably so, in my opinion) considered worse than not having that static mapping in DNS for some time. Restart Unbound at the earliest convenience as @franco put it.
Patrick
Quote from: Sinister Pisces on July 29, 2024, 10:14:45 PM
Thanks!
I use the default unbound. Just to clarify:
> If you edit static mappings and use DHCP registration in DNS services Unbound or Dnsmasq simply restart your DNS service at the earliest convenience to allow your new static lease(s) to be resolved by clients.
I didn't have to manually restart unbound before when setting up a static mapping for a lease. I assume ISC/some other component restarted Unbound when I hit the [ APPLY ] button in the GUI?
I think you're misunderstanding. If you set a static lease, and all you want is for that IP to be assigned to the client you have to do nothing more.
If you set a static lease, and subsequently want to refer to that client by it's host name, rather than IP, then you need to restart your DNS service so it 'picks up' the new host/lease.
To solve @Tessa original post, can the DNS service be restarted via API? I understand the original use case was to set static addresses via Terraform and have DNS resolve the new hostnames.
I held out on migrating from ISC to KEA during the 24.1 train up until now, and have completed the migration successfully. Admittedly I do not have any fancy DHCP options setup such as pointing to a UniFi controller, its a pretty basic setup with a handful of reservations.
I understand OP's concerns but I haven't heard of the timeline for ISC to be officially cut from a release, so having at least a year to figure out your migration (even if it means migrating to an external DHCP server) is friendly enough IMO.
Regarding the change to how ISC updates restart the DNS service, I was doing that anyways. It definitely should not reload my DNS (thus flushing my cache) without me explicitly wanting to do so.
Glad to be on it prior to the major upgrade. Depending on how things shake out I will probably wait for 24.7.2 before upgrading, just to be on the safe side.
Quote from: julsssark on July 29, 2024, 11:16:46 PM
To solve @Tessa original post, can the DNS service be restarted via API? I understand the original use case was to set static addresses via Terraform and have DNS resolve the new hostnames.
Yes, the services handling has MVC/API support since 23.1.5. With Kea you can automate the lease creation as well so in theory you don't even have to open the GUI to do it compared to ISC which will likely remain a static PHP page without API.
Cheers,
Franco
Thanks Franco.
> If you edit static mappings and use DHCP registration in DNS services Unbound or Dnsmasq simply restart your DNS service at the earliest convenience to allow your new static lease(s) to be resolved by clients.
I know this is not an OPNsense issue, but I don't understand why these DNS servers don't support a reload of the config w/o restarting the service. There is no logical reason to require a restart to read a new config or add new dns entries these days.
> With Kea you can automate the lease creation as well so in theory you don't even have to open the GUI to do it compared to ISC which will likely remain a static PHP page without API.
This is great news. Is that static lease then added to the DNS? If not, does the DNS have an API to do that? In that case it doesn't matter whether one has to make 1 or 2 API calls. I will certainly use this feature when I migrate to KEA in the future (when ISC is removed or feature parity exists). I always hoped this was possible with ISC.
I still believe that registering DHCP leases (dynamic and static) into the DNS should be considered a basic feature (when looking at pretty much any router out there).
Quote from: tessus on August 01, 2024, 01:56:59 PM
I know this is not an OPNsense issue, but I don't understand why these DNS servers don't support a reload of the config w/o restarting the service. There is no logical reason to require a restart to read a new config or add new dns entries these days.
Aha, this is the million dollar question! Take the main DNS services Dnsmasq and Unbound..
https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
When it receives a SIGHUP, dnsmasq clears its cache and then re-loads /etc/hosts and /etc/ethers and any file given by --dhcp-hostsfile, --dhcp-hostsdir, --dhcp-optsfile, --dhcp-optsdir, --addn-hosts or --hostsdir. The DHCP lease change script is called for all existing DHCP leases. If --no-poll is set SIGHUP also re-reads /etc/resolv.conf.
SIGHUP does NOT re-read the configuration file.(emphasis mine on the last part)
Unbound project is how old? 1.0.0 was released in 2008 according to Wikipedia and in 2024 someone started to actually work on a fast reload!
https://github.com/NLnetLabs/unbound/pull/1015
It's not yet merged but at least this is progressing.
Without a way to reload, a stop/start/restart will always be counter-productive with DNS servers.
Quote from: tessus on August 01, 2024, 01:56:59 PM
This is great news. Is that static lease then added to the DNS? If not, does the DNS have an API to do that? In that case it doesn't matter whether one has to make 1 or 2 API calls. I will certainly use this feature when I migrate to KEA in the future (when ISC is removed or feature parity exists). I always hoped this was possible with ISC.
As mentioned static leases of Kea are being fed to Dnsmasq/Unbound when requested in its setting. The import is automatic, but requires a restart of the DNS service when this static lease list is modified.
Quote from: tessus on August 01, 2024, 01:56:59 PM
I still believe that registering DHCP leases (dynamic and static) into the DNS should be considered a basic feature (when looking at pretty much any router out there).
Business wise most likely not. Much of that world is hooked on Microsoft anyway. And if you look at how rigid DNS servers are built you quickly see that they have no need for much dynamic shenanigans however useful an invididual user might see this. The DNS server authors drive this whole discussion. At least Bind does have dynamic DNS support... hopefully ISC will not deprecate Bind too ;) But you see Bind has been removed from operating systems because of its security issues and Bind was never a core service for us and likely never will be.
Cheers,
Franco
Thanks a bunch for the reply.
Quote from: franco on August 01, 2024, 02:08:17 PM
Take the main DNS services Dnsmasq and Unbound..
I worked for Tucows and we used PowerDNS and DNSdist I am not too familiar with dnsmasq and Unbound, except that I am using pi-hole which uses dnsmasq. Btw, my pi-hole queries OPNsense for local resolution.
Quote from: franco on August 01, 2024, 02:08:17 PM
When it receives a SIGHUP, dnsmasq clears its cache and then re-loads /etc/hosts and /etc/ethers and any file given by --dhcp-hostsfile, --dhcp-hostsdir, --dhcp-optsfile, --dhcp-optsdir, --addn-hosts or --hostsdir. The DHCP lease change script is called for all existing DHCP leases. If --no-poll is set SIGHUP also re-reads /etc/resolv.conf. SIGHUP does NOT re-read the configuration file.
Well, in this case a re-read of the config file is not necessary. Since I am not too familiar with the 2 DNS servers you mentioned I thought the static leases are put into the config. But it seems other files can be read on SIGHUP.
So adding dns data from the DHCP should be hot-reloadable (via SIGHUP) according to the text above.
Quote from: franco on August 01, 2024, 02:08:17 PM
Unbound project is how old?
I don't think that it matters how old SW is. It's always possible to re-work core features when the market requires it. 30 years ago nobody was too concerned about having to restart a service. These days people expect easy config management, HA, and dynamic updates.
Old code does not necessarily mean dumb design. And if the design was fairly good, extending the code to support something like this shouldn't be too complicated.
Quote from: franco on August 01, 2024, 02:08:17 PM
Without a way to reload, a stop/start/restart will always be counter-productive with DNS servers.
!00% agree with you there. However, in a DNS cluster this should be less of an issue.
Quote from: franco on August 01, 2024, 02:08:17 PM
The import is automatic, but requires a restart of the DNS service when this static lease list is modified.
This certainly sucks. One can only hope that the DNS server will improve in that regard.
Quote from: franco on August 01, 2024, 02:08:17 PM
Business wise most likely not. Much of that world is hooked on Microsoft anyway.
I agree to disagree on those 2 points. (Although any further discussion on that part, I'd rather do with a few beers and in person.)
Quote from: franco on August 01, 2024, 02:08:17 PM
And if you look at how rigid DNS servers are built you quickly see that they have no need for much dynamic shenanigans however useful an invididual user might see this.
It all depends on the DNS server. As I mentioned before, PowerDNS and DNSdist to the rescue. ;-)
> So adding dns data from the DHCP should be hot-reloadable (via SIGHUP) according to the text above.
Fair enough. That is how dynamic leases are implemented in OPNsense for Dnsmasq. The note about bouncing the cache is the second most problematic thing even with SIGHUP. All of these behavioural oddities are going to be disliked by someone out there.
https://github.com/opnsense/core/blob/master/src/opnsense/scripts/dhcp/dnsmasq_watcher.py#L97
> I don't think that it matters how old SW is. [...]
You're missing the point. The point is that DNS servers are not considering themselves to be the most flexible. At least not the ones in core.
> However, in a DNS cluster this should be less of an issue.
Then again, OPNsense is not a DNS cluster.
> It all depends on the DNS server. As I mentioned before, PowerDNS and DNSdist to the rescue. ;-)
People have added Bind and Dnscryptproxy over the years as plugins but never took an extended interest PowerDNS et al. We have/had packages for them but that's about it. With so many options to chose from I think there will always be some feature set overlap and individual outliers.
This is also very peripheral to the Kea discussion.
Cheers,
Franco
A patch is being worked on to enable the feature!
https://github.com/opnsense/core/pull/7362
:)
This topic was already referring to that PR in a way... The topic never stated that it wasn't possible to register static mappings.