puzzled by the ISC/KEA DHCP direction

[franco]

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

[Sinister Pisces]

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?

[franco]

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

[Sinister Pisces]

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?

[Patrick M. Hausen]

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

[Taunt9930]

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.

[julsssark]

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.

[saulsutherland]

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.

[franco]

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

[julsssark]

Thanks Franco.

[tessus]

> 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).

[franco]

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.

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.

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

[tessus]

Thanks a bunch for the reply.

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.

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.

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.

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.

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.

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.)

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. ;-)

[franco]

> 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

[mimizone]

A patch is being worked on to enable the feature!
https://github.com/opnsense/core/pull/7362

:)