Thanks for your quick answer!
If I understand correctly:
- Unbound replaces the Google or Cloudflared Dns provider in order to avoid DNS leak and maybe improve overall DNS response and stability
- Adguard is a DNS filter and can be linked to the Ubound install instead of Google or Cloudflare so that it uses local resolving stuff
If you send all traffic to Adguard, how can it leak to the ISP since you add upstream DNS resolvers? Unless some traffic is still router to ISP ?
Even though unbound is strictly used by clients, when you introduce adguardhome in the middle, it will read from the entries of whatever is in /etc/resolv.conf. in most cases this is your ISP dns servers listed as nameservers, unless you have chosen like 1.1.1.1 on wan dns 1 and wan dns 2. It creates the potential for adguardhome to leak your private lookups back to your ISP since it considers the entries of /etc/resolv.conf to be private reverse servers, which would skip your unbound and dnsmasq dhcp implementations all together.)
Here is a map of your request with just DNSMASQ and UNBOUND
/etc/resolv.conf (for non local lookups a.k.a router)
^
|
|
|
DNSMASQ----------->UNBOUND
here is is with adguardhome + unbound
DNSMASQ (moved to port 553) (reverse lookups are kept local when sent here by use of local= lines)
^
|
|
|
AdGuardHome (reads /etc/resolv.conf for private reverse servers) ------------------> Unbound for upstream
|
|
|
V
/etc/resolv.conf (usually ISP or WAN DNS is placed here as name servers and this typically deals with the routers own traffic like with dnsmasq.)
The real problem comes in when your Adguardhome server cannot determine a clients hostname, it will revert to using whois in an attempt to identify the device from your ISP servers listed in /etc/resolv.conf
Some users may consider this all arbitrary, which in an ideal situation it could be considered arbitrary. But if you are truely concerned about what you keep private, then where do you draw the line at?
That is why I atleast want to give users a choice on the matter.