Unbound DNS and separate zone for VLAN/LAN

[cr9c1]

I haven't had any luck finding an answer to this, but I may know what the answer is.

I have opnsense configured with a VLAN. Unbound listens on my LAN interface, and the VLAN.  They are configured on different "local domains", i.e. lan1.lan, lan2.lan.  LAN can talk to VLAN, but VLAN can't talk to LAN. (Blocked in the firewall). Think of it as a guest network that my main network can talk to, but it can't talk to the main network.

I have unbound configured to register DHCP static mappings and DHCP leases. Everything is working well, and hosts on the main LAN are assigned a lan1.lan record, and hosts on the VLAN are assigned a lan2.lan record (in DNS).  What I'm trying to do is block the VLAN and Unbound from resolving hosts on the main LAN network.  For instance, on the VLAN, a DNS query for a system on the main lan (lan1.lan) should not resolve. It looks as if Unbound uses a single zone for all records (my main LAN hosts/ptr and vlan hosts/ptr are part of the same zone). I want to prevent hosts on the VLAN from being able to successfully resolve hosts/IPs on the main LAN. The firewall will prevent any communication to the hosts directly, anyhow, but I'd also like to prevent resolution at the DNS level.

Is this possible with Unbound included with OPNsense? I've searched everywhere for an answer, but I don't see an option to split the lan1.lan and lan2.lan zones so that lan2.lan cannot resolve names on lan1.lan. I'm thinking that perhaps I could bind unbound to lan, and dnsmasq to vlan, but I'd prefer to stick with a single DNS resolver if possible, and this doesn't solve the problem if I add more VLANs down the road, either.  Any help or insight is greatly appreciated.

[zz00mm]

I think it would be easier to mgmt if another DNS server was used. If you want to try the Unbound route, here's a snipet of an additional unbound.conf file that I use to configure split-dns/split horizon. In your case, I would assume VLAN101 as your vlan and replace the IP's with 0.0.0.0 like DNSBL does. It will be interesting to see which is easier to mgmt.

server:
access-control-view: 10.0.0.0/16 "VLAN100"
access-control-view: 10.1.0.0/16 "VLAN101"

view:
name: "VLAN100"
view-first:yes
local-zone: "OPNsenseVM.xyz.zyx." transparent
local-data-ptr: "10.0.255.254 FWmain.xyz.zyx."
local-data: "FWmain.xyz.zyx. A 10.0.255.254"
local-data: "FWmain. A 10.0.255.254"
local-data-ptr: "10.0.91.255 OPNsenseVM.xyz.zyx."
local-data: "OPNsenseVM.xyz.zyx. A 10.0.91.255"
local-data: "OPNsenseVM. A 10.0.91.255"

view:
name: "VLAN101"
view-first:yes
local-zone: "OPNsenseVM.xyz.zyx." transparent
local-data-ptr: "10.1.255.254 FWmain.xyz.zyx."
local-data: "FWmain.xyz.zyx. A 10.1.255.254"
local-data: "FWmain. A 10.1.255.254"
local-data-ptr: "10.1.91.255 OPNsenseVM.xyz.zyx."
local-data: "OPNsenseVM.xyz.zyx. A 10.1.91.255"
local-data: "OPNsenseVM. A 10.1.91.255"

[zz00mm]

I will add this specifies what unbound to respond with. This configuration has 10 VLAN's and the goal was a user on a vlan to a device that's on multiple vlans to get the subnet ip
VLAN100 = ping NAS respond 10.0.133.2
VLAN101 = ping NAS respond 10.1.133.2
to
VLAN109 = ping NAS respond 10.9.133.2

same with FW's and other devices that are multi-homed.