[solved] Unbound Query Forwarding exclusions?

[manysmallpieces]

I am still learning about networking and OPNsense, so there are some things I have been overlooking.

There is one thing in particular that while not breaking anything as far as I can tell, I think is indicative of a misconfiguration and would like to fix.

I use both Unbound for its caching and the graphical reports in the Unbound DNS section of the Reporting menu along with DNSCrypt-Proxy for use of anonymized DNS relays. I might add Adguard Home for more granularity when using DNSBLs here soon so I would like to get this squared away first.

I have it set up such that Unbound is on port 53 and DNSCrypt-Proxy is on port 5353.
I do know the settings under System: Settings: General don’t really matter as far as Unbound is concerned, it’s an actual recursive resolver. So I have Unbound set to forward all queries to DNSCrypt-Proxy via a rule in Services: Unbound DNS: Query Forwarding. The rule is as such:
No Domain set, Server IP set to 127.0.0.1, Server Port set to 5353
What I have noticed is that DNSCrypt-Proxy has NX logs for internal domain names, which I don’t think should be happening. The gap in my knowledge here is what even should be happening in a more standard configuration. I can’t imagine Unbound recursively queries from root for domain names it knows are internal like home.arpa, right? So what does it do when it’s not operating under a blanket Query Forwarding rule? Is it just being forced to do this by the Query Forwarding rule, or have I done something else wrong? Whenever I try to search this I can only find people trying to fix things like domain based routing for internal services or forwarding internal domains to like a pi-hole. If my internal domain based routing is broken, I’ll admit I haven't really noticed it because I don’t use it. Thought at the very least I can reach my AP's config page by its FQDN so I don't know.

Right, I forgot to conclude what I was saying. The behavior I would like to see is that these internal domain names don’t get sent to DNSCrypt-Proxy, or anywhere else really. I feel my curiosity asking a deeper level question about what OPNsense and Unbound is truly doing under the hood when resolving internal host names / special-use domain names. Speaking of, I’ve seen a few of the other reserved domain names show up in those NX logs, such as in-addr.arpa and dns.resolver.arpa. I’ve also seen things like “device-metrics.amazon.com.home.arpa” which otherwise should be an external address, with the local domain appended to it. This is something to do with search domains, right? A weird behavior caused on the client end? I would still like to stop it internally tho.

[klosz007]

"I do know the settings under System: Settings: General don’t really matter as far as Unbound is concerned, it’s an actual recursive resolver."

Yes, they do. You control behavior of UnboundDNS be defining or not forwarders. No forwarders = pure resolver mode. Forwarders defined for specific domains only - acts as a forwarder for these domains only, for rest - as resolver. Forwarder set for all domains - forwarder only mode.

If checkbox "Use System Nameservers" checkbox in Query Forwarding section is set then it means it work as forwarder for all domains and uses DNS servers from Settings/General. This checkbox also disables DNS over TLS forwarders defined in another section.
Only the specific domains deifnied in Query Forwarding will be forwarded to different servers defined here if this checkbox is set.

I have never tried to set a "global" forwarder by setting forwarder in Query Forwarding with no domain name set. I'd rather check "Use System Nameservers" and use System/General DNS server settings. Generally speaking queriess to "local" domain (set in System/General) should be resolved locally but unsure how it works if it is done your way.

[dseven]

Port 5353 is used by mDNS. It's probably not the best choice for your purpose, and possibly could be muddying the waters.

When you specify query forwarding with no domain specified, it creates a "forward-zone" in Unbound for ".". The default type for the local domain in OPNsense is "transparent". You can change that at Services -> Unbound DNS -> General. A description of the options can be found at https://nlnetlabs.nl/documentation/unbound/unbound.conf/ "static" might work for you, though I'm not sure if there'd be other consequences......

P.S. regarding the other question; I do think that would be something that clients are doing - not much OPNsense can do to control that.....

[manysmallpieces]

"static" might work for you,

Before I decided to take lunch I did find a single post mentioning this setting by using the term 'upstream' in my searches.

I set it to static and so far I've only gotten "_dns.resolver.arpa SVCB" in DNSCrypt-Proxy's logs. Some more research on that one leads me to believe it's apple devices trying to establish a DoH connection via a feature called Discovery of Designated Resolvers. It's only getting NXDOMAIN or SERVFAIL back, funny part is I'm not even doing that on purpose (obviously). Seems Adguard does support this feature, but maybe not for Unbound.

As for the weird client behavior? Setting it to static fixes that to, which I guess that makes sense. Unbound immediately gives that NXDOMAIN itself now instead of letting DC-P do it after trying to resolve it. Learned some more about that though. The client seems to only add the internal domain appended to the end after it fails to reach the external address without it, so yeah something to do with search domains. As for why it can't reach it normally, probably DNSBL or maybe even Zenarmor.

I did identify a side effect, I mentioned in-addr.arpa, which, those should be reverse lookups. I realized I was being myopic and there totally are legitimize reasons for those to be sent to external resolvers sometimes - any time its an external address I don't have the PTR for cached. Those aren't getting through anymore. I wonder if there is a way to fix this part. I guess I could make a domain override, but that might try sending internal addresses upstream too. I know pi-hole explicitly has a setting for 'never send reverse lookups for internal addresses upstream', but cannot find a similar thing in Unbound. Hmm.

[klosz007]

I'm using AdGuard at home but I'm doing it differently. My AdGuard runds on separate VM (other than OPNsense).
I'm putting AdGuard in front of OPNsense i.e. DHCP clients revceive AdGuard's IP address as primary DNS server (OPNsense's IP is secondary - as backup in case AdGuard fails) and talk to AdGuard and AdGuard then forwards all (already filtered) queries to OPNSense.
In OPNsense I use DNS over TLS to Cloudflare servers to send/forward DNS queries as encrypted ones over WAN and not to let know my cable operator what I'm browsing that easily.

I tried to use Unbound resolver mode once but it did not work well with my dual-WAN setup.
If primary WAN (DSL) was operational (99% of the time) resolver worked fine.
If DSL failed and traffic went through backup link (LTE modem) then resolver was malfunctioning.
Resolver sends a lot of queries outside to resolve a single (uncached) name and it was taking too much time over LTE/cellular link to resolve a name so I had a lot of DNS timeouts then.
I could not find a way how to use resolver mode with DSL link and forwarder with LTE so eventually I switched from resolver to forwarder mode and then Unbound works fine over (slow) backup WAN link too.

Then I implemented DNS over TLS to enhance my privacy in forwarder mode.

[manysmallpieces]

In OPNsense I use DNS over TLS to Cloudflare servers to send/forward DNS queries as encrypted ones over WAN and not to let know my cable operator what I'm browsing that easily.

People definitely have some varying opinions on whether that's a good idea. Your ISP sees where you're going anyway, eh? At least your way should be pretty fast. I don't run DNSCrypt-Proxy with relays because of the ISP. I do it to simply spread the data around, less centralization. I guess people say using resolving mode with root hints does the same thing, but I like my method better, even if my uncached query times are trash. I just formally added Adguard and for the first time I'm getting easily displayed statistics on that and damn. That said, I have found with all other things being equal, that the DNSCrypt protocol (without relays) is about the same or maybe a bit more performant than DoH which is more performant than DoT. That's really really anecdotal and could quite likely be bullcrap. I've found the same for DNSCrypt with relays over ODoH (the DoH version of relays). The other nice thing about both our methods is it prevents ISP DNS hijacking since we're avoiding port 53.

--

In any case I'm going to mark this solved. The side effect I thought I was observing was bogus, just needed a service restart and time for the logs to populate, external reverse lookups are getting through and resolved just fine, local-zone static does not effect this. I confirmed this before adding Adguard.

I'll mention that even if it was a problem, Adguard does have setting that more or less does the same as the pi-hole setting 'never send reverse lookups for internal addresses upstream' I mentioned. I think I'm going to make another thread in General about Adguard since this one was ultimately about Unbound.

The funny part about this one is I was literally reading the documentation for that setting and local-zone types before posting this thread, and for some reason did not think it was relevant to my quandary. I must have been tired or something.

[cookiemonster]

In case you want to consider it, another spanner for you:
I wanted to also spread the encrypted dns queries. For that I install getdns/stubby on OPN. CLI only.
LAN client -> AdgH:53 -> Unbound:5353 -> stubby:853 -> scatter of DoT resolvers.
The scatter is presently only quad9 and cloudflare on their TLS ports.
More complicated than strictly necessary but I'm happy with the setup.