Question about Adguard home > Unbound DNS configuration

[P195]

Hi All,

When using a local DNS filtering service such as Adguard home on OPNsense, why may you want to include unbound DNS before sending on to the upstream provider as explained in the following guide ?

https://windgate.net/setup-adguard-home-opnsense-adblocker/

From what I can tell, unbound is just forwarding the query to the external provider.
What benefits does including unbound DNS in the chain provide Vs just using Adguard > Cloudflare ?

Thanks

[Patrick M. Hausen]

Reverse resolution of local hostnames integrated with DHCP.

[zan]

Mainly to resolve local hostnames in your internal network managed by DHCP server (assumed you have both running on OPNsense) You can also do hostnames and domains override in Unbound.
Can't do that with AGH alone.

Edit: Patrick beat me

[P195]

Removed - double post. See below.

[P195]

Thanks to both of you for your input!



Sorry I'm a networking noob so not too familiar with all the terms yet.

With reference to the picture above, when you say "reverse" does that mean that the DNS is resolved locally by unbound rather than at cloudflare? I kind of assumed that because cloudflare was furthest right, that's where it was resolved.

So is it essentially Client > Adguard > Unbound > Cloudflare > Unbound ? I may be missing the point!

What is the benefit of resolving local hostnames in my internal network?

Rather than rambling on about what I don't understand much, I'll just ask what is the "best" configuration for my DNS to be as private and secure as possible both when I am connected to VPN and also when not?

With VPN:
Client > VPN (app using VPN's DNS servers)
Client > VPN (app - custom DNS pointing to my OPNsense) > Adguard > Unbound > Cloudflare (> unbound?)
Client > VPN (app - custom DNS pointing to my OPNsense) > Adguard > Unbound (?)
Client > VPN (app - custom DNS pointing to my OPNsense) > Adguard > Cloudflare

No VPN:
Client > OPNsense > Adguard > Unbound > Cloudflare (> unbound?)
Client > OPNsense > Adguard > Unbound (?)
Client > OPNsense > Adguard > Cloudflare

Any schooling would be appreciated / needed!

Cheers
P195

[36thchamber]

It gets even more complicated for me.

I want as much as possible to go through VPN, but the firewall itself is independent, not part of normal rules, and is prone to race conditions. You need DNS when connecting VPN. You also need DNS when booting. But Adguard isn't scripted to be a DNS service, it starts too late.

Another challenge is Unbound doesn't resolve https://forum.openwrt.org/t/unbound-shortname-lookups-non-authoritative-answer/59722/1 LAN addresses well. It can't resolve simple hostnames. Nor hostnames with dots.

Another challenge is aliases start empty after boot and also update late.

So I ended up with 3 resolvers:
- AdGuard:53 Main resolver for almost everyone. Not for firewall as it starts too late. It has all the filters and device/user rules incl grouping (Mobile phone 1 = LAN IP + VPNserver IP etc). Something you don't have in Unbound.
- Dnsmasq:8953 Main LAN resolver. Can resolve properly unlike Unbound. Is called by AdGuard by its subrules [//local]127.0.0.1:8953. It is disallowed to resolve WAN addresses and bypass proper filtering.
- Unbound:853. It is the resolver for the firewall itself. It's the only one that can access WAN, but only selected bootstrap servers. The reason why not let Dnsmasq do it is that i want DOH/DOT at least, via WAN, of course.

Then there are settings per DHCP:
- firewall's DNS is Unbound. No race conditions, a multi WAN multi VPN multi gateway failover/load balancing always works. Can watch the resolving in the Reporting tab.
- all LAN networks DNS is AdGuard. AdGuard asks Dnsmasq about LAN hostnames and private reverse records. Its boostrap servers are equal to Unbound's servers and also go through DOH/DOT and WAN to prevent plaintext floating around.

Since firewall's services/plugins beyond DNS also go through WAN, and I definitely don't want ACME or DDNS to be updated via WAN, I set static rules to redirect most of it via VPN gateways.

Since aliases are often empty, the RC syshook with priority 70 refreshes them during boot. Even VPNs use aliases so it's a race condition.

Tons of other mechanisms, like DNS bypass rules, dnsmasq tweaks to forward IPs to nginx or NAS reverse proxy, various VPN rules, captcha avoidance, strict guest isolation etc.

With VPN:
VPN clients can't ever use VPN's own DNS servers. They can't use any SSL / VPN / TOR bypass technique or DNS they like (some malware apps like Google and Facebook would love to), but have to use OPNsense VPN server with all the rules and AdGuard home DNS. Mobile clients are DPI inspected with AdGuard clients, enforced DNS, scripted to avoid Private DNS and other Google garbage, and turn off VPN when connect to WIFI, with extra leak protection with iptables during the 4G <-> WIFI switch. Ethernet clients naturally use local DNS and rules.

Without VPN:
That is avoided. Only exception is firewall basic services like NTP, DNS. Only allowed servers, rest is blocked by WAN rule. Plugins masquerading as firewall can't use WAN. They're analysed for traffic and then forwarded by static routers to VPN. Which is not optimal, as IPs can change. So ideally another WAN rule blocks the rest.

[Patrick M. Hausen]

Another challenge is Unbound doesn't resolve https://forum.openwrt.org/t/unbound-shortname-lookups-non-authoritative-answer/59722/1 LAN addresses well. It can't resolve simple hostnames. Nor hostnames with dots.

It is not the job of a recursive nameserver to append search domains to queries. Your resolver library on the client device is supposed to do that. You need to set the domain or the list or search domains via DHCP. Then whenever you do something like "ping foo" on a client, the client's resolver will try all search domains in turn until it gets a match.

HTH
Patrick

[36thchamber]

It is not the job of a recursive nameserver to append search domains to queries.

Heard of it. Combine all kind of devices, different operating systems, IOT devices and this is unrealistic to achieve, if you want to address hosts by their hostnames. That's why the solution is another resolver, or write your own leasetrigger script.