Please follow the below template, it will help us to help you!
Expected Behaviour:
I use Pihole on a Raspi 3B with Raspi OS 64bit (just installed today). My router is a fritzbox 7360. my isp is Deutsche Telekom.
I have been able to use pihole with unbound for several years without any problems.
Last week there was a power outage and I was away for several days. no dns requests could not be answered for 2 days, but on 3 days after the power outage everything was running again without problems.
Then I installed the new 64bit version of raspi os with pihole following the official instructions from pi-hole.net. In the first days there were no problems, but after that unbound stopped answering dns requests. If I select a third party dns provider then everything runs normally again
Actual Behaviour:
Today I set up my pi from scratch again, but every time I make an unbound request, there is a serverfail. Right after the installation unbound works for a few requests, but after a few minutes no more.
Currently I am using my pihole with third party dns provider and everything works except unbound.
dig pihole.net @127.0.01 -p 5335
; <<>> DiG 9.16.27-Debian <<>> pihole.net @127.0.01 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3154
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pihole.net. IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sun Apr 10 18:18:26 CEST 2022
;; MSG SIZE rcvd: 39
dig sigok.verteiltesysteme.net @127.0.01 -p 5335
; <<>> DiG 9.16.27-Debian <<>> sigok.verteiltesysteme.net @127.0.01 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11577
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigok.verteiltesysteme.net. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sun Apr 10 18:19:18 CEST 2022
;; MSG SIZE rcvd: 55
unbound-checkconf:
unbound-checkconf: no errors in /etc/unbound/unbound.conf
sudo service unbound status:
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-04-10 17:10:04 CEST; 1h 11min ago
Docs: man:unbound(8)
Process: 18941 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
Process: 18944 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
Main PID: 18947 (unbound)
Tasks: 1 (limit: 839)
CPU: 350ms
CGroup: /system.slice/unbound.service
└─18947 /usr/sbin/unbound -d -p
Apr 10 17:10:04 pi systemd[1]: Starting Unbound DNS server...
Apr 10 17:10:04 pi unbound[18947]: [18947:0] info: start of service (unbound 1.13.1).
Apr 10 17:10:04 pi systemd[1]: Started Unbound DNS server.
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf:
server:
# If no logfile is specified, syslog is used
# logfile: "/var/log/unbound/unbound.log"
verbosity: 0
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: yes
# 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.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232
# 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 ab>
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