Messages

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.

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

[no 'lan.' TLD]

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:

Code Select Expand

server:
  harden-below-nxdomain: no


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!

[is]

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:

Code Select Expand

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


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:

Code Select Expand

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


[Internal DNS domains]

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

Behavior
With 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):

Code Select Expand

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?

EDIT 2026-04-10:

The feature `harden-below-nxdomain` has been added to OPNsense 26.1.6 and defaults to enabled. You must disable it to solve the above issue.

[behind]

Hi Kosta! Just wanted to let you know that I am in a very similar place as you were last year: coming from Sophos UTM, consistently exceeding the 50-ip limit with all my IoT devices, with a site-to-site IPsec VPN with another UTM at the office, Lets Encrypt, a number of WAF/Web Protection rules, and a home lab vSphere infrastructure.

I now have OPNSense set up behind my UTM, and am double-NATing my VLAN of IoT devices to hide them from Sophos. So I no longer have the IP problem, per se. But I eventually would like to just move completely to OPNSense. How has the transition gone for you? I wonder if you have any links/pointers/gotchas to share around setting up the VPN and the WAF. I hope it's worked out for you!