Two piholes resolve but receive “DNS request timed out”

Help
1

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

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

DNS resolution without timeout error

Actual Behaviour:

I have two Raspberry Pi 1's Model B Rev 2 running PiHole with a static IP, both IP's are configured on the router, and the clients randomly pick one of the DNS servers, the first seems to get the most request with the second only getting a few.

C:\Users\User>nslookup retrogamingcables.co.uk
Server:  pi-dns-1
Address:  192.168.0.11

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to pi-dns-1 timed-out

Debug Token:

pi-dns-1: https://tricorder.pi-hole.net/o86ph2r0sg
pi-dns-2: https://tricorder.pi-hole.net/7rb6lgkixs

2

Time-outs could indicate a DNS loop, something preventing your Pi-hole to receive requests, or Pi-hole's upstream DNS servers not responding.

Since your debug log shows you are neither using Conditional Forwarding nor your router as Pi-hole's upstream, you haven't closed a loop.

Next, verfify that Pi-hole's required ports are not blocked by a firewall on your RPis.

Also, your debug log shows your time is off, which may interfere with upstream resolution:

*** [ DIAGNOSING ]: contents of /var/log

-rw-r--r-- 1 pihole pihole 264399 Jul  6 09:32 /var/log/pihole-FTL.log
   -----head of pihole-FTL.log------
   [2020-07-06 00:00:45.968 487] WARN: getOverTimeID(1593990300): 3192 is too large: 1592075100

You want to check that your time zone settings are correct:

timedatectl status

Use e.g. sudo raspi-config to adjust if necessary.
You could then try to force a time sync by running

systemctl restart systemd-timesyncd

If that doesn't work, set your time manually:

timedatectl set-time '2020-07-06 04:51:42'

Restart Pi-hole's DNS resolver after that:

pihole restartdns
3

Thank you for the reply, I checked and the timezone is correct on both Raspberry Pi's. The date and time is now correct also on both of them.

I restarted the DNS resolver on both but still having the same issue, it's still timing out when looking up dns queries.

Edit: I just checked the logs and it is showing that the date/time is out still, but if i type in timedatectl status the time, date and timezone are all correct.

Also iptables was installed on both of the Raspberry Pi's I have since uninstalled this, but no change.

New Logs
pi-dns-1: https://tricorder.pi-hole.net/4fw0qy9icp
pi-dns-2: https://tricorder.pi-hole.net/caz29i58b6

4

It's just messages in the log that are the same as before, see log timestamps.
You've successfully resolved time issues, as your recent checks show a correct time and date.

From a client in your network, what are the results of the following commands:

nslookup pi.hole

nslookup flurry.com 192.168.0.11

nslookup flurry.com 192.168.0.12
5

Thanks for your help with this. Here is the output from the commands.

nslookup pi.hole
Server:  pi-dns-1
Address:  192.168.0.11

Name:    pi.hole
Address:  192.168.0.11

nslookup flurry.com 192.168.0.11
Server:  pi-dns-1
Address:  192.168.0.11

Name:    flurry.com
Addresses:  ::
          0.0.0.0

nslookup flurry.com 192.168.0.12
Server:  pi-dns-2
Address:  192.168.0.12

Non-authoritative answer:
Name:    flurry.com
Addresses:  98.136.103.26
          74.6.136.153
          212.82.100.153
6

Things look ok for your pi-dns-1.

Your pi-dns-2 should also have answered with 0.0.0.0.

There are some irregularities in pi-dns-2's debug log:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve  via localhost (127.0.0.1)
[✗] Failed to resolve  via Pi-hole (192.168.0.12)

*** [ DIAGNOSING ]: Dashboard and block page
[✗] Block page X-Header: X-Header does not match or could not be retrieved.

You could try to reconfigure your second Pi-hole at 192.168.0.12 by running pihole -r and choose Reconfigure.

7

Oh well that's good to know atleast one of them is working correctly.

I tried to reconfigure pi-dns-2 (192.168.0.12) and run the command nslookup flurry.com 192.168.0.12 but I still get an IP Address from the server.

Since reconfiguring pi-dns-2 (192.168.0.12), the below now happens, but restarting the DNS resolver makes it return the IP address as above.

nslookup flurry.com 192.168.0.12
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.0.12

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

I temporarily unplugged the network cable from pi-dns-2 (192.168.0.12) but nslookups for retrogamingcables.co.uk still timeout.

Here are new logs

pi-dns-1: https://tricorder.pi-hole.net/gil0gk3fdi
pi-dns-2: https://tricorder.pi-hole.net/iwi4znmh04

8

Verify that your router hasn't reserved your .12 to another device.

And let's check your network configuration for conflicts.
On your pi-dns-2 machine, what's the output of:

grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf
9

My router hasn't reserved .12 to another device, all the other devices on my network have different addresses. the .12 address is also outside of the DHCP address range.

The output of grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf is as follows.

root@pi-dns-2:~# grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf
hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
interface eth0
arping 192.168.0.1
profile 192.168.0.1
static ip_address=192.168.0.12/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1

This is the same output but from pi-dns-1 (192.168.0.11).

root@pi-dns-1:~# grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf
hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
interface eth0
arping 192.168.0.1
profile 192.168.0.1
static ip_address=192.168.0.11/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1
10

Nothing in your confs that would explain why Pi-hole wouldn't receive a DNS request.

Let's check your ports and your machine's DNS resolver on your pi-dns-2 next:

sudo netstat -tulpn

cat /etc/resolv.conf
11

I know right, that's what's so confusing, although I hadn't checked everything your now checking as I didn't know of some of these commands.

I'll provide output from both the working pi and the non working one, the non working one first however.

sudo netstat -tulpn output from the non working pi-dns-2 (192.168.0.12)

root@pi-dns-2:~# sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      419/lighttpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      454/pihole-FTL
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      388/sshd
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      454/pihole-FTL
tcp6       0      0 :::80                   :::*                    LISTEN      419/lighttpd
tcp6       0      0 :::53                   :::*                    LISTEN      454/pihole-FTL
tcp6       0      0 :::22                   :::*                    LISTEN      388/sshd
tcp6       0      0 ::1:4711                :::*                    LISTEN      454/pihole-FTL
udp        0      0 0.0.0.0:37422           0.0.0.0:*                           268/avahi-daemon: r
udp        0      0 0.0.0.0:58674           0.0.0.0:*                           383/snmpd
udp        0      0 0.0.0.0:53              0.0.0.0:*                           454/pihole-FTL
udp        0      0 0.0.0.0:68              0.0.0.0:*                           345/dhcpcd
udp        0      0 192.168.0.12:123        0.0.0.0:*                           379/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           379/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           379/ntpd
udp        0      0 127.0.0.1:161           0.0.0.0:*                           383/snmpd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           268/avahi-daemon: r
udp6       0      0 :::53                   :::*                                454/pihole-FTL
udp6       0      0 :::59702                :::*                                268/avahi-daemon: r
udp6       0      0 fe80::b5fe:6ec5:6c5:123 :::*                                379/ntpd
udp6       0      0 ::1:123                 :::*                                379/ntpd
udp6       0      0 :::123                  :::*                                379/ntpd
udp6       0      0 :::5353                 :::*                                268/avahi-daemon: r

cat /etc/resolv.conf output from the non working pi-dns-2 (192.168.0.12)

root@pi-dns-2:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.1

sudo netstat -tulpn output from the working pi-dns-1 (192.168.0.11)

The output from the above has 1 more entry in it than the non working pi-dns-2, not sure if this is of any relevance.

root@pi-dns-1:~# sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      416/lighttpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      501/pihole-FTL
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      384/sshd
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      501/pihole-FTL
tcp6       0      0 :::80                   :::*                    LISTEN      416/lighttpd
tcp6       0      0 :::53                   :::*                    LISTEN      501/pihole-FTL
tcp6       0      0 :::22                   :::*                    LISTEN      384/sshd
tcp6       0      0 ::1:4711                :::*                    LISTEN      501/pihole-FTL
udp        0      0 0.0.0.0:53              0.0.0.0:*                           501/pihole-FTL
udp        0      0 0.0.0.0:68              0.0.0.0:*                           354/dhcpcd
udp        0      0 0.0.0.0:52045           0.0.0.0:*                           280/avahi-daemon: r
udp        0      0 192.168.0.11:123        0.0.0.0:*                           383/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           383/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           383/ntpd
udp        0      0 0.0.0.0:59785           0.0.0.0:*                           387/snmpd
udp        0      0 0.0.0.0:161             0.0.0.0:*                           387/snmpd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           280/avahi-daemon: r
udp6       0      0 :::53                   :::*                                501/pihole-FTL
udp6       0      0 :::49476                :::*                                280/avahi-daemon: r
udp6       0      0 fe80::eeba:6fbe:291:123 :::*                                383/ntpd
udp6       0      0 ::1:123                 :::*                                383/ntpd
udp6       0      0 :::123                  :::*                                383/ntpd
udp6       0      0 ::1:161                 :::*                                387/snmpd
udp6       0      0 :::5353                 :::*                                280/avahi-daemon: r

cat /etc/resolv.conf output from the working pi-dns-1 (192.168.0.11)

root@pi-dns-1:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.1
12

Those look ok as well, both of them.

Let's check if it's related to your upstream DNS servers somehow.

Run from your pi-dns-2 this time, what's the output of the following command:

dig www.thetimes.co.uk @84.200.69.80
13

This is the output from the pi-dns-2.

root@pi-dns-2:~# dig www.thetimes.co.uk @84.200.69.80

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> www.thetimes.co.uk @84.200.69.80
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27189
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.thetimes.co.uk.            IN      A

;; ANSWER SECTION:
www.thetimes.co.uk.     227     IN      CNAME   www.thetimes.co.uk.edgekey.net.
www.thetimes.co.uk.edgekey.net. 21527 IN CNAME  e2541.dsca.akamaiedge.net.
e2541.dsca.akamaiedge.net. 2    IN      A       2.21.140.185

;; Query time: 32 msec
;; SERVER: 84.200.69.80#53(84.200.69.80)
;; WHEN: Mon Jul 06 19:38:37 BST 2020
;; MSG SIZE  rcvd: 143

And this is the output from pi-dns-1

root@pi-dns-1:~# dig www.thetimes.co.uk @84.200.69.80

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> www.thetimes.co.uk @84.200.69.80
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57380
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.thetimes.co.uk.            IN      A

;; ANSWER SECTION:
www.thetimes.co.uk.     237     IN      CNAME   www.thetimes.co.uk.edgekey.net.
www.thetimes.co.uk.edgekey.net. 21537 IN CNAME  e2541.dsca.akamaiedge.net.
e2541.dsca.akamaiedge.net. 12   IN      A       2.21.140.185

;; Query time: 31 msec
;; SERVER: 84.200.69.80#53(84.200.69.80)
;; WHEN: Mon Jul 06 19:38:27 BST 2020
;; MSG SIZE  rcvd: 143
14

Let's specifically check a query for your offending domain through your pi-dns-2, your upstream and through Google's DNS:

dig retrogamingcables.co.uk @192.168.0.12

dig retrogamingcables.co.uk @84.200.69.80

dig retrogamingcables.co.uk @8.8.8.8
15

Ah finally some progress, the first command failed with no response, the next two commands worked fine.

Edit: Actually maybe not, the output below is from the non-working pi-dns-2, but running the commands on the working pi-dns-1, the output is the same.

root@pi-dns-2:~# dig retrogamingcables.co.uk @192.168.0.12

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> retrogamingcables.co.uk @192.168.0.12
;; global options: +cmd
;; connection timed out; no servers could be reached

root@pi-dns-2:~# dig retrogamingcables.co.uk @84.200.69.80

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> retrogamingcables.co.uk @84.200.69.80
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 225
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;retrogamingcables.co.uk.       IN      A

;; Query time: 32 msec
;; SERVER: 84.200.69.80#53(84.200.69.80)
;; WHEN: Mon Jul 06 19:53:00 BST 2020
;; MSG SIZE  rcvd: 52

root@pi-dns-2:~# dig retrogamingcables.co.uk @8.8.8.8

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> retrogamingcables.co.uk @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;retrogamingcables.co.uk.       IN      A

;; ANSWER SECTION:
retrogamingcables.co.uk. 3599   IN      A       213.230.222.4

;; Query time: 156 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jul 06 19:53:10 BST 2020
;; MSG SIZE  rcvd: 68

Output from pi-dns-1

root@pi-dns-1:~# dig retrogamingcables.co.uk @192.168.0.11

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> retrogamingcables.co.uk @192.168.0.11
;; global options: +cmd
;; connection timed out; no servers could be reached

root@pi-dns-1:~# dig retrogamingcables.co.uk @84.200.69.80

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> retrogamingcables.co.uk @84.200.69.80
;; global options: +cmd
;; connection timed out; no servers could be reached

root@pi-dns-1:~# dig retrogamingcables.co.uk @8.8.8.8

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> retrogamingcables.co.uk @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46534
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;retrogamingcables.co.uk.       IN      A

;; ANSWER SECTION:
retrogamingcables.co.uk. 3599   IN      A       213.230.222.4

;; Query time: 166 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jul 06 19:59:48 BST 2020
;; MSG SIZE  rcvd: 68
16

Only the last lookup succeeded - your @84.200.69.80 failed:

This is also the reason why your lookup through Pi-hole itself fails.

So nothing wrong with Pi-hole, but with your chosen upstream DNS:
84.200.69.80 trips over resolving retrogamingcables.co.uk.

Consider switching to another set of DNS servers, at least until DNS.Watch fixes this.
(It might also be enough to add an additional upstream DNS that is able to resolve the cables domain, though I wouldn't outright recommend it. It's probably ok as a general fallback, but that could lead to noticably longer resolution times when Pi-hole tries to resolve the domain through a different upstream.)

17

Oh you are right, I see that now.

I chose DNS.Watch just for the "No Censorship. No Logging" part, would you happen to have any recommendations for a suitable replacement?

Edit: I changed to Comodo just as a test, retrogamingcables.co.uk now resolves, but so does flurry.com but only on the pi-dns-2. Do I still have a problem with the pi-dns-2?

18

I don't think so.
We did use flurry.com as a test domain since its known to be blocked by Pi-hole (at least when using default blocklists). So only lookups through Pi-hole's IP should return 0.0.0.0.

A lookup through a public DNS server is likely to succeed, unless such a server would block flurry.com as well.

I wouldn't dismiss them altogether, there may be a reason why DNS.Watch do not resolve that domain (although I am not aware of one).

You'd have to search for public DNS servers yourself, as recommendations may vary wildly based on your preferences and your location.

Since you mention privacy as an important motivation:
Consider installing unbound alongside Pi-hole on your RPis and use that as Pi-hole's only upstream - that way, it is highly probable that no single DNS provider will ever see any of your requested domains in full again.

1 Like
19

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.