Messages

1

General Discussion / Re: DNSCrypt questions, possible solution for toml file after upgrade

« on: October 17, 2024, 11:21:01 pm »

Your shell script seems simple enough, at least without going over it line by line. The idea should work at least.
You should take a look at https://docs.opnsense.org/development/backend/autorun.html tho. Putting it elsewhere could get reverted on reboot or update as I understand it.

Could put it in 'early' to have it run every restart before system network starts up or maybe 'update' to check once after core package updates.

--

That said, DNSC-P is the one DNS service I can actually answer questions about. What are you having trouble getting working with it?

2

General Discussion / Adguard plugin questions.

« on: October 17, 2024, 10:51:26 am »

I've recently added the Adguard plugin to my DNS 'stack' on OPNsense and have a few musings about configuring it.

First things first, I had to go into AdGuardHome.yaml and add 127.0.0.1 to the listen interfaces under DNS: bind_hosts:.
Is that expected behavior? I was experiencing that the firewall itself had no DNS. Under (System: Settings: General> Networking) I have the list of servers blank and everything unchecked. So the only DNS that OPNsense has is its own services. This was working fine with with Unbound but after switching Unbound's port and letting Adguard take over port 53, nothing. I did some diagnostics tests and discovered that connections on loopback @ 53 were being refused. Clients still had DNS though, and that made sense enough as connections on the lans interface IPs @ 53 were fine.

Explicitly, this makes sense? Even in the Adguard home GUI it was directly stating "AdGuard Home DNS server is listening on the following addresses:" and without adding 127.0.0.1 it only had lan interface IPs. Thing is, I can't recall anyone mentioning having to do this. I guess I could have just set OPNsense to use a lan interface IP as its DNS server. The DNS Lookup diagnostic went just fine doing it as such. Maybe there is a reason to prefer one way over the other.

--

I did originally want OPNsense to keep using Unbound and just leave Adguard alone, but I didn't see a way to have it use a port other than 53. I guess I'm sneaking in an Unbound question here, but is there a way to have it listen on both a nonstandard port and 53 for just one interface? Or force OPNsense to get its system DNS from a IP listening on a nonstandard port? Maybe I could unselect all the lan interfaces in (Services: Unbound DNS: General> Network Interfaces), only have Adguard listening on the lan interfaces, and have them both listening on port 53. Hmm, I think I would have to change my DNS hijacking firewall rules if I did it that way.

Code: [Select]

Interface: lans_group
Protocol: TCP/UDP
Destination / Invert: Ticked
Destination: lans_group net
Destination port range: From: DNS - To: DNS
Redirect target IP: 127.0.0.1
Redirect target port: DNS
Description: Forward DNS to local
NAT Reflection: Disable
I would have to change the Redirect target IP from loopback, or that would probably... that would probably make any hijacked DNS requests use Unbound instead of Adguard.

---

My other set of musings are somewhat of a rehash of what I was saying in this post https://forum.opnsense.org/index.php?topic=43401.0 . But in the context of Adguard instead of Unbound. I thought, perhaps, since I run both Unbound and DNSCrypt-Proxy, I could get more performance or at least less overhead by splitting upstream queries from Adguard to both DNSC-P and Unbound for external and local respectively. As opposed to explicitly setting Unbound as Adguard’s sole upstream and then forcing DNSC-P as Unbound’s sole upstream via a catch all Query Forwarding rule. Probably redundant but here’s that:

Code: [Select]

Domain: (blank)
Server IP: 127.0.0.1
Server Port: 30054
Another set of musings in the middle of those. Is this even worth doing? My thinking is:

• That using DNSC-P in the way that I do puts my uncached query times in the dumpster, though I know that relative to that, playing hot potato with queries over loopback isn't adding that much.
• That having three DNS services all caching and logging every query is very redundant, but better to have the logs at each junction than not.
• My firewall is highly overspec hardware wise so maybe I should not care.
• I should take some time to gain a deeper understanding of the implications of using multiple services and consider turning off caching for one or two of them. Adguard has 'optimistic mode', Unbound has prefetch. Pros and cons.

I read somewhere that I should make sure my TTLs are 'synced' if I am using multiple caches. How does one go about that?
Again, is this a worth while endeavor or am I better off using Unbound as Adguard's sole upstream to make use of prefetch?
No matter what I should probably turn off DNSC-P's cache, yeah?

In any case, trying out the idea I laid out, I set DNSC-P as both the Upstream and the Bootstrap [only because it keep auto-filling the Bootstrap section with quad9 and such if you try to leave it blank], and then Unbound as the Private reverse DNS server with “Use private reverse DNS resolvers” and “Enable reverse resolving of clients’ IP addresses” both checked. Problem with is is Adguard doesn’t fully filter the things I was talking about in that other post out such as ‘things like “device-metrics.amazon.com.home.arpa” which otherwise should be an external address, with the local domain appended to it.’ While Unbound with local-zone set to static, as was the concluded solution in that thread, did.

Maybe I could do this with some clever regular expression based rules in Adguard’s custom filtering. Hmm, wait. I could set it such that any requests ending with “.home.arpa” get sent to Unbound explicitly with a rule and then Unbound will use local-zone static to properly handle those requests.

3

24.7 Production Series / Re: Unbound Query Forwarding exclusions?

« on: October 17, 2024, 08:32:38 am »

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.

4

24.7 Production Series / Re: Unbound Query Forwarding exclusions?

« on: October 14, 2024, 05:32:14 pm »

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

5

24.7 Production Series / [solved] Unbound Query Forwarding exclusions?

« on: October 14, 2024, 10:36:12 am »

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.