When setting up PiHole to use unbound (Upstream DNS Server: 127.0.0.1#5335) name resolution works correctly.
Environment: Raspberry Pi 2 Model B Rev 1.1
OS: Raspbian GNU/Linux 11 (bullseye)
Actual Behaviour:
Once I remove any other Upstream DNS Servers, DNS resolution stops working, when pinging a domain I get the following on a Windows 10 machine:
C:\Users\xxx>ping www.microsoft.com
Ping request could not find host www.microsoft.com. Please check the name and try again.
server:
# If no logfile is specified, syslog is used
logfile: "/var/log/unbound/unbound.log"
verbosity: 1
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: no
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
# root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
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
C:\Users\xxx>nslookup www.microsoft.com
Server: pi.hole
Address: 192.168.1.3
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to pi.hole timed-out
This indicates problems when unbound is trying to contact one of the authoritative DNS servers. Unfortunately, SERVFAIL is a very generic error, giving us no details what exactly went wrong.
To name just two possible reasons, your unbound may be unable to communicate with upstream authoritative servers (e.g. because your ISP blocks or redirects DNS queries), or unbound may fail to verify the DNSSEC chain.
Is that just www.microsoft.com failing, or does this happen for other domains as well?
Thank you for the answer. I am starting to understand now...: When I said name resolution was working fine, I made a mistake as I did the test while still having other Upstream DNS Servers... And then it worked. My mistake - sorry about that. Does this new info help at all?
No, it is not only microsoft.com, all the domains fail to resolve resulting in not being able to do any browsing on the network.
Also, let me mention, that in my current setup, https://www.dnsleaktest.com/ reports no leak. Does this say anything about the ISP blocking (or not) DNS queries? I would think this means that the ISP is now completely bypassed by DNS queries.
A DNS leak would occur if a VPN client would not send its DNS requests through the VPN tunnel it is supposed to use. If you are not using a client that is currently connected to a VPN, the concept of DNS leakage does not apply at all.
Let 's try to find out whether your DNS requests get redirected.
Run from a client, what's the output of:
nslookup flurry.com 80.241.218.68
And from your RPi:
dig flurry.com @80.241.218.68
EDIT:
Re-reading your post, I don't think there's redirection, as your dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335 was successful.
DNSSEC is being done by unbound. The DNSSEC option in Pi-hole is not required for unbound to do this. Enabling this option in Pi-hole adds the DNSSEC status in the query log.
What are you trying to do here? You are forwarding all queries from unbound back to Pi-hole for resolution, which creates a circular loop. Pi-hole doesn't know the answer, it forwards the query to unbound to resolve, unbound sends it back to Pi-hole.
Local domains should have already been resolved by Pi-hole prior to them being sent to unbound.
If you intend to run unbound as a recursive resolver (which is what our guide sets up), eliminate this file and restart unbound.
I removed the file, restarted unbound, but I can't change pihole yet, as I can't interrupt the network again. I'll do it shortly and will report back. If you can think of any way to test it please let me know.
pi@pi3:~ $ dig cnn.com @127.0.0.1 -p5335
; <<>> DiG 9.16.15-Raspbian <<>> cnn.com @127.0.0.1 -p5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25257
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;cnn.com. IN A
;; ANSWER SECTION:
cnn.com. 60 IN A 151.101.65.67
cnn.com. 60 IN A 151.101.129.67
cnn.com. 60 IN A 151.101.1.67
cnn.com. 60 IN A 151.101.193.67
;; Query time: 340 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Fri Sep 17 18:13:26 EEST 2021
;; MSG SIZE rcvd: 100
Please correct me, but I think the Upstream DNS Servers option in PiHole should only have 127.0.0.1#5335 and not others. Currently, I also have a Quad 9 DNS selected, otherwise I couldn't even write these lines.
This is how it looks at the moment (so that the network is usable):
This is true. You can remove the Quad9 and your Pi-hole should continue working now that you have fixed the unbound problem. To confirm this, delete Quad 9 server, then run the following commands. The first routes a DNS query through Pi-hole, which should then send it to unbound. The second confirms that the request was processed by Pi-hole and unbound as intended.
