I'm running OPNsense 26.1.1 with:
- Unbound as the main DNS resolver (full recursion)
- Dnsmasq for DHCP for two VLANs (1 and 12); DNS listening on port 53053
- Windows AD domain: sarangan.lan (VLAN 1, AD DNS forwards to Unbound
Internal DNS domains- sarangan.lan - Windows domain, VLAN 1
- iot.lan - IoT devices, VLAS 12 - pointed to Unbound
- infra.lan - APs, switches in both VLANs - pointed to Unbound
Architecture- VLAN 1 domain clients use AD DNS
- DCs forward all non-AD queries to Unbound (192.168.2.1)
- Unbound does full recursion for public domains
- Domain Override in Unbound: iot.lan -> 127.0.0.1:53053 so Unbound forwards iot.lan to Dnsmasq
- Dnsmasq has DHCP reservations with hostnames under iot.lan
BehaviorWith DNSSEC disabled in Unbound, everything works:
- somedevice.iot.lan resolves (from VLAN 1 or from OPNsense)
- DCs forward iot.lan queries properly
- Unbound forwards to Dnsmasq correctly
If I enable DNSSEC, resolution for iot.lan starts failing within 30 seconds:
- Queries return NXDOMAIN
- Disabling DNSSEC immediately fixes it
Example (works, then stops working):
root@fw01:~ # nslookup emporia.iot.lan 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: emporia.iot.lan
Address: 192.168.12.86
root@fw01:~ # nslookup emporia.iot.lan 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find emporia.iot.lan: NXDOMAIN
I've tried:
- Adding iot.lan, infra.lan, and sarangan.lan to Insecure Domains (these seem to be added automatically in the config when forwarding to Dnsmasq is configured, but I added them anyways).
- Disabling Strict QNAME Minimisation
- Disabling DNSSEC hardening
- Clearing caches
- Restarting services
The issue persists as long as DNSSEC is enabled.
I have been all over the interwebs and have had long discussions with the AI oracles. Is it expected behavior that Unbound DNSSEC validation conflicts with forwarding a private, non-delegated TLD like .lan to Dnsmasq?
My current suspicion is that this is not an Unbound problem, it's a Dnsmasq problem. When DNSSEC is enabled, something changes the behavior of Dnsmasq and it no longer treats `iot.lan` as local:
DNSSEC enabled:
root@fw01:~ # drill .0.0.1 -p 53053 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 64879
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; emporia.iot.lan. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
. 2494 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2026021301 1800 900 604800 86400
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Fri Feb 13 10:31:58 2026
;; MSG SIZE rcvd: 108
DNSSEC Disabled:
root@fw01:~ # drill u/127.0.0.1 -p 53053 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 7948
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; emporia.iot.lan. IN A
;; ANSWER SECTION:
emporia.iot.lan. 1 IN A 192.168.12.86
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Fri Feb 13 10:32:35 2026
;; MSG SIZE rcvd: 49
I will be honest with you :
I am not even sure you will ever get this to work, because even tho DNSmasqd can be an Authoritive DNS Server I think it can only deal with DNSSEC when used as a Forwarding DNS Server ?!
But you could try adding the right DNSSEC related DNS Records to DNSmasqd and see the result for yourself...
I am confused by the DNSmasqd documentation/man page about this stuff so I wouldn't mind anyone showing me that I am wrong! ;)
I do a similar thing, using Unbound as the resolver, forwarding my local domain to Dnsmasq and it seems fine.
Do you have DNSSEC validation turned on Dnsmasq? I don't in my setup, only in Unbound. I don't have DNSSEC hardening turned on but I notice you've tried that both ways anyway.
Another thing I notice which may not be relevant is that Dnsmasq seems to be trying to forward the query, given the response mentions NXDOMAIN with a reference to root-servers.net. In my setup I have enabled 'Do not forward to system defined DNS servers' in Dnsmasq settings. It may not help but since you're using Dnsmasq just to serve local domains, and Unbound should be the recursive resolver, it makes sense to me to never allow Dnsmasq to do any forwarding. If nothing else it may make it easier to diagnose what's going on since you'll know any answer from Dnsmasq is _only_ from Dnsmasq.
I notice another potential problem in your tests: doing some similar tests myself, I noticed that the port specifier must be first
This will use the specified port:
drill -p PORT @127.0.0.1 NAME
This will not, the port seems to just be silently ignored:
drill @127.0.0.1 -p PORT NAME
(I normally use dig instead, where the order doesn't seem to matter as much.)
So what you're seeing probably is Unbound behaviour changing, rather than Dnsmasq. The fact you don't see 'aa' (authoritative answer) in the flags response is a clue that you're going via a recursive resolver and not hitting Dnsmasq directly.
tl;dr I don't know why it doesn't work, sorry! But maybe you can at least change your drill command and be sure Dnsmasq isn't changing here.
Hello, Ben!
I already have 'Do not forward to system defined DNS servers' enabled. Dnsmasq should not be doing any forwarding. I also do not have DNSSEC enabled in Dnsmasq. Are you saying that you have a configuration similar to mine and it is working for you? That would at least give me hope that it's just a matter of settings on my side.
The order of the parameters doesn't seem to matter here:
root@fw01:~ # drill @127.0.0.1 -p 53053 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 6682
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; emporia.iot.lan. IN A
;; ANSWER SECTION:
emporia.iot.lan. 1 IN A 192.168.12.86
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Sat Feb 14 12:55:22 2026
;; MSG SIZE rcvd: 49
root@fw01:~ # drill -p 53053 @127.0.0.1 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 33100
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; emporia.iot.lan. IN A
;; ANSWER SECTION:
emporia.iot.lan. 1 IN A 192.168.12.86
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Sat Feb 14 12:55:52 2026
;; MSG SIZE rcvd: 49
Quote from: LemurTech on February 14, 2026, 10:09:58 PMThe order of the parameters doesn't seem to matter here:
Well, I beg to differ, because..
Quoteroot@fw01:~ # drill @127.0.0.1 -p 53053 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 6682
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
...
root@fw01:~ # drill -p 53053 @127.0.0.1 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 33100
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
Note the difference in flags. You are getting different results here. aa = Authoritative Answer because that one is hitting Dnsmasq directly. The other is not, because the port is being ignored, and it's going via Unbound.
But yes, I have what is a broadly similar setup.
- I am forwarding a subdomain of a real, existing domain to Dnsmasq (e.g. subdomain.example.net) rather than a .lan domain. I've just tried with a .lan domain like yours though and it still all seems to work too.
- Another difference in my setup may be that I'm using DoT forwarders (Quad9) instead of doing full recursion. Potentially that makes some difference to DNSSEC validation. But I also tried temporarily turning those off and everything still seemed to work.
- I don't have any windows AD stuff but you're seeing problems even without that involved so I don't think that's the culprit.
I'm kind of out of ideas but it does seem like what you're trying to do should be possible. If no-one else has better ideas you might need to turn up Unbound logging levels and see if there are any clues, especially with DNSSEC enabled, what's different between the working queries and the one which fail after 30 seconds?
You are right! I was too much a n00b to see the 'aa' flag difference!
So Dnsmasq is *not* the problem; it's with Unbound trying to do recursion on the iot.lan domain when DNSSEC is turned on, despite lan and iot.lan being listed in 'Insecure Domains'.
I did try turning up logging but couldn't seem to pull anything useful. I'm at a loss. Thanks for trying!
I've resolved this with the help of my friendly neighborhood AI. (I'd tried that before, but this time I presented the evidence fresh and actually got somewhere.)
The root issue:
When DNSSEC is enabled, Unbound can
cryptographically prove that the public DNS has
no 'lan.' TLD. After learning that 'lan.' is
NXDOMAIN (secure), Unbound applies
RFC 8020 "NXDOMAIN cut": if a parent name does not exist, everything beneath it is treated as nonexistent too. That causes Unbound to answer '*.lan' as NXDOMAIN without ever consulting the forwarding rule for 'iot.lan'.
Disabling 'harden-below-nxdomain' (via custom config) stops Unbound from applying the NXDOMAIN cut, so it will again honor the 'iot.lan' forwarding and return the records from Dnsmasq.
Why "Insecure Domains" didn't prevent it:
'domain-insecure' tells Unbound
not to validate DNSSEC under that domain, but it does not stop Unbound from learning that the
parent ('lan.') is NXDOMAIN from the root and applying NXDOMAIN-cut behavior beneath it. In other words:
- 'domain-insecure: iot.lan' affects validation
- 'harden-below-nxdomain' affects "cut off everything below a proven NXDOMAIN parent"
So the failure mode persists until NXDOMAIN-cut is disabled.
The fix:
server:
harden-below-nxdomain: no
Hi LemurTech.
I've read your solution, and I wonder if this could be the solution for other problems that I've found people are having https://github.com/opnsense/core/issues/9736
Given that you have researched this in detail, may be it worth to open a ticket at github for asking the developers to add the intended options that had solved this problem.
May be these options were not needed before, but the new Unbound-Dnsmasq schema proposed by the developers can lead to the need for some additional options like the ones you have mentioned.
In my case, I had the problem of Unbound not forwarding queries to Dnsmasq when my Inet connection was down. It's not the exact same symptom but the problem looks the same at the end.
Quote from: muchacha_grande on February 18, 2026, 12:42:08 PMI've read your solution, and I wonder if this could be the solution for other problems that I've found people are having https://github.com/opnsense/core/issues/9736
Given that you have researched this in detail, may be it worth to open a ticket at github for asking the developers to add the intended options that had solved this problem.
I'm not sure it's the same issue unless DNSSEC is involved. That said, I did open a feature request ticket to expose 'harden-below-nxdomain'.
Quote from: LemurTech on February 18, 2026, 07:26:24 PMThat said, I did open a feature request ticket to expose 'harden-below-nxdomain'.
Thank you. In any case, the next time my Internet connection fails I will test this custom option to see if it also solves my issue.