unbound install error? Topic is solved

[neo-2020]

Both settings are not conflicting and can be set together.

ok, thank you very much.
will make both settings on the router!
helped me a lot!

what about the guest access, does anyone have experience with it in relation to pi-hole?

[Joulinar]

I don't use the guest access. But I did a small test at home and Ad blocking was working as well. This is due to setting #1 as your guest clients are going to use fritz.box as DNS server and the FritzBox will use PiHole. Inside Pihole these request are related to Fritzbox as client.

[neo-2020]

I don't use the guest access. But I did a small test at home and Ad blocking was working as well. This is due to setting #1 as your guest clients are going to use fritz.box as DNS server and the FritzBox will use PiHole. Inside Pihole these request are related to Fritzbox as client.

Perfect!
I'm guaranteed to have more questions soon.
I thank you very much!

[neo-2020]

1. ...
2. ...
3. ...
4. This service adds and removes 127.0.0.1 to /etc/resolv.conf dynamically with Unbound service start and stop, if "resolvconf" is installed (AFAIK it is as a dependency for Pi-hole). That would actually makes sense when you use Unbound directly as local resolver and relativises my argument above at least for maintenance tasks when the service is gracefully stopped. The problem in combination with Pi-hole is that unbound-resolvconf.service manages 127.0.0.1 without port (hence port 53) hardcoded, instead of using the IP + port that it is actually configured to listen on, which is 127.0.0.1:5335 (or 5353), while Pi-hole listens on port 53. Hence it adds and removes Pi-hole as local nameserver entry when the Unbound service is started/stopped, which might not be exactly what you want, e.g. if Pi-hole has a fallback upstream DNS or you actually use Unbound directly with port 5335 or 5353, which would make sense when you want to hide DNS queries from upstream providers but do not need to have ads blocked on the server, where you do not browse websites from .

Hello, you mentioned in your post that you can use unbound to hide the DNS requests from upstream providers.

When I do dnsleaktest I have the answer You use 1 DNS server: my upstream providers server.
My /etc/resolv.conf is: nameserver 127.0.0.1
The connected clients have this output: cat /etc/resolv.conf > nameserver 127.0.0.53
Is that right?
Are the DNS requests still routed to the upstream provider or are the DNS requests safely resolved and saved locally by Unbound?

[MichaIng]

Connected clients should have the Unbound server's local IP address. 127.0.0.53 practically equals 127.0.0.1 (like all 127.* IP addresses), hence loops requests back to the sender. This can hence only work on the machine that runs Unbound, not on other network members.

Unbound (by default) sends DNS requests to DNS root servers directly, the central DNS system itself. No regular public DNS provider is involved, but of course the information needs to be received from somewhere, the DNS root system. Public DNS providers themselves forward/send requests to DNS root servers as well, so when using Unbound, you bypass one intermediate actor. The downside is that, since DNS natively is unencrypted/plain text, requests are send unencrypted to DNS root servers while public providers support encrypted DNS protocols like DoT, DoH, DNScrypt etc. Unbound supports those protocols as well, but then needs to use a public DNS provider again.

So finally it's a question which one you trust more or who you want to hide your requests from:
- Using Unbound with default setup, your ISP is theoretically able to read your DNS requests, as those are send in plain text. But you don't need to trust another public provider like Google or Cloudflare.
- Using Unbound with e.g. DoT enabled, sends requests encrypted to the public provider, hence your ISP cannot read them. But the public provider can read them and sends them unencrypted (obfuscated between many others though) to DNS root servers.
- Using a public DNS provider directly, like

nameserver 8.8.8.8

in /etc/resolv.conf, sends DNS requests unencrypted to the public provider, hence your ISP as well as the public DNS provider can read them.

[neo-2020]

Connected clients should have the Unbound server's local IP address. 127.0.0.53 practically equals 127.0.0.1 (like all 127.* IP addresses), hence loops requests back to the sender. This can hence only work on the machine that runs Unbound, not on other network members.

So everything is right with the clients!?!

OK, thank you very much, basically I understood that.
For me, privacy and security are important, so the Unbound (by default) is no longer used.
Because / whom

1. DNS clear text are sent.
2. My ISP can theoretically read my DNS requests.

...
Unbound supports those protocols as well, but then needs to use a public DNS provider again.
...
- Using Unbound with e.g. DoT enabled, sends requests encrypted to the public provider, hence your ISP cannot read them. But the public provider can read them and sends them unencrypted (obfuscated between many others though) to DNS root servers.

1. What is the configuration for your proposal (Using Unbound with e.g. DoT enabled) in DietPi?
2. If I follow the Guides > DNS > Cloudflared (DoH), do I have to adjust / change something in the DietPi settings in /etc/unbound/unbound.conf.d/....?
3. Is it possible to let DietPi manage everything via my VPN provider?
4. Which option is better to use to encrypt the DNS for my ISP: DoT, DoH?
5. A different / better suggestion for my plan?

I just can't deceide for myself which one to use. This is probably all better than sending DNS in clear text to my ISP. ???!!!???

Thank you

[Joulinar]

So everything is right with the clients!?!

Well you clients would need to point to your local network IP/server your have unbound running on and not to a loopback interface.

DoT, DoH and DNScrypt are completly different types to encrypt your DNS request. Every method has advantages as well as disadvantages. It is not like, method A is better method B

At the end you would need to decide whom you are trusting, because someone need to read your DNS request. It could be you ISP, one of the global DNS provider or the root DNS server.

An easy way to setup DoH is describe on PiHole wiki https://docs.pi-hole.net/guides/dns/cloudflared/
There is no need to setup PiHole but it describe how to setup a cloudflare tool to be able to use DoH. The DoH DNS provider can be chosen by yourself as well.

[neo-2020]

Well you clients would need to point to your local network IP/server your have unbound running on and not to a loopback interface.

in network manager (Ubuntu) the local network IP / server of the pi-hole is displayed, but in terminal cat /etc/resolv.conf> nameserver 127.0.0.53 Strange or Right?

DoT, DoH and DNScrypt are completly different types to encrypt your DNS request. Every method has advantages as well as disadvantages. It is not like, method A is better method B

At the end you would need to decide whom you are trusting, because someone need to read your DNS request. It could be you ISP, one of the global

That is of course understandable. What are the advantages and disadvantages of DoH and DoT?

An easy way to setup DoH is describe on PiHole wiki https://docs.pi-hole.net/guides/dns/cloudflared/

Very important
I would combine that with pi-hole. Is it enough to install as specified in PiHole wiki guides or does it require further settings with DietPi. As in:

• /etc/unbound/unbound.conf.d/dietpi.conf
• /etc/unbound/unbound.conf.d/dietpi-pihole.conf> change port to 5053?
• /etc/dhcpcd.conf> change static domain_name_servers to 5053?
• more settings??

After install and the simple change in Settings> DNS> Upstream DNS Servers> Custom 1 (IPv4) to 127.0.0.1#5053 Recent Queries (showing queries for client) is still displayed. Is that right? It must now be encrypted or not visible via DoH, or not?

[Joulinar]

there is a small DNS over TLS vs. DNS over HTTPS at cloudflare site https://www.cloudflare.com/learning/dns/dns-over-tls/

If you you like to use DoH I would recommend to

1. install normal PiHole from dietpi-software.
2. Once done follow the guide at PiHole wiki to just install the Cloudflare tool (as we have PiHole already be installed)
   https://docs.pi-hole.net/guides/dns/cloudflared/
3. Adjust PiHole DNS to point to the Cloudflare tool

That's quite a easy way without that much configuration effort needed

[MichaIng]

Just keep in mind that those large public DNS providers are much more likely using your data, even if anonymized, than your ISP does, at least in most countries. Working with that data is often (part of) the business model, in case of Google it's obvious, in case of Cloudflare for their statistics and research to gain and show expertise, enhance and sell their paid service plans. It would be naive to think that you get a service completely for free without paying at least with your data in a way from such type of company. Only when there is a non-profit organisation with transparent donation-based (or supported by public in other ways) finances, like Let's Encrypt, it might be different. E.g. Quad9 could be quite trustable as it's operated by a non-profit, though supported by large companies as well like IBM.

So what I want to say is that in most cases I would rather trust the often small local ISP more than a global DNS provider, especially since when using Unbound, your DNS requests do not address the ISP. So even if your ISP would use your data when you use its DNS service (often ISPs provide DNS services as well, as default for their router products etc), to assume that it sneaky reads your DNS requests to the DNS root servers to collect your data is probably mistrust at the wrong place. But of course in a suppressive political system it might be the opposite way round .

Another hint about Unbound config: Remove /etc/unbound/unbound.conf.d/dietpi-pihole.conf and apply interface and port directly in /etc/unbound/unbound.conf.d/dietpi.conf. We did falsely assume that dietpi-pihole.conf would override dietpi.conf, but actually it adds that ip/port binding, so Unbound would then listen on two ports. This is fixed with next release already.

If you want to use DoT, with Unbound the following should work: https://www.dnsknowledge.com/unbound/co ... -on-linux/

Code: Select all

cat << '_EOF_' > /etc/unbound/unbound.conf.d/dietpi-dot.conf
# Adding DNS-over-TLS support 
server:
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
forward-zone:
name: "."
forward-tls-upstream: yes
## Cloudflare
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com
## Quad9
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net
## Cloudflare IPv6
forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
_EOF_

The forward-addr entries are just examples, Cloudflare IPv6 is not required to resolve hostnames to IPv6 addresses, but only if for some reason you want to have the request sent over IPv6 for some reason. Using only a single forward-addr will work as well, I'm not sure how fallbacks are done by Unbound, e.g. in which case/how fast it will try the second entry, if the first cannot be connected to. A separate file can be used safely here since this forward-zone block is not present in dietpi.conf . So DoT can be easily reverted by removing the dietpi-dot.conf.

Here a large list of public DNS providers, their IPs and their in cases included ad blocking / adult content blocking features: https://wikipedia.org/wiki/Public_recursive_name_server

DoH is supported by newest Unbound as well . But AFAIK not by the version shipped with Debian Buster . So in case of DoH, for now I agree with Joulinar that cloudflared seems to be a good solution (it can be used with any DNS provider, not just Cloudflare itself) and Unbound is not required anymore then.