Unbound cannot resolve dnsmasq DHCP reservations unless Domain in the reservation is set, contrary to documentation

[Unspec7]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Within the documentation, the instructions for dnsmasq DHCP reservation specifies that only host needs to be specified, with domain left blank, presumably which defaults to your system domain. Intuition suggests this is expected - in all other areas requesting a domain, not setting a domain simply sets it to the system default.

That is not the case here. Unless domain is explicitly set when creating the reservation, Unbound is unable to query dnsmasq to lookup local hostnames (e.g. myhost.mydomain.com), violating the principle of least astonishment.

To Reproduce

Steps to reproduce the behavior:

1. Create DHCP reservation with just a host specified
2. Setup query forwarding from Unbound to dnsmasq for system domain.
3. dig/nslookup the created DHCP reservation
4. Get SERVFAIL
5. Edit DHCP reservation and add in the system domain to the domain field
6. dig/nslookup the edited DHCP reservation
7. Get expected IP address

Expected behavior

1. Create DHCP reservation with just a host specified
2. Setup query forwarding from Unbound to dnsmasq for system domain.
3. dig/nslookup the created DHCP reservation
4. Get expected IP address

Describe alternatives you considered

ISC DHCP works fine. but as it is deprecated/being deprecated, I want to move to dnsmasq.

Relevant log files

all the configured stub or forward servers failed, at zone [my system domain]. no server to query nameserver addresses not usable have no nameserver names

Additional context

I own my own domain and use it for both local use and web use, with a split DNS setup through the usage of two reverse proxies (a local one intended for local services and a public one for public services)

Unbound is able to resolve reservations that do NOT have domain set, but appear in the "Leases" tab of dnsmasq. See #8611

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 25.1.6_2-amd64

[Unspec7]

Also of note, even with domain set, AAAA lookups will still SERVFAIL. Setting the domain seems to only resolve the issue for A lookups.

Edit: Oh, another neat thing with this bug: unbound gets slammed with wpad lookup errors as it's unable to properly query dnsmasq.

[TheNec]

Don't know if that helps or even if it's related but I noticed a similar problem in my network yesterday in the evening, recognized some hours after the 25.1.6 update with my OPNsense's unbound seemingly but with static IP host overrides (haven't checked others due to being late) and without dnsmasq (only as piholeFTL/dnsmasq on a downstream pi-hole) using only ISC DHCPv4 for dynamic adressing. Restarting the unbound service didnt't help.

Now after the 25.1.6 hotfix (unrelated to unbound according to the changelog) it seemed to be gone resolving hostnames without the domain given again but as you've already installed it, it still could be an unbound bug only happening from time to time.

Additional context is that during the 25.1.6 update I noticed some strange messages I can't remember correctly but I think I read 'deleting unbound config' or something like that which made me startle briefly.

[Unspec7]

I updated directly to the hotfix from 25.1.5

[Monviech]

I will look into replicating this and respond soon if I find anything weird.

[Monviech]

I have used this exact setup as base for my test:

https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

I have created a reservation for a client with just a host specified, and I could query the FQDN of that client in any network (e.g. host.lan.internal), and I could query the short name while I was in the same network as the host I queried due to dns suffix (e.g. host).

Can you re-verify with the exact documented setup, if your configuration right now is a bit different?

[dMopp]

Even worse here, its not working at all anymore for my setup (KEA ipv4 + v6) + Blocky (as a service) + unbound (not running on port 53). This was working before :(

So no dhcp leases are resolvable with unbound anymore. In my case, this breaks a lot (firewall rules, shaper, home automation etc)

[fichtner]

Let's not derail other people's tickets... if you have issues with Unbound post upgrade the most obvious thing to do is look at the release notes and see that a new Unbound version shipped and you can easily revert using:

# opnsense-revert -r 25.1.5 unbound

Also provide a reference for your configuration and version used. You say "Kea v6 not working anymore" but 25.1.6 is the first version with Kea v6. But please do so in a separate ticket when you have figured out more than "not working at all".

Cheers,
Franco

[dMopp]

Sorry, created a new ticket .. :|

[Unspec7]

I have used this exact setup as base for my test:

https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

I have created a reservation for a client with just a host specified, and I could query the FQDN of that client in any network (e.g. host.lan.internal), and I could query the short name while I was in the same network as the host I queried due to dns suffix (e.g. host).

Can you re-verify with the exact documented setup, if your configuration right now is a bit different?

Yes, that is the exact steps. I followed the dnsmasq documentation pretty closely. That said, perhaps more context is needed.

My DNS setup is somewhat convoluted, but it worked fine with ISC DHCP. All queries are sent to pihole first, via the keepalived IP (192.168.1.205). Pihole then sends that upstream to unbound on opnsense, which has three options: 1) forwards it to quad9 via DoT (default "fallback" option, e.g. if I'm querying google, youtube, etc). 2) forwards it to cloudflare 1.1.1.1 over DoT for 5 specific subdomains of mine (e.g. x1.mydomain.com, x2.mydomain.com). 3) forwards all other subdomains of mine that are NOT in (2) to dnsmasq for plain old DNS lookup on port 53053.

Hope that helps.

[Unspec7]

I've abandoned dnsmasq, it's far too unstable in terms of hostname lookups for me to use. Hopefully dnsmasq will be a fully functional DHCP server by the time ISC gets retired fully, but at the moment ISC JustWorksTM and that's more than what I can say for dnsmasq.