25.1.6 - DNS/DHCP best practice

[OPNenthu]

This is of course secondary to the core functionality, but I was wondering if at some point DNSmasq and/or Kea might gain the Status, State and Lease Type columns that are present in ISC?  I rather like those, especially the green/red Status indicator.

Higher priority (for me, at least) is being able to set DHCP Option 43 for my UniFi console.  I appreciate that there's focus on it already in this thread :)

[rolsch]

The goal for 25.7: Dnsmasq DHCP/RA for small and medium deployments and Kea/Router Advertisements (radvd) for bigger deployments (requiring seamless HA support).

The docs are in the works, but we also need a bit more code glue for 25.7 and 26.1 to make the most of these transitions.

But TLDR: nothing changes for users. Anyone can use what they want. Even ISC for the forseeable future (2-5 years).


Cheers,
Franco

I would like to have a smart migration path from ISC to xy in opnsense as I have many MAC addresses statically mapped in ISC ;-)
- maybe as ontime script from console...

[RamSense]

There is. I just converted my system from isc to kea.
For ipv4 this tool was VERY helpfull: https://github.com/EasyG0ing1/Migration/
For static ipv6 I had to enter them manually, but worked fine also.
Migration took only about 15 minutes because of this manual part for v6. I only use dynamic on the guest network.

I do not use DNSmasq, I only use BIND. (Opnsense - KEA DHCP4 and DHCP6 with Router Advertisements (radvd), and for DNS - Adguard Home -> bind on opnsense)

[IsaacFL]

But now a new issue: how do i get reverse lookups working with dnsmasq?

For reverse dns, I added an 2 additional forwards to Services: Unbound DNS: Query Forwarding

I use the 10.0.0.0/8 for my local addresses, so
    <enabled>1</enabled>,
    <domain>10.in-addr.arpa</domain>
    <server>127.0.0.1</server>
    <port>53053</port>

I did the same for my ipv6, redacted:
          <domain>x.x.x.x.x.x.x.x.x.x.x.3.0.6.2.ip6.arpa</domain>
          <server>127.0.0.1</server>
          <port>53053</port>

[Monviech (Cedrik)]

@Issac thanks

https://github.com/opnsense/docs/issues/724

[tessus]

With a lot of effort due to my big number of static reservations, I have now made the shift from ISC DHCP / Unbound to DNSmasq "only". Radvd is still in effect, since I use no DHCPv6. Thanks to ChatGPT for helping me to write the programs to extract the CSVs from the configuration XML for both the static reservations plus the DNS mappings and aliases.

@meyergru Any chance you could make these scripts available via a github repo?

I am currently using ISC DHCP / Unbound myself (only v4 - no v6 at all) and I have been quite happy with it. Although the fact that ISC is no longer maintained is a pitty and makes me slightly nervous.

However, I do have a high number of static mappings (as you have). I use around 20 VLANs, but the most mappings are distributed between 3 of them. In my Unbound I have set about 18 overrides with a select few of them having 2-3 aliases. (Thus those are not that hard to recreate manually if need to be.)

One of the very few things that irked me for years has been the problem that I couldn't set a static mapping via an API call. e.g. when creating a VM via TF (or Pulumi, or whatever tickles your fancy, or even manually), it would be great to set a static mapping and when decommissioning the same VM, remove the mapping again. Afaik a lot of services got an API (kudos to the devs), but I haven't seen anything for ISC, thus moving to dnsmasq might be a good choice.
I think to remember a few years ago, the devs were suggesting to migrate to Unbound from dnsmasq (or maybe this was just for one issue in one forum topic), but it seems now it's the other way around. I don't really mind, as long as there is some workable migration. By "workable" I mean in an automated fashion that does not require me to recreate all settings, DHCP ranges, static mappings, and whatnot manually.
On the other side, if it absolutely has to be I probably can invest 5 or 6 hours to manually to do all this. The problem is that this process is rather error prone - manual work always is.
I have also noticed that some VMs (even though they are sending a hostname) get a DHCP address (no static mapping) but are not registered in the DNS. I am not sure why this is happening, but I think this started with 25.1. Either way, moving to dnsmasq might fix that as well.

Anyway, long story short, it would be great to use scripts to migrate to test dnsmasq only. If it doesn't work as I hope, it should be fairly easy to restore a backup and just use ISC/Unbound for now...

[tessus]

For reverse dns, I added an 2 additional forwards

Oh, wait. Does this mean that you cannot use dnsmasq only (for DHCP and DNS), if you want a working reverse DNS, in which case you have to use Unbound as well?

[nautilus7]

Is anyone going to fix the version typo on the title of this thread?

[kasper93]

I believe it's unbound because when running a nslookup on my windows machine to a host that is in unbound's overrides, it times out twice before finally succeeding, suggesting unbound is choking on...something because it's a local lookup to unbound.

I'm seeing the same thing. I think current documentation is incomplete in a way of setting up this unbound to dnsmasq forward. And in fact I don't even see how it suppose to work in practice. Symptoms are like @Unspec described, timeouts and generally instability, it sometimes works, other times does not. It queries unbound multiple times, also with host.lan.internal.lan.internal.

If you think about it, unless I'm missing something it is lucky it even manages to return anything sometimes, breaking recursion.

If dnsmasq dns is set on alternative port, it will forward queries back to unbound which is main dns server. Unbound then sees that this query should be forwarded (back) to dnsmasq, which ask unbound again... and we get infinite recursion. I hope I missed something in configuration, because as it stand now it hardly can work like that.

[meyergru]

@meyergru Any chance you could make these scripts available via a github repo?

Here is the link:

https://github.com/meyergru/iscdhcp_to_dnsmasq

As for the problems: You can do one of two things:

1. Use dnsmasq as your sole DNS service - especially for the DHCP reservations and leases. While it cannot do recursive name resolution, most people do not even need that. You could just use your system name servers and that works just fine.

2. If you absolutely want to use another DNS service for resolving internet names, you will have to configure DNSmasq and Unbound on different port and point one to the other (IDK what the official recommendation for that is), but beware of using port 5353, because that is also used by the mDNS-Repeater. There fore, I use 5454 for that.

P.S.: Instead of Unbound, you can also use os-dnscrypt-proxy in order to use DoH. There is a problem with forwarding domains to other servers that do not run on port 53, but that will soon be fixed.

The logic behind all of this is always the same: Have one DNS service do internet resolution and one for DHCP naming (the latter being DNSmasq). The one running on port 53 is the one you are querying from your LAN. It is up to you if you plainly cascade the services or if you forward your local zones to DNSmasq - both approaches work.

There were some early problems with firewall rules not being applied after enabling the checkbox, I expect a hotfix for that at some point.

[agh1701]

The goal for 25.7: Dnsmasq DHCP/RA for small and medium deployments and Kea/Router Advertisements (radvd) for bigger deployments (requiring seamless HA support).

The docs are in the works, but we also need a bit more code glue for 25.7 and 26.1 to make the most of these transitions.

But TLDR: nothing changes for users. Anyone can use what they want. Even ISC for the forseeable future (2-5 years).


Cheers,
Franco

So, making the switch now to Dnsmasq DHCP/RA and Unbound mite no work as we think until 25.7 I.E. missing glue.

[gstyle]

Is anyone going to fix the version typo on the title of this thread?

Sorry ;)
Done

[julsssark]

I made the switch from Kea v4 to DNSMasq v4 and everything seems to be working correctly. I have a half-dozen vlans and use clients->AdGuard->Unbound for DNS. Look ups from Unbound to DNSMasq for dynamic hosts are working. I followed the configuration example in the docs. The hardest part (and it was not a big deal) was doing the export of Kea reservations and reordering/renaming the columns so that they matched the import for DNSMasq.

Thank you OPNsense team for continuing to improve this amazing software!

[tessus]

Here is the link:

Thanks a bunch for the scripts.

Well, my DNS setup is a bit different than probably most people have:

I use a pi-hole keepalived cluster and most VLANs must use that cluster for DNS resolution (via an outbound NAT rule). The only time the Unbound DNS is used is for local address resolution via conditional forwarding on pi-hole.
My OPNsense Unbound can theoretically also forward queries to upstream servers, but I could turn that off, since I do not use Unbound, except for local addresss resolution (standard and reverse, which is however initiated from pi-hole). No machine is using OPNsense's Unbound directly - ever.
A few dedicated machines in certain VLANs are allowed to use external DNS servers directly. All others use my pi-hole cluster even if they have set external DNS servers.

As for DoH, I am not using it - for now. I might be doing so in the future though.

So my use-case is rather easy. I need my OPNsense's DNS (whatever that might be) for local address resolution only. However, I also need reverse lookup. I think I've read that I would have to add 2 forwards to DNSmasq, which in turn would require me to run Unbound as well for the reverse lookup. This makes this simple setup less simple, because I would have to run 2 DNS services on OPNsense instead of just one.
I have to look into this before I migrate to DNSmasq.

[RES217AIII]

I'm a typical OPNsense user managing a home network and a small business environment. As a non-expert network engineer, I'm genuinely grateful for how reliably and efficiently OPNsense runs. Much of this is thanks to the outstanding work of the OPNsense developers and the helpful community here in the forum.

After the deprecation of ISC DHCP, I migrated to Kea. The transition was seamless, and my setup has continued to work flawlessly ever since.

Here's what my configuration looks like:
- **Clients** receive **IPv4 addresses via Kea DHCP**.
- **IPv6 addresses** are assigned via **SLAAC** using router advertisements.
- **DNS** is handled through **AdGuardHome** (for filtering), and **Unbound** for DNS-over-TLS.

Important clients in my LAN/VLANs have **static leases** via Kea, and I use those for internal DNS assignments. Since my network doesn't undergo significant dynamic changes, I don't currently require DDNS.

That said, I'm following this discussion with interest — not because I'm facing any issues now, but because I'm thinking ahead. The deprecation of ISC DHCP seems to have triggered a broader strategic discussion about the default DHCP system in OPNsense.

My concern is whether Kea will continue to be supported and actively integrated into OPNsense, or whether it will fall to a lower priority in favor of dnsmasq — even though dnsmasq itself hasn't seen much development since 2024 and may not be as future-proof.

I'm very happy with my current setup and could certainly continue using it as-is. But I wonder: why not make Kea more accessible for small environments by focusing the GUI integration on the most common use cases? For example, DDNS support could be added via a simple checkbox to enable the Kea D2 module. The user would just enter a BIND server address and a TSIG key name — no full mapping of all Kea capabilities would be needed in the GUI.

I don't know how much development effort this would take — and that may be the limiting factor — but from a user's perspective, such a step would make Kea much more approachable and clearly position it as the forward-looking standard in OPNsense.