# Frequent timeout when resolving DNS

**URL:** <https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299>\
**Category:** Help\
**Created:** [August 11, 2019, 3:21am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299 "2019-08-11T03:21:59Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 3:22am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/1 "2019-08-11T03:22:00Z")

</div>

#### 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.

```auto
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

```auto
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

```auto
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](https://tricorder.pi-hole.net/9m7z6bcnou)

---

<div class="post-metadata">

**Author:** ![DanSchaper](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/danschaper/32/91_2.png) [@DanSchaper](https://discourse.pi-hole.net/u/DanSchaper)\
**Post date:** [August 11, 2019, 4:07am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/2 "2019-08-11T04:07:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![DanSchaper](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/danschaper/32/91_2.png) [@DanSchaper](https://discourse.pi-hole.net/u/DanSchaper)\
**Post date:** [August 11, 2019, 4:11am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/3 "2019-08-11T04:11:35Z")

</div>

```plaintext
*** [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`:

```plaintext
    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:

```plaintext
*** [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:

```plaintext
   server=127.0.0.1
   server=127.0.0.1

```

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 4:49am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/4 "2019-08-11T04:49:35Z")

</div>

```
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

```auto
server=127.0.0.1#5353
server=127.0.0.1#5053

```

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 4:51am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/5 "2019-08-11T04:51:11Z")

</div>

```auto
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.

```

---

<div class="post-metadata">

**Author:** ![DanSchaper](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/danschaper/32/91_2.png) [@DanSchaper](https://discourse.pi-hole.net/u/DanSchaper)\
**Post date:** [August 11, 2019, 4:52am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/6 "2019-08-11T04:52:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 4:53am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/7 "2019-08-11T04:53:32Z")

</div>

> 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!

---

<div class="post-metadata">

**Author:** ![jfb](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/jfb/32/4332_2.png) [@jfb](https://discourse.pi-hole.net/u/jfb)\
**Post date:** [August 11, 2019, 5:05am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/8 "2019-08-11T05:05:07Z")

</div>

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'`

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [August 11, 2019, 6:43am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/9 "2019-08-11T06:43:27Z")

</div>

> [@hisname](#):
>
> > 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 may find this 2.5 years old reply useful:

> [@Primary vs. Secondary DNS](https://discourse.pi-hole.net/t/primary-vs-secondary-dns/1536/2):
>
> Following the regulations, there is nothing like a primary and secondary DNS server. These indications are quite misleading but many systems adopted it this way. We only list the DNS servers as primary and secondary, because this is what the providers write on their pages. The bad phrasing is supported especially by how Windows handles it. If you look at any Linux distribution, there is usually no separation between primary and secondary, but you can only provide a comma-separated list of DNS se…

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 9:51am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/10 "2019-08-11T09:51:48Z")

</div>

```auto
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

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [August 11, 2019, 10:03am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/11 "2019-08-11T10:03:44Z")

</div>

> [@hisname](#):
>
> cloudflared

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`).

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 10:05am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/12 "2019-08-11T10:05:13Z")

</div>

> [@DL6ER](#):
>
> is running on your system, too. Is this intended?

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)

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 10:07am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/13 "2019-08-11T10:07:00Z")

</div>

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/](https://www.reddit.com/r/pihole/comments/cobx1n/frequent_timeout_when_resolving_dns/)

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [August 11, 2019, 10:07am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/14 "2019-08-11T10:07:54Z")

</div>

Do you also see delays if you run something like

```plaintext
dig pi-hole.net @8.8.8.8

```

on your Pi-hole several times?

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 10:11am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/15 "2019-08-11T10:11:31Z")

</div>

> [@DL6ER](#):
>
> ```auto
> dig pi-hole.net @8.8.8.8
> 
> ```

```auto
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?)

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [August 11, 2019, 10:14am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/16 "2019-08-11T10:14:26Z")

</div>

> [@hisname](#):
>
> 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).

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 10:17am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/17 "2019-08-11T10:17:33Z")

</div>

using cloudflare and google DNS, I am now having better results. probably due to my unbound misconfig

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [August 11, 2019, 10:26am UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/18 "2019-08-11T10:26:26Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![hisname](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/h/e56c9b/32.png) [@hisname](https://discourse.pi-hole.net/u/hisname)\
**Post date:** [August 11, 2019, 12:44pm UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/19 "2019-08-11T12:44:35Z")

</div>

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 😛 )

 ![network_topology](https://discourse.pi-hole.net/uploads/default/original/2X/9/9aec12276d2f50ae7ab58fa077c178ef4c8dc515.png)

---

<div class="post-metadata">

**Author:** ![jfb](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/jfb/32/4332_2.png) [@jfb](https://discourse.pi-hole.net/u/jfb)\
**Post date:** [August 11, 2019, 1:33pm UTC](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299/20 "2019-08-11T13:33:19Z")

</div>

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?

[Next page](https://discourse.pi-hole.net/t/frequent-timeout-when-resolving-dns/22299.md?page=2)