PIHOLE_DNS_1=127.0.0.1#5353 <- that's the unbound resolver
PIHOLE_DNS_2=127.0.0.1#5053 <- that's the cloudflared resolver as a backup
My /etc/dnsmasq.d/01-pihole.conf
has this entry though
server=127.0.0.1#5353
server=127.0.0.1#5053
PIHOLE_DNS_1=127.0.0.1#5353 <- that's the unbound resolver
PIHOLE_DNS_2=127.0.0.1#5053 <- that's the cloudflared resolver as a backup
My /etc/dnsmasq.d/01-pihole.conf
has this entry though
server=127.0.0.1#5353
server=127.0.0.1#5053
C:\Users\User>tracert 157.240.13.35
Tracing route to 157.240.13.35 over a maximum of 30 hops
1 <1 ms 1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 * * 7 ms 1.128.104.27.unknown.m1.com.sg [27.104.128.1]
4 * * * Request timed out.
5 * 3 ms 3 ms ISP_IP.unknown.m1.com.sg [ISP_IP]
6 4 ms 4 ms 7 ms ISP_IP..unknown.m1.com.sg [ISP_IP]
7 * * * Request timed out.
8 * * * Request timed out.
9 * 1082 ms 4 ms po245.psw02.sin6.tfbnw.net [129.134.38.135]
10 4 ms 4 ms 3 ms 157.240.36.35
11 * * * Request timed out.
12 * * * Request timed out.
13 * * 4 ms edge-star-mini-shv-02-sin6.facebook.com [157.240.13.35]
Trace complete.
There is no such thing as a backup DNS or secondary DNS. Both will be used.
That traceroute shows me that you have some big network issues that need to be resolved first.
There is no such thing as a backup DNS or secondary DNS. Both will be used.
Never knew that. I will do some research about this issue. thanks!
You can run this command from the Pi terminal to see which processes are running related to Pi-Hole. Your debug log shows some problems.
sudo netstat -nltup | grep 'Proto\|:53 \|:5053 \|:5353 \|:67 \|:80 \|:471'
You may find this 2.5 years old reply useful:
pi@raspberrypi:~ $ sudo netstat -nltup | grep 'Proto\|:53 \|:5053 \|:5353 \|:67 \|:80 \|:471'
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 13793/pihole-FTL
tcp 0 0 127.0.0.1:5053 0.0.0.0:* LISTEN 7048/cloudflared
tcp 0 0 127.0.0.1:4711 0.0.0.0:* LISTEN 13793/pihole-FTL
tcp 0 0 127.0.0.1:5353 0.0.0.0:* LISTEN 9399/unbound
tcp 0 0 127.0.0.1:5353 0.0.0.0:* LISTEN 9399/unbound
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 1767/lighttpd
tcp 0 0 192.168.1.138:80 0.0.0.0:* LISTEN 1767/lighttpd
tcp6 0 0 :::53 :::* LISTEN 13793/pihole-FTL
tcp6 0 0 ::1:4711 :::* LISTEN 13793/pihole-FTL
tcp6 0 0 :::80 :::* LISTEN 1767/lighttpd
udp 0 0 127.0.0.1:5053 0.0.0.0:* 7048/cloudflared
udp 0 0 0.0.0.0:53 0.0.0.0:* 13793/pihole-FTL
udp 0 0 127.0.0.1:5353 0.0.0.0:* 9399/unbound
udp 0 0 127.0.0.1:5353 0.0.0.0:* 9399/unbound
udp6 0 0 :::53 :::* 13793/pihole-FTL
Seems to me that unbound and pihole-ftl is running
is running on your system, too. Is this intended?
Please check /var/log/pihole.log
to see if there are explanations for the delays you see (or if just no response comes back). You can also enable logging in unbound
to see what it is doing and why things are taking as long as they do. It is normal that initial lookups are slower as unbound
first has to walk down from the root zone over the TLD. However, this shouldn't take more than (very) few seconds and should also not happen more than once (after restarting unbound
).
yes this was intended. As per my previous comment, it was a "backup" DNS server. I have since removed the DNS entry in pihole. (PIHOLE_DNS_2=127.0.0.1#5053)
i forgot to mention that I was using google, cloudflare and DNS.watch. they are having issues too. https://www.reddit.com/r/pihole/comments/cobx1n/frequent_timeout_when_resolving_dns/
Do you also see delays if you run something like
dig pi-hole.net @8.8.8.8
on your Pi-hole several times?
pi@raspberrypi:~ $ dig pi-hole.net @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> pi-hole.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17103
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net. IN A
;; ANSWER SECTION:
pi-hole.net. 267 IN A 206.189.252.21
;; Query time: 6 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 11 18:08:43 +08 2019
;; MSG SIZE rcvd: 56
pi@raspberrypi:~ $ dig pi-hole.net @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> pi-hole.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21208
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net. IN A
;; ANSWER SECTION:
pi-hole.net. 270 IN A 206.189.252.21
;; Query time: 9 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 11 18:08:44 +08 2019
;; MSG SIZE rcvd: 56
pi@raspberrypi:~ $ dig pi-hole.net @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> pi-hole.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2736
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net. IN A
;; ANSWER SECTION:
pi-hole.net. 299 IN A 206.189.252.21
;; Query time: 56 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 11 18:08:44 +08 2019
;; MSG SIZE rcvd: 56
pi@raspberrypi:~ $ dig pi-hole.net @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> pi-hole.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6050
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net. IN A
;; ANSWER SECTION:
pi-hole.net. 264 IN A 206.189.252.21
;; Query time: 6 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 11 18:08:45 +08 2019
;; MSG SIZE rcvd: 56
pi@raspberrypi:~ $ dig pi-hole.net @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> pi-hole.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55962
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net. IN A
;; ANSWER SECTION:
pi-hole.net. 294 IN A 206.189.252.21
;; Query time: 6 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 11 18:08:45 +08 2019
;; MSG SIZE rcvd: 56
pi@raspberrypi:~ $ dig pi-hole.net @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> pi-hole.net @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached
pi@raspberrypi:~ $ dig pi-hole.net @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> pi-hole.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52523
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net. IN A
;; ANSWER SECTION:
pi-hole.net. 223 IN A 206.189.252.21
;; Query time: 5 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 11 18:09:31 +08 2019
;; MSG SIZE rcvd: 56
It does timeout after a couple of requests. I assume that is normal? (google preventing ddos on their infra?)
It depends on your definition of "couple of times". I just did this 500 times to 8.8.8.8
and always received a reply (query time is about 15msec for me).
using cloudflare and google DNS, I am now having better results. probably due to my unbound misconfig
Someoe* (or rather something**) seems to be rate-limiting your Internet connection.
This explains why you have more issues with unbound
as it has to do many more requests when walking the entire DNS path compared to a single request you send out to some external recursive DNS resolving service such as Google's DNS.
*) Maybe your Internet service provider (ISP)?
**) Maybe even your router?
probably my router since I doubt my ISP throttle my network. thanks for your help. Could be my router 2 having issues since if i were to directly connect to router 1, there is no problems at all.(Yes I took CCNA in 2016 but I didn't went for certification )
Why is your Pi-Hole on the router for untrusted devices? Have you tried connecting it to Router 1? With your routers in this configuration, are you double-NAT'd?
thanks! I went to read up on double NAT. My network config was wrong as I have 2 192.168.1.1
, it probably got confused with routing. I changed router 2 to 192.168.2.1
and I don't have anymore timeout!
It appears in this configuration that neither of the phones are using Pi-Hole for DNS. Is that intentional?
Yes its intentional. This is just a simplied version of my network