Hello,
I have a TP-Link BE3600 router and a Raspberry Pi 3b.
The Raspberry Pi has a statically assigned IP address of 192.168.0.20.
When I enter it as the DNS server in the TP-Link, all devices set 192.168.0.20 as their primary DNS, but they automatically add 192.168.0.1 (main router) as their secondary DNS.
Pihole runs with unbound.
If I set primary and secondary 192.168.0.20 network crash.
How can I prevent this? Is the only solution to disable DHCP on the router and run it on Pi-hole?
This may indicate Pi-hole or Unbound are not correctly configured.
Before changing the router settings, please try these commands from a client machine (not from Pi-hole server) and post the output:
nslookup google.com
nslookup google.com 192.168.0.20
Please, also upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
sudo pihole -d
PS C:\Users\M> nslookup google.com
Server: pi.hole
Address: 192.168.0.20
*** pi.hole can't find google.com: Server failed
PS C:\Users\M> nslookup google.com 192.168.0.20
Server: pi.hole
Address: 192.168.0.20
I run sudo pihole -d but I can’t upload log, weird:
[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
* curl failed, contact Pi-hole support for assistance.
* Error message: curl: (6) Could not resolve host: tricorder.pi-hole.net
Added it here:
log.txt (36.3 KB)
It's expected, since you are using 192.168.0.20 as DNS server for Pi-hole server, but Pi-hole is not working, so the server can't resolve domains.
-rw-r--r-- 1 root root 54 Apr 10 21:34 /etc/resolv.conf
nameserver 192.168.0.20
Your log seems to indicate that Unbound is not correctly resolving domains.
Let's temporarily use a different upstream DNS server to debug Pi-hole first.
Please execute this command:
sudo pihole-FTL --config dns.upstreams '[ "8.8.8.8" ]'
Then try both nslookup commands again and try to upload a new debug log.
log: https://tricorder.pi-hole.net/yiDvMNX4/
PS C:\Users\M> nslookup google.com
Server: pi.hole
Address: 192.168.0.20
Non-authoritative answer:
Name: google.com
Addresses: 2a00:1450:4025:804::8a
2a00:1450:4025:804::65
2a00:1450:4025:804::66
2a00:1450:4025:804::64
142.250.130.102
142.250.130.101
142.250.130.138
142.250.130.100
142.250.130.139
142.250.130.113
PS C:\Users\M> nslookup google.com 192.168.0.20
Server: pi.hole
Address: 192.168.0.20
Non-authoritative answer:
Name: google.com
Addresses: 2a00:1450:4025:804::64
2a00:1450:4025:804::8a
2a00:1450:4025:804::65
2a00:1450:4025:804::66
142.250.130.139
142.250.130.113
142.250.130.102
142.250.130.101
142.250.130.138
142.250.130.100
This output shows Pi-hole is working and the Windows machine is already using Pi-hole as DNS server.
It means the issue only happens when you use Unbound as upstream. You can now set 192.168.0.20 as both primary and secondary on your router.
Now we can try to debug Unbound. From Pi-hole server command line, what is the output of this command?
dig google.com @127.0.0.1 -p 5335
; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> google.com -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5383 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;google.com. IN A ;; Query time: 51 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP) ;; WHEN: Sat Apr 11 22:06:54 CEST 2026 ;; MSG SIZE rcvd: 39
Yes, pihole is working now after set secondary dns. I suspected it was unbound. Now, what could have gone wrong with it?
This means Unbound is not able to resolve google.com.
You need to check your unbound config files.
Did you follow Pi-hole guide to configure Unbound?
Did third test. There is a warning:
adam@Pihole:~ $ dig @198.41.0.4 version.bind CH TXT +time=3 ; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> @198.41.0.4 version.bind CH TXT +time=3 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4761 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "ATLAS" ;; Query time: 27 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) (UDP) ;; WHEN: Sat Apr 11 22:22:00 CEST 2026 ;; MSG SIZE rcvd: 59
Did validation tests:
adam@Pihole:~ $ dig pi-hole.net -p 5335 ; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> pi-hole.net -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30886 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;pi-hole.net. IN A ;; Query time: 351 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP) ;; WHEN: Sat Apr 11 22:34:32 CEST 2026 ;; MSG SIZE rcvd: 40 adam@Pihole:~ $ dig fail01.dnssec.works -p 5335 ; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> fail01.dnssec.works -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 921 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;fail01.dnssec.works. IN A ;; Query time: 75 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP) ;; WHEN: Sat Apr 11 22:35:30 CEST 2026 ;; MSG SIZE rcvd: 48 adam@Pihole:~ $ dig +ad dnssec.works -p 5335 ; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> +ad dnssec.works -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3399 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;dnssec.works. IN A ;; Query time: 39 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP) ;; WHEN: Sat Apr 11 22:35:59 CEST 2026 ;; MSG SIZE rcvd: 41
What does below output?
traceroute -n 8.8.8.8
Maybe your ISP applies CGNAT:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 1.262 ms 1.249 ms 1.138 ms
2 91.221.172.1.maxnet.net.pl (91.221.172.1) 3.808 ms 4.172 ms 5.097 ms
3 rs1.maxnet.org.pl (46.175.224.1) 5.016 ms 6.058 ms 6.954 ms
4 * * google1.plix.pl (195.182.219.69) 15.097 ms
5 64.233.174.229 (64.233.174.229) 16.035 ms 15.955 ms 16.045 ms
6 142.250.224.89 (142.250.224.89) 16.429 ms 216.239.40.213 (216.239.40.213) 9.306 ms 108.170.234.101 (108.170.234.101) 9.440 ms
7 dns.google (8.8.8.8) 8.322 ms 8.413 ms 8.330 ms
Hop two is directly to a public IPv4 address 91.221.172.1 and no 100.x.x.x address(es) from the CGNAT wiki.
Am also not sure if a traceroute would actually reveal CGNAT being applied so you're my guinea pig 
But it couldn't hurt inquiring your ISP if they apply CGNAT and asking for assistance bc you shouldnt get a SERVFAIL status return code with below query:
$ dig +ad dnssec.works @127.0.0.1 -p 5335
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +ad dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7586
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dnssec.works. IN A
;; ANSWER SECTION:
dnssec.works. 3600 IN A 46.23.92.212
;; Query time: 99 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sun Apr 12 10:01:04 CEST 2026
;; MSG SIZE rcvd: 57
Unbound does something similar as above dig to check if the replies it receives are legit.
If thats failing, you wouldnt be able to run Unbound with recursive settings like from the official guide.
EDIT: Oh and make sure date/time on your Pi is not too far off which can also cause DNSSEC validation to fail:
timedatectl
Oh another thing, could you post output for below to check how Unbound is configured currently?
sudo rgrep -v '^ *\(#\|$\)' /etc/unbound/unbound.conf*
EDIT: Oh and one more?
dig +norecurse +ad @ns3.myinfrastructure.org. dnssec.works
adam@Pihole:~ $ dig +ad dnssec.works -p 5335 ; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> +ad dnssec.works -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5629 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;dnssec.works. IN A ;; Query time: 43 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP) ;; WHEN: Sun Apr 12 11:29:37 CEST 2026 ;; MSG SIZE rcvd: 41
adam@Pihole:~ $ sudo rgrep -v '^ *\(#\|$\)' /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf: interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf: port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip6: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf: edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf: prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf: so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fe80::/10
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 192.0.2.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 198.51.100.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 203.0.113.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 255.255.255.255/32
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 2001:db8::/32
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf: auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/remote-control.conf:remote-control:
/etc/unbound/unbound.conf.d/remote-control.conf: control-enable: yes
/etc/unbound/unbound.conf.d/remote-control.conf: control-interface: /run/unbound.ctl
adam@Pihole:~ $ dig +norecurse +ad @ns3.myinfrastructure.org. dnssec.works ; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> +norecurse +ad @ns3.myinfrastructure.org. dnssec.works ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34571 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;dnssec.works. IN A ;; Query time: 3 msec ;; SERVER: 5.45.109.212#53(ns3.myinfrastructure.org.) (UDP) ;; WHEN: Sun Apr 12 11:30:46 CEST 2026 ;; MSG SIZE rcvd: 41
What about below one?
Yeah something upstream is bugging your setup:
$ dig +norecurse +ad @ns3.myinfrastructure.org. dnssec.works
[..]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12889
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
[..]
;; ANSWER SECTION:
dnssec.works. 3600 IN A 46.23.92.212
[..]
;; SERVER: 5.45.109.212#53(ns3.myinfrastructure.org.) (UDP)
I suggest contacting your ISP.
adam@Pihole:~ $ timedatectl
Local time: Sun 2026-04-12 20:29:59 CEST
Universal time: Sun 2026-04-12 18:29:59 UTC
RTC time: n/a
Time zone: Europe/Warsaw (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
My experience is that it would 
But you would also notice it when using certain services online and also gaming client software that would start behaving very annoyingly very fast, because it sees a shitload of connections from one IP Address and starts freaking out thinking it’s some kind of security issue 