Messages

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

Could anyone please confirm whether the latest release 25.1.8_1 has resolved the issue described by meyergru?  I have reverted back to ISC + Unbound due to this issue and would like to confirm that it's fixed before I change the configuration again.

Thank you!

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.

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!

@Monviech has changed the scheme on how to determine the "local" domains by his latest patch 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.

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

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

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.

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.

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.

Thank you, done!  So far so good.

In a setup with Unbound as the primary DNS resolver forwarding to DNSmasq for local DNS resolution of DHCP names (as described here: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration), I believe I've discovered an issue.

Unbound randomly stops forwarding DNS queries for the local domain configured in Unbound > Query Forwarding, instead attempting to resolve the local domain recursively (like all other domains).  This fails of course, resulting in NXDOMAIN.  It sometimes resumes working after a while.  Restarting Unbound also fixes it temporarily.  This seems to be a known issue with Unbound, see for example: https://github.com/NLnetLabs/unbound/issues/451

Although it's not a bug in OPNSense, this affects the new recommended mechanism to forward local queries from Unbound to DNSMasq.  Since this is the "new" way post-ISC DHCP, this is concerning.  Not sure what the solution is, since it seems to be an issue in Unbound and nothing to do with Opnsense.

I noticed a new potential issue: DNSmasq will randomly stop resolving local hostnames, returning NXDOMAIN.  It sometimes resumes working after a while, otherwise restarting it works too.  Is this a known issue?  I recall reading similar anecdotal reports recently on the forum.

The domain is mandatory if you do query forwarding from Unbound to Dnsmasq.

In version 25.1.7_4 this should work as expected.

OK, this is the part I was missing: when I created my static entries in DNSmasq > Hosts, I did not include the domain.  Now the static entries all resolve fine even without an initial DHCP exchange.

Thanks!

Hello,

Like others, I've switched from ISC to DNSmasq DHCP.  It seems to be working fine overall, except I've noticed that local DNS names for static DHCP leases defined in DNSmasq > Hosts are not resolved until the first DHCP request/offer exchange.  Is this normal?

Thanks!

Yes you're right.  The "Default" mode is not one of the modes described in the DNSmasq Man page, so I missed it.  Thanks!

What if I want only stateful DHCPv6 without SLAAC, which corresponds to the "Managed" mode under Services > Router Advertisements?  None of the DNSmasq RA modes seem to do this.  Possible using DNSmasq?

This is not specifically related to OPNsense (I think), but there are a lot of knowledgeable people on this forum so I thought I'd ask anyway.

For the past week or so, I've noticed that my Windows 11 PC is not renewing its IPv6 address.  I have a /56 prefix delegation from my ISP which is split into a few /64s on my OPNsense box and handed out to clients using DHCPv6.  I'm running ISC DHCPv6 in Managed mode because I want to control the IPv6 addresses assigned to clients (no SLAAC).  This has worked fine until recently.  Now, my sole Windows 11 PC won't renew its IPv6 address.  Upon expiration of the DHCPv6 lease, it reverts to an fe80: link-local address and I lose public IPv6 connectivity.  Doing ipconfig /renew6 causes the PC to pull a new lease from OPNsense, and all is good until the next time the lease expires.

Any ideas what's going on here?  The problem started around the time I upgraded OPNsense to 25.1.6 (which introduced DNSmasq for DHCP), but I haven't changed my configuration and am still using ISC for DHCP.  DNSmasq is disabled.  I simply upgraded without changing anything in my configuration.  My other clients (Linux, Windows 10, macOS, iOS) can all renew their IPv6 leases without issue as before; it's only the one Windows 11 box that has an issue.  So I don't think it's related to the OPNsense 25.1.6 upgrade.

Thanks!