Messages

I noticed that since upgrading, the disk access LED on my Opnsense box flashes much more often than before the upgrade - like every 2 seconds or so.  I disabled the Host Discovery feature and it stopped immediately.  I'm not sure what this feature needs to access the disk so much for (my log file was only 40KB after running for a few hours), but this seems like a great way to wear out an SSD.  I agree this feature should be disabled by default; those who need it can enable it themselves.

Thanks.  This is for local overrides only, not a real local zone.

I did previously read the guide linked by @monviech, but must have missed a few subleties.  I read it again.  Thanks, all good.

-cinergi

Hello,

Just wondering what is considered the best practice for local DNS resolution when using Unbound and dnsmasq together: Unbound running as primary resolver on port 53 and forwarding to dnsmasq on some other port for the local domain?  Or vice versa, i.e. dnsmasq on port 53 forwarding non-local queries to Unbound?  I'm currently using the latter setup (dnsmasq 53 --> Unbound 5353) but am wondering if the other setup (Unbound 53 --> dnsmasq 5353) would be better in some way.  The documentation includes both options as valid.

I recall having some issues when I initially tried Unbound --> dnsmasq, specifically Unbound sometimes randomly stopped forwarding local queries to dnsmasq, but that was in the early days of the transition away from ISC DHCP so it may have been a bug that was since fixed.

For the Unbound --> dnsmasq case, what happens for queries to local non-FQDN host names?  For example, if my local domain is home.lan, I would configure Unbound to forward queries for home.lan to dnsmasq; so queries for my-pc.home.lan (for example) would be properly forwarded, no problem there.  But what about non-FQDN queries to my-pc without a domain?  How would Unbound know to forward those as well?

Thanks!

Thanks both.  I looked at the link from @meyergru, point #3 specifically: Using the interface's link-local address which does not change.  This achieves my purpose, thank you!

Cheers!

Hello,

I'm running OPNsense 2.7.8 with DNSmasq for DHCP and local host name resolution.  I'm trying to set a local DNS host entry pointing to the interface's IPv6 address.  Since this address is derived from the WAN prefix delegation and could therefore change, I'm hesitant to hard-code the IPv6 address in the DNS host entry.  Is there any way to specify "this interface IP address"?  When setting custom DHCP options, for example, it's possible to specify [..] for the interface IP which would be perfect in this case, but this doesn't seem to be supported for DNS host entries - only DHCP options.

Thanks!

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.