neo-2020
Within DietPi 6.34 we have some challanges around unbound. But we will introduce quite some improvement with DietPi 6.35
This is the related pull request on GitHub. https://github.com/MichaIng/DietPi/pull/4022
then i will wait for the official update.
can someone please answer my questions?
My question:
1: must comment out in /etc/systemd/resolved.conf # DNSSEC = allow-downgrade and replace allow-downgrade with off?
2: does /etc/resolv.conf nameserver have to be changed to 127.0.0.1?
3: systemctl status dhcpcd.service is inactive (dead), is that correct?
4: systemctl status unbound-resolvconf.service is inactive (dead), is that correct?
5: how to update from /var/lib/unbound/root.hints. Once in six months? about cromjob? or is that already automated by dietpi?
6: Which other settings have to be set in order to use Unbound correctly?
Many Thanks!
usually DietPi will take care on all settings needed to have unbound working correctly, as well in combination with PiHole.
TL;DR nothing to do aside of:
echo -e '#!/bin/dash\ncurl -sSfL https://www.internic.net/domain/named.root -o /var/lib/unbound/root.hints' > /etc/cron.monthly/dietpi-unbound
chmod +x /etc/cron.monthly/dietpi-unbound
Details:
- /etc/systemd/resolved.conf is relevant for systemd-resolved only, which is not used by default on DietPi to manage /etc/resolv.conf. If you actively use it (manually enabled it for a specific purpose), and you use Unbound to resolve hostnames for the DietPi server itself, then you can indeed either leave DNSSEC in for resolved commented (default) or set it to “no” actively.
- /etc/resolv.conf defines the DNS nameservers for the DietPi server itself. I usually do not recommend to use a servers own services by the server itself for such a critical service. E.g. when you do some remote maintenance, update or such and for some reason Unbound crashes or does not start up, the DietPi server itself cannot resolve hostnames anymore, which may break further steps to repair/debug the situation and may even lock you out in some circumstances (I just remember two cases where with Pi-hole this was an issue). For this reason, also Pi-hole does not enforce itself as local resolver anymore on install. Since you don’t use the server for browsing the web, usually, there is usually not much reason to use no regular upstream DNS server, but it depends on the individual use case of course.
- Yes this is correct, we do not use a DHCP client to disable DHCP (what Pi-hole does, as on Raspbian by default dhcpcd is used for network setup in general), but use the Debian default method which sets up network interfaces via /etc/network/interfaces. dhcpcd can conflict with this and is unnecessary then, so we disable it. Luckily Pi-hole is about to remove the forced dhcpcd install, so the package and service won’t be present then anymore: https://github.com/pi-hole/pi-hole/pull/3715
- 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
. - Good point and idea, that one is missing in our docs. Probably we can add a monthly cron job
. Do:
curl -sSfL https://www.internic.net/domain/named.root > /var/lib/unbound/root.hints
- None that I am aware of, otherwise we would set it during install already .
well we could blase a small script into /etc/cron.monthly to refresh root.hints??
See the two commands I posted above. We could add then as is to dietpi-software. I just verified, if any error occurs with the connection, -o /var/lib/unbound/root.hints won’t override the target file, compared to simple redirect > /var/lib/unbound/root.hints.
Ah I should read with more care 
Overlooked the first comment
Likely because I edited it inside after you read .
MichaIng
First of all, many thanks for the detailed explanation!
As far as I understand everything, I hope that my settings are correct! I’m very happy.
Next question about the setting in router:
Where is it correct or better to enter the pi-hole ip in the router (fritzbox)?
1: Internet > Zugangsdate > DNS-Server > Bevorzugter DNSv4-Server
or
2: Heimnetzt > Netzwerk > Netzwerkeinstellungen > IPv4-Konfiguration > Lokaler DNS-Server
Where’s the difference? I never got it right 
And what about the guest access, are the guests also directed via pi-hole? the guest access uses a different IPv4 address / IP address range 192.168.179.1!
Guest network
The FRITZ! Box guest network has its own IP address range from which the FRITZ! Box assigns the IP addresses to the guest devices. The address range is determined by the FRITZ! Box and cannot be changed.
Setting 1 is the DNS settings for your FritzBox. This is the DNS Server your FritzBox is using to answer DNS queries. If nothing else set, all clients will use the FritzBox as DNS server and inside PiHole you will see just the FitzBox as client.
Setting 2 is the DNS server that will be published to your client. Now your clients will use PiHole as DNS server and DNS queries will go directly to PiHole. Inside PiHole you will see all clients separately now, allowing you to configure and manage them individually as you like. Maybe your kids needs a stronger setting than you.
Both settings are not conflicting and can be set together.
Personally I’m using a 3rd option. I deactivated DHCP on my FritzBox and I’m using PiHole as DHCP server.
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?
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!
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?
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.
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
- DNS clear text are sent.
- My ISP can theoretically read my DNS requests.
- What is the configuration for your proposal (Using Unbound with e.g. DoT enabled) in DietPi?
- 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/…?
- Is it possible to let DietPi manage everything via my VPN provider?
- Which option is better to use to encrypt the DNS for my ISP: DoT, DoH?
- 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
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 cloudflared (DoH) - Pi-hole documentation
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.
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?
That is of course understandable. What are the advantages and disadvantages of DoH and DoT?
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?
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
- install normal PiHole from dietpi-software.
- 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/ - Adjust PiHole DNS to point to the Cloudflare tool
That’s quite a easy way without that much configuration effort needed
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/configure-unbound-dns-over-tls-on-linux/
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.