I'm running 25.1.7_4 and looked at the settings for Dnsmasq DNS & DHCP. My current Unbound DNS does not do query forwarding and I currently do not want to do that with dnsmasq either.
However, if I wanted to do so, how would I specify the upstream DNS servers? There is nothing to set in the options.
Also, there is no way to enable/disable query forwarding, so what does dnsmasq do? I don't see, whether it is active or not. Is it enabled or not? This all is very confusing.
These are the only options one can set for query forwarding:
qf-options.png
DNSmasq always forwards, because it does not support recursion. I assume it uses the servers set in System > Settings > General, but I am not 100% sure. About the first sentence I am. Not forwarding is simply not an option. Only Unbound and BIND can do that.
You can only selectively limit what DNSmasq forwards, i.e. private reverse lookups and with an upcoming patch (3b8e4a6, I think it is not yet in 25.1.7_4), also for the domains that have been used in DHCP ranges. Everything else will be asked from upstream servers.
As Patrick said, these are the ones from the system settings plus 127.0.0.1 as upstream servers, which could be Unbound, if you follow the recommendations in the docs. If you remove all system nameservers, then only 127.0.0.1 will be used.
Thanks for the replies.
Unfortunately this logic makes it impossible for me to replace unbound/isc with dnsmasq. Imagine my opnsense system specifies my pihole as the upstream dns. Then my pihole (which is set and used by all my clients) asks via conditional forwarding dnsmasq on opnsense for internal address resolution. If anything goes wrong here, and we all know that can happen and has happened in the past (due to bugs, misconfig, and whatnot), there's an infinite query loop.
As mentioned before, I need dnsmasq (as my current unbound) for internal address resolution only. If I cannot configure dnsmasq to do just that, I cannot use it.
This also means that I cannot migrate from ISC to dnsmasq (dhcp only), because I still need dnsmasq to do local address resolution. dnsmasq dhcp does not register the leases with Unbound but with dnsmasq only. So I still need Unbound which then asks dnsmasq, which then could still ask my pihole - there's the infinite loop again. The same is true, if I were to use 127.0.0.1 in an Unbound/dnsmasq or dnsmasq-only scenario.
I know that dns resolvers have a bunch of settings to mitigate such loops, but when I currently go through the stack and its options, nothing seems to apply.
It should be easy to add a GUI option to tell dnsmasq not to forward queries at all. I know that it is possible to configure dnsmasq not to forward queries. opnsense just needs to create an option for that.
It has been added but its not in a release yet.
You can patch it in from the opnsense shell with:
opnsense-patch https://github.com/opnsense/core/commit/220dbc7931e11c71587734ed9c1731abdf9eaff8
opnsense-patch https://github.com/opnsense/core/commit/3b8e4a6ab6f74c24eca3b34d8ae0370a4ce494b8(make sure you are on 25.1.7_4)
Read the links for descriptions of what is added.
Quote from: tessus on May 26, 2025, 06:26:01 PMIt should be easy to add a GUI option to tell dnsmasq not to forward queries at all. I know that it is possible to configure dnsmasq not to forward queries. opnsense just needs to create an option for that.
"Not at all" is somewhat relative:
The two patches @Monviech mentioned ought to make sure, that there will be no default upstream requests and also none for the DHCP range domain names. I have some host definitione with domain names that are not within my DHCP ranges (I use them for remote VPN IPs). When such domain names get appended by Windows via the DNS search list, then there will still be requests for something like "www.google.com.internal-vpn", which still get forwarded by DNSmasq to upstream servers, if they are configured.
You could just drop all domains into a custom override file, dnsmasq has a custom import folder.
Check how adblocking works:
https://github.com/hagezi/dns-blocklists/blob/main/dnsmasq/anti.piracy.txt
You can just throw that into the import folder and it will "block" all of these local domains. Same as if you need some custom ones yourself, just create a file like this.
I know that, but I would have liked a GUI input with a plain list of domains to add with local=/domain/ definitions without any need to have either external (i.e. Unbound forward domains) or "internal" (i.e. DHCP range domains, like you implemented it) dependency - following your and Franco's approach to keep it to the tool itself and not integrate multiple tools to solve a specific application need.
You could still add that on top.
If you just want a HostnameField in the (advanced) general settings you can open an issue on github. Should be simple to add. Though we first need to discuss it like all additions.
Done. (https://github.com/opnsense/core/issues/8726)
Should the two patches @Monviech mentioned also correct reverse lookups? In my case, following the configuration (Dnsmasq and Unbound) in the doc, reverse lookups are failing still (forwards are now working tho).
Did you do a custom forward in Unbound for "...168.192.in-addr.arpa" (or whatever you use) to DNSmasq? This is shown in the configuration examples.
Also, you will have to check "Do not forward private reverse lookups" in DNSmasq.
Yes, I have Dnsmasq DNS do not forward reverse + system dns servers (no dns servers are configured at system level) and Unbound custom forwards configured for each of my subnets.
What i have also observed is that the forward and reverse lookups work initially after service restarts or firewall reboot only for a short time, then I start receiving NXDOMAIN.
Pending your response, I'm thinking I may need to redo my configs from scratch to make sure I haven't misconfigured something since I have been trying to get this working over the past week (static and dynamic leases are working as expected, it's just the name resolution are not).
There is a lot going on between Unbound and DNSmasq with DNS names and forwarding and with FQDN vs. plain names, because at times, they plan ping-pong if configured incorrectly. I had all kinds of strange things going on when that happened.
If you want to check that out, you can track this down to whether DNSmasq or Unbound is the culprit by using:
# nslookup
> set port=53053
> server 127.0.0.1
and only then start entering DNS names. By doing this, you ask DNSmasq directly. Unbound can only work with what it gets from DNSmasq for delegated domains. Also try out what happens, when you ask for names that do not exist. If DNSmasq returns REFUSED instead of NXDOMAIN, Unbound will deliver a SERVFAIL. That in turn may lead to timeouts, if system nameservers are configured.
Also, you can look at /var/etc/dnsmasq-hosts to see if your DHCP host entries are there, including their all aliases.
Quote from: meyergru on May 26, 2025, 08:57:22 PMDone. (https://github.com/opnsense/core/issues/8726)
Nice one, thank you, @Monviech: Your solution here (https://github.com/opnsense/core/pull/8730) is even better and it works, too (I just tried). I also updated the helper scripts (https://github.com/meyergru/iscdhcp_to_dnsmasq) to reflect the CSV structure change that goes along with it (hoping to see this change in an upcoming release).
Thanks for testing it, it looked like a neat spot to put it.
Now we should have most bases covered.
@meyergru post #13 - querying dnsmasq directly using "dig" from my laptop (MacBook) with the port (53053) and server (192.168.31.1 in my case) worked as expected, short and fully qualified names, including reverse lookups. I confirmed /var/etc/dnsmasq-hosts contain the expected static assignments as well.
√ ~ % dig -p 53053 @192.168.31.1 kmbpro
; <<>> DiG 9.10.6 <<>> -p 53053 @192.168.31.1 kmbpro
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36073
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;kmbpro. IN A
;; ANSWER SECTION:
kmbpro. 1 IN A 192.168.31.20
;; Query time: 9 msec
;; SERVER: 192.168.31.1#53053(192.168.31.1)
;; WHEN: Tue May 27 20:02:40 EDT 2025
;; MSG SIZE rcvd: 51
dig -p 53053 @192.168.31.1 kmbpro.mgmt.internal
; <<>> DiG 9.10.6 <<>> -p 53053 @192.168.31.1 kmbpro.mgmt.internal
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22263
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;kmbpro.mgmt.internal. IN A
;; ANSWER SECTION:
kmbpro.mgmt.internal. 1 IN A 192.168.31.20
;; Query time: 9 msec
;; SERVER: 192.168.31.1#53053(192.168.31.1)
;; WHEN: Tue May 27 20:42:43 EDT 2025
;; MSG SIZE rcvd: 65
dig -p 53053 @192.168.31.1 -x 192.168.31.20
; <<>> DiG 9.10.6 <<>> -p 53053 @192.168.31.1 -x 192.168.31.20
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10355
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;20.31.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
20.31.168.192.in-addr.arpa. 1 IN PTR kMBPro.mgmt.internal.
;; Query time: 9 msec
;; SERVER: 192.168.31.1#53053(192.168.31.1)
;; WHEN: Tue May 27 20:02:06 EDT 2025
;; MSG SIZE rcvd: 89
doing the same query without pointing directly to dnsmasq always fails on short names and reverse lookups, whereas FQDN works occasionally, otherwise also fails with NXDOMAIN
dig kmbpro
; <<>> DiG 9.10.6 <<>> kmbpro
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53396
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;kmbpro. IN A
;; AUTHORITY SECTION:
. 1562 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2025052702 1800 900 604800 86400
;; Query time: 17 msec
;; SERVER: 192.168.31.1#53(192.168.31.1)
;; WHEN: Tue May 27 20:45:49 EDT 2025
;; MSG SIZE rcvd: 110
dig kmbpro.mgmt.internal
; <<>> DiG 9.10.6 <<>> kmbpro.mgmt.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22874
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;kmbpro.mgmt.internal. IN A
;; ANSWER SECTION:
kmbpro.mgmt.internal. 1 IN A 192.168.31.20
;; Query time: 11 msec
;; SERVER: 192.168.31.1#53(192.168.31.1)
;; WHEN: Tue May 27 20:47:56 EDT 2025
;; MSG SIZE rcvd: 65
√ ~ % dig -x 192.168.31.20
; <<>> DiG 9.10.6 <<>> -x 192.168.31.20
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43607
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;20.31.168.192.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 16 msec
;; SERVER: 192.168.31.1#53(192.168.31.1)
;; WHEN: Tue May 27 20:48:10 EDT 2025
;; MSG SIZE rcvd: 114
I believe I have things configured consistent with the online doc examples (see screenshots below)
Am I missing something in unbound configuration or is this a possible bug?
(https://raw.githubusercontent.com/kstamand/opnsense-dnsmasq/master/Dnsmasq-General.png)
(https://raw.githubusercontent.com/kstamand/opnsense-dnsmasq/master/Dnsmasq-DHCP-Hosts.png)
(https://raw.githubusercontent.com/kstamand/opnsense-dnsmasq/master/Dnsmasq-DHCP-Ranges.png)
(https://raw.githubusercontent.com/kstamand/opnsense-dnsmasq/master/Unbound-DNS-Query-Forward.png)
Quote from: Monviech (Cedrik) on May 26, 2025, 08:10:58 PMYou can patch it in from the opnsense shell
Ah, nice. Thanks.
One last question: If I replace ISC/Unbound with dnsmasq and use dnsmasq to resolve my local hostnames, will reverse lookup also work? I never got an answer to my previous questions in other topics whether this works or not:
nslookup mymachine.lan.internal returns
192.168.2.5nslookup 192.168.2.5 returns
mymachine.lan.internal.P.S.: After all these discussions, maybe it is time for me to re-think my DNS strategy.
Currently I am using my pi-hole cluster directly (or via redirected means) and use opnsense's dns for local address resolution (via conditional forwarding from pihole). I can't recall in detail why I set it up this way years ago, but there must have been a very good reason. I faintly remember it was a workaround for an issue with pihole or opnsense (or a combination of both).
Anyhoo, IMO it is a better architecture to do it the other way around: use opnsense's dns and use the pi-hole cluster as upstream DNS. I guess I have some thinking and planning to do. I probably will change to this architecture when I migrate away from ISC/Unbound.
Thanks for all the interesting discussions around this topic.
@stumper: Judging from your statement about /var/etc/dnsmasq-hosts, I assume you applied the patches? But the last patch changes something in how this works by adding a "local" flag to the DHCP host entries.
I also had "Require domain", "Do not forward private reverse lookups" and "DHCP authoritative" checked in my DNSmasq settings, but I currently have deactivated DNSmasq and cannot test it. Maybe you should wait until the next release comes out.
There is a lot happening and there are quite some patches lined up that it is getting harder to add anything specifically. Waiting for a release is indeed a good choice.
Also, all hosts in the dnsmasq hosts file get turned into A, AAAA and PTR Records automatically by dnsmasq. So things /should/ work automagically.
@monviech and @meyergru thank your for your responses and will wait for next release
kind regards
Just to say that I am having the same issue as @stumper. DNS requests from Unbound to DNSmasq for local hostnames work intermittently. I have applied both patches but still the same issue. By enabling DNS query logging in DNSmasq, I've determined that when the problem occurs, Unbound is not forwarding the local queries to DNSmasq, instead trying to resolve them recursively (which results in NXDOMAIN since they are local names) despite the Unbound Forwarding configuration. There are no queries logged in the DNSmasq log. When it works, I do see the queries from Unbound in the DNSmasq log as expected.
So it seems that the problem is on the Unbound side, not DNSmasq.
Do these queries ask for names that are proper FQDNs including the local domain for which you configured the forwarding? If they ask for unqualified host names the behaviour you observe is expected. Servers do not append search/default domains. The client's resolver library is supposed to do that.
Yes, FQDNs for my local domain (which I've defined as home.lan). Sometimes these queries are forwarded properly from Unbound to DNSmasq, other times they are not. A restart of Unbound temporarily fixes the issue.
Technically in Windows, asking for unqualified host names is OK because Windows automatically appends the DHCP-configured search suffix (in my case home.lan). But I'm querying the FQDNs anyway just to make sure.
This leads to all sorts of LAN issues. For example, I have SMB shares configured on my PCs that point to the local name of my NAS storage. These shares don't work when the DNS lookups aren't working.
@stumper: first try to help and post here, so bear with me
1. Reverse lookups: dig -p 53053 @192.168.31.1 -x 192.168.31.20
your reverse resolution forward entries in unbound are probably wrong: I guess you wanna change *.198.* to *.192.in-addr.arpa . Furthermore your are probably better off with a single 168.192.in-addr.arpa. as I doubt you want to individually configure this on host level in your setup.
2. Forward lookups non-fqdn: dig -p 53053 @192.168.31.1 kmbpro
AFAIK dig doesn't add search domains (as nslookup would do) and kmbpro is something else than kmbpro.mgmt.internal . so unbound doesn't know to forward it to dnsmasq:53053 and fails resolving it on its own. just try dig kmbpro.mgmt.internal or use nslookup (and make sure your resolv.conf is ok on search domains)
3. Forward fqdn lookups working just occassionally:
I had the same issue with fqdns in my setup. digging a bit in the logs it seemed as if unbound and dnsmasq were ping ponging in some situations until something broke (esp. on AAAA entries). I was able to solve it in my setup by telling dnsmasq not to perform any further upstream resolution tries (create a file with the content as shown below + restart dnsmasq)
# cat /usr/local/etc/dnsmasq.conf.d/01_no-resolv.conf
no-resolv
I haven't tried the patches meyerguru and monviech have recommended but I guess they won't change anything about 1. and 2. .
@cinergi I understand why this is a problem. :-) So it looks like a bug. Maybe open an issue on github.
I don't use DNSmaq and probably never will. Kea and Unbound it is for me. I do not understand the motivation to bring in this piece of software, to be honest.
I think the problem is with the DNSmasq / Unbound interaction: I have observed, that when you ask DNSmasq for names it cannot resolve and which are not considered "local" (i.e. that DNSmasq does not think it is authoritative for), it returns REFUSED instead of the usual NXDOMAIN.
Alas, Unbound turns those answers into SERVFAIL and then thinks DNSmasq is broken. It then stops asking it for a short while, despite the custom forwarding it tells it do do so.
It all depends upon keeping DNSmasq from ever returning REFUSED answers. The problem here is that, e.g., Windows adds a DNS search domain to any DNS name it is asking for. So, if you ask for www.google.com, it may ask DNSmasq for www.google.com.internal. If that name is forwarded to DNSmasq, but not one of the "local" domains, the problem will occur.
@Monviech has changed the scheme on how to determine the "local" domains by his latest patch (https://github.com/opnsense/core/commit/4381fe4903ecbeff19ebd1e04b789628e51124ef) once again. It requires the user to mark at least one DHCP host entry from each forwarded domain to be marked as "local" (a new flag introduced by the commit).
But still: that commit is also not yet part of any release and you have to apply both previous patches in order first, therefore I am not showing how to do it. Just keep your patience and hope it will work. I have switched back to ISC DHCP / Unbound for the time being as I was struck by the same problem.
Why can't we get proper RFC 2136 integration of e.g. Kea and BIND? Problem solved. There is no need to have at least three different DNS servers. BIND does everything a DNS server can do.
Quote from: medivh on May 28, 2025, 07:51:29 PM3. Forward fqdn lookups working just occassionally:
I had the same issue with fqdns in my setup. digging a bit in the logs it seemed as if unbound and dnsmasq were ping ponging in some situations until something broke (esp. on AAAA entries). I was able to solve it in my setup by telling dnsmasq not to perform any further upstream resolution tries (create a file with the content as shown below + restart dnsmasq)
# cat /usr/local/etc/dnsmasq.conf.d/01_no-resolv.conf
no-resolv
I haven't tried the patches meyerguru and monviech have recommended but I guess they won't change anything about 1. and 2. .
I think that's exactly what one of those patches does: adds no-resolv to the default DNSmasq configuration in /usr/local/etc/dnsmasq.conf. Actually I don't know if it's added by those patches, but no-resolv is definitely there in the config file.
Quote from: medivh on May 28, 2025, 07:51:29 PMI haven't tried the patches meyerguru and monviech have recommended but I guess they won't change anything about 1. and 2. .
No, they don't - those problems must be addressed separately. And also, the first two patches are superseded by the latest patch, as explained.
@Patrick: I was not recommending DNSmasq (especially not at this time) - I will gladly use Kea once the missing options are build in... ;-)
P.S.: If you can live with upstream DNS servers without a full DNS resolver, just use DNSmasq alone, then none of the discussed interaction problems occurs.
Quote from: Patrick M. Hausen on May 28, 2025, 07:54:41 PM@cinergi I understand why this is a problem. :-) So it looks like a bug. Maybe open an issue on github.
I don't use DNSmaq and probably never will. Kea and Unbound it is for me. I do not understand the motivation to bring in this piece of software, to be honest.
The only reason (for me) is to enable local DNS resolution, since Unbound does not integrate with Kea. That's the only reason why I've been trying to make DNSmasq work. Otherwise I would happily use Unbound for DNS and Kea for DHCP.
Unbound and Kea do support resolution for static leases. I do not need dynamic ones unless it's finally implemented via the proper protocol as it (IMHO) should.
Quote1. Reverse lookups: dig -p 53053 @192.168.31.1 -x 192.168.31.20
your reverse resolution forward entries in unbound are probably wrong: I guess you wanna change *.198.* to *.192.in-addr.arpa . Furthermore your are probably better off with a single 168.192.in-addr.arpa. as I doubt you want to individually configure this on host level in your setup.
@medivh:
thanks for pointing out my mistake (case of tired eyes on my part), everything working as expected with that correction.
2. Short name resolutions - I also realized, after stepping away for a bit, that short name digs were not going to work no matter what.
3. With the patches applied and the Unbound query forwarding address correction, I have not received any intermittent resolution errors in the past hour.
@Patrick: Having Dnsmasq as an available option is good thing,
at least for my needs - once it is stable here, my goal is to retire Unbound and rely only on Dnsmasq for DHCP and DNS, with DNS blackhole capabilities added in (coming from an Asuswrt-Merlin home setup, I have been using Dnsmasq blackhole functionality for many years successfully and comfortably).
Thank you to all who have responded and provided very useful information!!
Quote from: meyergru on May 28, 2025, 07:55:30 PM@Monviech has changed the scheme on how to determine the "local" domains by his latest patch (https://github.com/opnsense/core/commit/4381fe4903ecbeff19ebd1e04b789628e51124ef) once again. It requires the user to mark at least one DHCP host entry from each forwarded domain to be marked as "local" (a new flag introduced by the commit).
But still: that commit is also not yet part of any release and you have to apply both previous patches in order first, therefore I am not showing how to do it. Just keep your patience and hope it will work. I have switched back to ISC DHCP / Unbound for the time being as I was struck by the same problem.
If I understand correctly, that latest patch adds a checkbox in the DNSmasq DHCP static host entries list enabling the host's configured domain to be designated as Local. But if I look in the DNSmasq configuration file /usr/local/etc/dnsmasq.conf, my local domain (I only have one) is already present there even without enabling that checkbox: local=/home.lan/ So I don't see how this patch would help in my case. There must be something else going on.
I've reverted to Unbound + ISC until the Unbound + DNSMasq solution is stabilized.
Quote from: Patrick M. Hausen on May 28, 2025, 07:54:41 PMI do not understand the motivation to bring in this piece of software, to be honest.
Quote from: stumper on May 29, 2025, 03:27:49 AMcoming from an Asuswrt-Merlin home setup
Bingo.
This is twice now I've seen recent comments referencing prior familiarity with some *WRT derivative as an argument for preferring Dnsmasq. We are likely sorting ourselves into camps: those favoring more professional setups, and those favoring home routers / embedded appliances.
I was debating with myself if maybe Dnsmasq was a play for smaller, resource constrained applications. Now I think it makes sense that it's more about familiarity and convenience (integration), because after all OPNsense runs a FreeBSD base on x86 hardware with (usually) multiple gigabytes of RAM. A resource constraint argument makes less sense here as compared to an embedded router OS.
Quote from: OPNenthu on May 29, 2025, 03:59:02 AMBingo.
This is twice now I've seen recent comments referencing prior familiarity with some *WRT derivative as an argument for preferring Dnsmasq. We are likely sorting ourselves into camps: those favoring more professional setups, and those favoring home routers / embedded appliances.
I was debating with myself if maybe Dnsmasq was a play for smaller, resource constrained applications. Now I think it makes sense that it's more about familiarity and convenience (integration), because after all OPNsense runs a FreeBSD base on x86 hardware with (usually) multiple gigabytes of RAM. A resource constraint argument makes less sense here as compared to an embedded router OS.
I would prefer a Kea + Unbound setup, since I see Kea as more robust and professional than DNSmasq. However, the Kea implementation in OPNsense lacks certain features that are important to me including support for custom DHCP options and registration of static and dynamic DHCP hostnames in Unbound. The pfSense folks seem to have done it already - see https://docs.netgate.com/pfsense/en/latest/services/dhcp/kea-settings.html. To the OPNsense folks - please, please consider doing the same!
There have already been efforts to have dynamic registration in unbound for KEA DHCP leases: https://github.com/opnsense/core/issues/7475
Unfortunately opnsense has closed this without any reason. Maybe the opnsense team can think again about this, because this whole KEA/dnsmasq/ISC situation is kind of frustrating and introduces more confusion than clarification both for long time and new users. IMO the standard should be KEA as the ISC successor, including dynamic host registration and dnsmasq should be optional as it always was.
Most small to medium business environments I have seen so far (in germany) use Microsoft, which includes a dynamic registering DHCP/DNS combination with HA capabilities as standard server roles. Microsoft devices even have their own commands to register their DNS name inside active directory integrated DNS servers.
For businesses who use these technologies, running Kea with scripts that update some other DNS server, or even with a KEA plugin that enables RFC2136 to update a server with zones like bind, should be a less preferable solution (also because it is pretty new, the reports about KEA are not quite positive yet, and other combinations are more battle tested).
For dynamic registration, this is something more specific to the home user environment. In a business environment, you shouldn't even want random dynamic updates because they cannot be as safely controlled as static leases.
This means, KEA + Unbound with static leases could work for businesses if they want a different DHCP server + DNS server combination. (As it exists right now)
For home users, Dnsmasq could be the preferable choice, even as single DNS/DHCP server that just forwards to e.g., google or cloudflare or the ISP DNS servers.
The choices are there, everybody can take what they think is the better one.
In my home network with quite some vlans and homelab, I run dnsmasq dhcpv4+dhcpv6+RA and all DNS features since 3 months and have peace and quiet.
Sometimes its just personal preference that clouds the correct answer. I am leaning a bit more towards dnsmasq though since it makes more sense to me.
Please note that this complete post is my own personal opinion.
I agree with these widespread MS AD Setups, but: MS is considering on-prem AD as legacy and urges people to get rid of it and moving to entra id. So in the next years, this scenario is going away and businesses need an answer for that. While dynamic registration is not so much relevant in normal usage, it is when doing debugging. In Entra ID case, the hostname is well defined, because the device is managed by intune. So the admin can see the proper reverse dns name while running i.e. a tcpdump. Depending on the size of the business, there are various options like commercial ones like fortigate, unifi or opensource solutions with optional commercial support like opnsense. I'm sure that opnsense is considered often, but if the set up is not so straight forward anymore, it could be the case that an admin who isn't so much "in the game" as many users here, will consider another solution which "just works".
Regarding dnsmasq: Dnsmasq is IMHO fine when there is no need for a real recursive DNS server. But many people are running unbound for various reasons and do not want to use an upstream recursive DNS. Now there are 2 options, either bind unbound or dnsmasq to port 53 and forward either everything or just specific zones, depending which server is running on 53. Both work, but both have their caveats and are more a workaround than a proper solution.
The ISC solution with the script that feeds unbound with the dynamic leases has been a proper solution for the last years. It just worked, there haven't been much complaints. So why re-inventing the wheel here when we just could do the same with KEA?
The setup with two dns servers is not even that uncommon, check out what pihole recommends for example (its a dnsmasq + unbound combination)
https://docs.pi-hole.net/guides/dns/unbound/
Quote from: Monviech (Cedrik) on May 29, 2025, 12:15:01 PMThis means, KEA + Unbound with static leases could work for businesses if they want a different DHCP server + DNS server combination. (As it exists right now)
It does for me at home and will do @work once we get the unifi option 43 issue solved. I am indeed quite satisfied with Kea, needs only minor improvements.
Kind regards,
Patrick
Do you really need option 43? Ive read some discussion on reddit where somebody assumed they needed it, but what made it work the whole time was resolving the unifi inform endpoint via DNS.
It looks like unifi gear has several fallbacks and/or different ways to find each other.
https://www.reddit.com/r/opnsense/s/hWyYrkYmN7
I wasn't aware of that. We have Unifi gear in two office locations with the controller placed in our data centre, so routed connection. I have been using option 43 ever since we started to use Unifi.
So I could add a host override for "unifi." in Unbound ...
Anyway Kea in OPNsense needs a procedure to introduce selected custom options we agree on. I'll give it a try.
Yes, a DNS resolution for "unifi" works, too: https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3
I use DNS resolution for Unifi and have never used option 43.
I had some issues earlier with short name resolution, so going forward I'll probably follow the advice here (https://forum.opnsense.org/index.php?topic=47262.msg238577#msg238577) to keep a 'unifi' alias in addition to the host entry, maybe even in Unbound. Maybe I'll do that regardless of the DHCP and DNS services used.