Hallo,
hab gerade bei Heise folgendes gesehen:
wäre es möglich und überhaupt sinnvoll das auf dem Pi einzurichten?
English translation by @DL6ER: This article describes downloading and maintaining a local copy of the DNS root zone. Te question is whether it is possible and/or useful to do this on a Raspberry Pi.
Sorry, I don't speak german…
In order to do this you need to implement the unbound solution, proposed by the pihole developers.
Duplicating the root zone (zone transfert) has been partially discussed here
I'm running the latest version of Raspbian (oktober 2018). It isn't possible with the unbound version, included in this distro, you need at least unbound version 1.7 (mentioned in the article (on discourse)).
It is however possible to compile and use the latest version of unbound (1.8.1) and use the feature. This requires a lot of work, since the original Raspbian package (version 1.6.x) doesn't appear to use chroot, and some additional software (not included in the unbound package)
The unbound config I'm using looks like this (everything ends up in /etc/unbound):
server:
logfile: /unbound.log
verbosity: 1
interface: 127.x.x.x@55xx
interface: xxxx:xxxx:xxxx:xxxx::xxxx@55xx
do-ip4: yes
do-udp: yes
do-tcp: yes
do-ip6: yes
root-hints: "/root.hints"
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: no
cache-min-ttl: 3600
cache-max-ttl: 86400
prefetch: yes
num-threads: 1
so-rcvbuf: 1m
edns-buffer-size: 1472
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
for some reason, discourse doesn't show the entire config file, so the config continues here (It is a single config file)...
remote-control:
control-enable: yes
auth-zone:
name: "."
master: i.root-servers.net
master: f.root-servers.net
master: j.root-servers.net
master: k.root-servers.net
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/root.zone"
I've copied the original unbound.conf from the raspian distribution, witch simply includes everything in /etc/unbound/unbound.conf.d. I've also copied /etc/unbound/unbound.conf.d/qname-minimisation.conf and /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf from the Raspbian distribution into that directory, and placed my unbound.conf (see above) in this directory
To compile unbound 1.8.1 (on Raspbian), I'm using the following script:
#!/bin/bash
# Make sure only root can run our script
if [ "$(id -u)" != "0" ]; then
echo "This script must be run as root" 1>&2
exit 1
fi
# install dnsutils
sudo apt-get -y install dnsutils
# install drill
# usage drill txt qnamemintest.internet.nl
# result HOORAY - QNAME minimisation is enabled on your resolver
sudo apt-get -y install ldnsutils
sudo apt-get -y install libssl-dev
sudo apt-get -y install libexpat1-dev
sudo groupadd -g 991 unbound
sudo useradd -c "unbound-1.8.1" -d /var/lib/unbound -u 991 -g unbound -s /bin/false unbound
file=unbound-1.8.1
mkdir -p unbound
cd unbound
wget https://nlnetlabs.nl/downloads/unbound/$file.tar.gz
for some reason, discourse doesn' show the entire script, so script continues here (It is a single script)...
tar xzf $file.tar.gz
cd $file
sudo ./configure --prefix=/usr --sysconfdir=/etc --disable-static --with-pidfile=/run/unbound.pid
sudo make
sudo make install
I haven't figured out how to compile unbound with system, so I created my own /lib/systemd/system/unbound.service, content:
[Unit]
Description=Unbound DNS server
Documentation=man:unbound(8)
Requires=network.target
Wants=nss-lookup.target
Before=nss-lookup.target
After=network.target
[Service]
ExecStartPre=/usr/sbin/unbound-anchor -a /etc/unbound/root.key -v
ExecStart=/usr/sbin/unbound -d -v
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=360
[Install]
WantedBy=multi-user.target
enable the unbound system configuration, using this:
sudo systemctl daemon-reload
sudo systemctl enable unbound.service
Hope this helps, I also wonder if this is beneficiary for privacy...
thanks for the extensive reply!
you think its not really worth the effort to do this? my first thought was something like that, too. perhaps i will try it anyway when im really extremely bored 
NOT entirely sure it is worth the effort, I did it anyway...
@DL6ER
Is this beneficiary for privacy?
How to verify the unbound DNS request to the root entries are using the local copy?
How often do you need to update the copy? It currently does this only when unbound starts, unless forced by sudo /usr/sbin/unbound-control auth_zone_transfer "."
have it up and running now, seems to be quite quick an can give a little bit of privacy perhaps...
edit: only seemed to be any effort btw, followed these:
https://docs.pi-hole.net/guides/unbound/
and it took something about 5 minutes...
No. Full-stop.
With qname minimization (enabled by default), the root servers will only be queried for the TLD, i.e., the request will only be for .de or .com. There is no way this would leak anything really. In addition, you'll still have to contact the name servers one level further down, so anyone "watching" you will still know if you visit a suspicious, e.g., Russian webpage.
TL;DR: No privacy is gained by having a local copy.
What it will be beneficial for is that it will provide a local copy for the top level. This will speed up the first query for an individual TLD after unbound has been restarted. After the first query, e.g., to something.de, your local unbound will hold the corresponding reply in it's cache and will also take care of always refreshing the information before it expires so there should be no benefit at all once you queried domains under all relevant TLDs at least once.
I looked at the article @Troy_McClure posted above and they mix up a few things.
To summarize things: As unbound used an internal cache, qname minimization and does DNSSEC validation by default, the vast majority of the benefits mentioned in the article are void.
Furthermore, as Pi-hole is cascaded in front, requests for your local domain should not even be forwarded to unbound and can also never propagate through to the root servers (this is once thing they mention concerning privacy).
I cannot give any reliable figures, but I doubt that they'd need to be updated more often than maybe once a month. Maybe once every three months or even once a year is sufficient. The DNS servers referenced in this data are all global players, being relevant/responsible for an entire TLD such as .com, I don't think that the IP addresses of these servers change very often.
I will rename the header and move this into General so everyone can have a look at this discussion.
will it be more beneficiary for privacy with this Option disabled and will that give a big/any performance impact?
not the pentagon at here but why not use such a solution...
This is actually rather difficult to answer. From my experience, I'd say that all issues with qname minimization have been fixed and that there is no obvious benefit in disabling it. Disabling it would clearly not increase privacy (rather decrease it!).
ok, when qname minimization is ok, what else voids the benefits mentioned ?
One of the points / or maybe their major point is that a local copy would eliminate the first query to the root servers. This argument is nullified by unbound's cache as it would never query the root zone again for a TLD as it already stores a local copy once the first query was made.
Don't misunderstand me - I'm mainly arguing that unbound is already so efficient and well implemented that most of the problems they address and that could be solved by a local copy don't even exist in the first place - there is no room for improvement if your existing server already does most of it.
Just a small hint: This will cause a notable increase in the amount of that that is sent around and will likely increase delays in transit. Well, it will probably to too bad in the end when your Pi-hole can utilize the cache to a sufficient amount.
Well, it very much depends on your particular setup. Anyways I just wanted to point this out in case others users will find this at some point in the future and would blindly follow any configs they find online.
There is no harm in double caching things. The TTL should ensure that the data is kept only as long as it is meaningful.
Not if you are visiting the same page multiple times - often enough browsers like Firefox send dozens of queries even when visitng a page only once while it is loading the multiple contents that are there on modern webpages.
Furthermore, Pi-hole (as a DNS frontend) caches only exact hits (like whatever.domain.com). Unbound (as DNS backend / recursive resolver) will also cache the answers for domain.com and (quite importantly) com.
You mentioned pre-fetching. This is also very useful and will help with the overall latency of your system.
Conclusion: Both caches have their place: Exact matches are quickly answered by Pi-hole itself. Partial matches shorten the DNS path, unbound has to traverse if it holds parts of this path (e.g. domain.com) already in its cache. If Pi-hole's cache wouldn't be there, everything would always have to be passed to unbound (just another step in the chain causing some unnecessary delay). If unbounds cache wouldn't be there, unknown domains would have to be walked every time starting from the root zone down to the node you requested.