Frequent timeout when resolving DNS

Please follow the below template, it will help us to help you!

Expected Behaviour:

DNS should be resolved on first try.

Actual Behaviour:

I am running pihole inside a container with Unbound as my resolver. Pihole takes a long time to resolve the first DNS request to the point where browsing experience is better without pihole. Subsequent requests are better.

pi@raspberrypi:~ $ dig facebook.com

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> facebook.com
;; global options: +cmd
;; connection timed out; no servers could be reached

pi@raspberrypi:~ $ dig facebook.com

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9867
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;facebook.com.                  IN      A

;; ANSWER SECTION:
facebook.com.           287     IN      A       157.240.13.35

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Aug 10 09:41:23 +08 2019
;; MSG SIZE  rcvd: 57

On my Windows Machine

C:\Users\User>tracert facebook.com

Tracing route to facebook.com [157.240.13.35]
over a maximum of 30 hops:

  1     1 ms     1 ms     5 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        4 ms     4 ms  IP_ADDRESS_REMOVED.unknown.m1.com.sg [IP_ADDRESS_REMOVED]<- This is my ISP
  5     6 ms     4 ms     4 ms  IP_ADDRESS_REMOVED.unknown.m1.com.sg [IP_ADDRESS_REMOVED]<- This is my ISP
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     5 ms     5 ms     5 ms  po744.psw03.sin6.tfbnw.net [129.134.43.99]
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13    93 ms     5 ms     5 ms  edge-star-mini-shv-02-sin6.facebook.com [157.240.13.35]

Trace complete.

This is my Pihole setupVars.conf

BLOCKING_ENABLED=true
QUERY_LOGGING=true
INSTALL_WEB_SERVER=true
INSTALL_WEB_INTERFACE=true
LIGHTTPD_ENABLED=
IPV4_ADDRESS=192.168.1.138
IPV6_ADDRESS=
PIHOLE_INTERFACE=eth0
DNSMASQ_LISTENING=local
PIHOLE_DNS_1=127.0.0.1#5353
PIHOLE_DNS_2=127.0.0.1#5053
DNS_FQDN_REQUIRED=true
DNS_BOGUS_PRIV=true
DNSSEC=false
CONDITIONAL_FORWARDING=false

I have tried a "hack" which is to increase dns cache size and ttl so that dns lookup will be faster. but not a lot anyway.
I am running OpenWRT as my DHCP on my router and I can provide more info if needed. Thanks for any help provided!

Debug Token:

https://tricorder.pi-hole.net/9m7z6bcnou

Does a trace to the bare IP without resolving names have the same bad hops?

*** [ DIAGNOSING ]: Ports in use
[*:53] is in use by pihole-FTL
[*:53] is in use by pihole-FTL
[127.0.0.1:4711] is in use by pihole-FTL
[[::1]:4711] is in use by pihole-FTL

There is no Unbound resolver listening as you have configured setupVars.conf:

    PIHOLE_DNS_1=127.0.0.1#5353
    PIHOLE_DNS_2=127.0.0.1#5053

And a test to 8.8.8.8 for DNS resolution fails:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] www.fiestasypinatas.net is 0.0.0.0 via localhost (127.0.0.1)
[✓] www.fiestasypinatas.net is 0.0.0.0 via Pi-hole (192.168.1.138)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

/etc/dnsmasq.d/01-pihole.conf has some misconfigurations as well:

   server=127.0.0.1
   server=127.0.0.1
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.

1 Like

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 :stuck_out_tongue: )

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?