Slow DNS resolution

Help
1

Expected Behaviour:

[I have a Raspberry Pi 3B+ running Raspbian GNU/Linux 11 (bullseye). I'm running FTL v5.24 and am using Google as my Pi-Hole's upstream DNS server. DNSSEC is disabled. Conditional Forwarding is disabled. I currently have my settings as "Show everything and record everything," but have tried "hide domains and clients" before with the same results. ]

Actual Behaviour:

[DNS resolution is taking an extensive amount of time on devices using Pi-Hole for DNS resolution. ]

Debug Token:

[https://tricorder.pi-hole.net/Es5ll3ma/]

I'm thinking it might be hardware-related, but not sure how to test that on a Raspberry Pi.

Any help is appreciated. Thanks!

1 Like
2

What's the result of:

dig flurry.com @192.168.4.96

dig dns.google @192.168.4.96
3 
─$ dig flurry.com @192.168.4.96
;; communications error to 192.168.4.96#53: timed out

; <<>> DiG 9.19.19-1-Debian <<>> flurry.com @192.168.4.96
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29231
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
flurry.com.             2       IN      A       0.0.0.0

;; Query time: 2620 msec
;; SERVER: 192.168.4.96#53(192.168.4.96) (UDP)
;; WHEN: Mon Feb 19 11:10:20 EST 2024
;; MSG SIZE  rcvd: 55

________________________________________________

─$ dig dns.google @192.168.4.96

; <<>> DiG 9.19.19-1-Debian <<>> dns.google @192.168.4.96
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62742
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dns.google.                    IN      A

;; ANSWER SECTION:
dns.google.             598     IN      A       8.8.4.4
dns.google.             598     IN      A       8.8.8.8

;; Query time: 39 msec
;; SERVER: 192.168.4.96#53(192.168.4.96) (UDP)
;; WHEN: Mon Feb 19 11:10:33 EST 2024
;; MSG SIZE  rcvd: 71
4

From your debug log, I've noticed that your router's DHCP server is distributing public DNS servers instead of Pi-hole. I assume that is by intention?

Your debug log shows that your Pi-hole is configured for eth0 network interface, but the machine hosting Pi-hole uses enxb827ebe91a77 instead.

You should run pihole -r with Reconfigure to change that.

This may have contributed to your dig results, but if it had done so, I'd have expected both lookups to have returned higher reply times than usual.

Instead, the unfiltered lookup for a public domain does return in 39 msecs (which looks normal), while the blocked one does so in 2,620msecs, and only after a prior timeout.

While Pi-hole has to wait for upstream servers to return a reply for forwarded queries, Pi-hole returns blocked results immediately, commonly in under 10 msecs.

The timeout could suggest that something is interfering with blocked results only.

What machine did you run those digs from?

Your debug log also shows an excessive load warning on your Pi-hole machine:

*** [ DIAGNOSING ]: Pi-hole diagnosis messages
  count   last timestamp       type               message
  ------  -------------------  -----------------  --------------
  1       2024-01-30 20:45:22  LOAD               excessive load

This may have contributed to your observation, but peak loads are typically only temporary, e.g. during os updates, and Pi-hole is unlikely to cause them.

Do you run any additional software on your machine hosting Pi-hole that could cause permanent CPU loads?

5

That's interesting. I didn't notice that. It appears I do not have an eth0 interface.

siberianreacher@JarvisII:~ $ ifconfig -a
enxb827ebe91a77: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.4.96  netmask 255.255.252.0  broadcast 192.168.7.255
        inet6 fe80::8b6b:6191:1812:84a8  prefixlen 64  scopeid 0x20<link>
        inet6 fdaa:8e8e:c8ca:1:6ba9:41d5:cfc9:5322  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:e9:1a:77  txqueuelen 1000  (Ethernet)
        RX packets 8538015  bytes 1477287994 (1.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 858874  bytes 106558986 (101.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 280857  bytes 18318008 (17.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 280857  bytes 18318008 (17.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:bc:4f:22  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I'll try to run a pihole -r to see if that fixes any issues. I have tried it before, however, with no improvement.

To your question about my router distributing public DNS servers, I had set the router to Cloudflare's DNS servers and forgot to switch it back. But even when I do have it set to use Pi-hole, I still have these issues.

The machine I ran the digs from is a Windows machine that I have running subsystem for Linux. Should I have run the digs from the Pi-hole itself?

I have noticed that excessive load error before on the GUI interface, but I am not sure what is causing it. The error seems to occur when the cores are over 4.

I don't have anything other than Pi-hole running on the Raspberry Pi. I have SSH enabled to access it from other devices in my house, but that's about it for services. Nothing that I'm aware of should be causing high CPU usage. This is why I was wondering if the issue could be hardware-related. Do you know of any hardware problems with the Raspberry Pi 3B+? And is there a way to test for them?

6

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