Websites load extremely slow when using Pi-hole

I have set up Pi-hole on my new Raspberry Pi 4B that is connected via 1Gbps LAN to my network. After some (seemingly random) time of use, the load times of websites increase significantly. In the development tools, I can see that requests are aborted with the error NS_BINDING_ABORTED. I cannot see anything in the Pi-hole logs. After rebooting, the issue is gone – until it comes back at some point. Using an external DNS resolver like 1.1.1.1 also fixes the issue, but obviously defeats the purpose.

Expected Behaviour:

Websites should still load as fast as before.

Actual Behaviour:

Websites' load time increases significantly, in some cases to > 10s (if the site makes lots of XHR requests or has lots of images).

Debug Token:

https://tricorder.pi-hole.net/dd3q2xxzbe

If this happens check the reply time in the query log of Pi-hole. Additionally, run nslookup pi.hole from the affected client.

Does it happen with all websites? On different browsers?

The query times seem to be in a normal range. A few examples:

105.1ms www.golem.de (IP)
203.4ms cdn.sroeerdigitalgroup.de (CNAME)
48.7ms cmp-cdn.golem.de (CNAME)
87.7ms ssl.gstatic.com (IP)
95.1ms s3.amazonaws.com (IP)

nslookup is fine too:

$ nslookup pi.hole
Server:		192.168.5.6
Address:	192.168.5.6#53

Name:	pi.hole
Address: 192.168.5.6

I think it happens with all websites and in all browsers I have tried (Firefox, Chrome, Safari). The more requests are needed to load the site, the more it is noticeable.

Here are two examples of timing analysis in Firefox:

Screen Shot 2021-03-16 at 19.52.16

That looks really strange.

From the pictures you posted I think this is a network issue and not a DNS issue (even though DNS resolution is listed as "2 sec"). I have no idea why "Blocked" is listed at all and why it does take so long.

To rule out DNS even more, have a look in /var/log/pihole.log and /var/log/pihole-FTL.log for suspicious messages during the times you experience the slowness.

1 Like

I know, I haven't seen anything like this before either.

It would seem like it – but I am fairly confident that it is not. I have a complete Ubiquiti system that has been working very reliably in the past. If I switch my client to 1.1.1.1 for DNS resolving when the issue is occurring, the problem is instantly gone, without any other changes.

However, I wasn't (yet) able to identify problems within those two log files.
Around the time I had slow loading times this morning, there are only these entries in the logs:

/var/log/pihole-FTL.log
[2021-03-18 08:42:53.831 929M] Resizing "FTL-strings" from 122880 to (126976 * 1) == 126976 (/dev/shm: 3.7MB used, 978.6MB total, FTL uses 3.7MB)
[2021-03-18 08:49:03.453 929M] Resizing "FTL-dns-cache" from 192512 to (12288 * 16) == 196608 (/dev/shm: 3.7MB used, 978.6MB total, FTL uses 3.7MB)
/var/log/pihole.log
Mar 18 08:49:03 dnsmasq[929]: reply speedtest.telemaxx.net.prod.hosts.ooklaserver.net is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply speedtest.telemaxx.net is 85.115.3.102
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 15264, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 7410, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 45580, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply pfalzkom.de is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply speedtest.pfalzkom.de is 213.183.69.197
Mar 18 08:49:03 dnsmasq[929]: reply mbn-glasfaser.de is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply sp1.mbn-glasfaser.de.prod.hosts.ooklaserver.net is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply sp1.mbn-glasfaser.de is 185.60.197.7
Mar 18 08:49:03 dnsmasq[929]: query[A] speedtest.ggew-net.de.prod.hosts.ooklaserver.net from 192.168.2.17
Mar 18 08:49:03 dnsmasq[929]: forwarded speedtest.ggew-net.de.prod.hosts.ooklaserver.net to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: dnssec-query[DS] twl-kom.de to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 15264, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 7410, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 45580, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply crafthost24.de is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply sp.crafthost24.de.prod.hosts.ooklaserver.net is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply sp.crafthost24.de is 157.90.225.31
Mar 18 08:49:03 dnsmasq[929]: reply starface.de is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply voiptest.starface.de.prod.hosts.ooklaserver.net is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply voiptest.starface.de is 37.120.180.41
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 15264, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 7410, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply de is DNSKEY keytag 45580, algo 8
Mar 18 08:49:03 dnsmasq[929]: reply bc-networks.de is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply speedtest1.bc-networks.de.prod.hosts.ooklaserver.net is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply speedtest1.bc-networks.de is 176.9.58.37
Mar 18 08:49:03 dnsmasq[929]: dnssec-query[DS] ggew-net.de to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: query[A] ocsp2.globalsign.com from 192.168.2.17
Mar 18 08:49:03 dnsmasq[929]: forwarded ocsp2.globalsign.com to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: reply twl-kom.de is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply speedtest.twl-kom.de is 217.151.151.210
Mar 18 08:49:03 dnsmasq[929]: query[A] r3.o.lencr.org from 192.168.2.17
Mar 18 08:49:03 dnsmasq[929]: forwarded r3.o.lencr.org to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: query[A] ocsp.starfieldtech.com from 192.168.2.17
Mar 18 08:49:03 dnsmasq[929]: forwarded ocsp.starfieldtech.com to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: dnssec-query[DS] globalsign.com to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: reply ggew-net.de is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply speedtest.ggew-net.de.prod.hosts.ooklaserver.net is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply speedtest.ggew-net.de is 217.113.177.17
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply r3.o.lencr.org is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply o.lencr.edgesuite.net is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply a1887.dscq.akamai.net is 95.100.86.217
Mar 18 08:49:03 dnsmasq[929]: reply a1887.dscq.akamai.net is 95.100.86.207
Mar 18 08:49:03 dnsmasq[929]: reply globalsign.com is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply ocsp2.globalsign.com is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply global.prd.cdn.globalsign.com is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply cdn.globalsigncdn.com.cdn.cloudflare.net is 104.18.20.226
Mar 18 08:49:03 dnsmasq[929]: reply cdn.globalsigncdn.com.cdn.cloudflare.net is 104.18.21.226
Mar 18 08:49:03 dnsmasq[929]: dnssec-query[DS] starfieldtech.com to 127.0.0.1
Mar 18 08:49:03 dnsmasq[929]: reply starfieldtech.com is no DS
Mar 18 08:49:03 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:03 dnsmasq[929]: reply ocsp.starfieldtech.com is <CNAME>
Mar 18 08:49:03 dnsmasq[929]: reply ocsp.godaddy.com.akadns.net is 192.124.249.23
Mar 18 08:49:03 dnsmasq[929]: reply ocsp.godaddy.com.akadns.net is 192.124.249.36
Mar 18 08:49:03 dnsmasq[929]: reply ocsp.godaddy.com.akadns.net is 192.124.249.22
Mar 18 08:49:03 dnsmasq[929]: reply ocsp.godaddy.com.akadns.net is 192.124.249.41
Mar 18 08:49:03 dnsmasq[929]: reply ocsp.godaddy.com.akadns.net is 192.124.249.24
Mar 18 08:49:03 dnsmasq[929]: query[A] ocsp.sectigo.com from 192.168.2.17
Mar 18 08:49:03 dnsmasq[929]: forwarded ocsp.sectigo.com to 127.0.0.1
Mar 18 08:49:04 dnsmasq[929]: dnssec-query[DS] sectigo.com to 127.0.0.1
Mar 18 08:49:04 dnsmasq[929]: reply sectigo.com is no DS
Mar 18 08:49:04 dnsmasq[929]: validation result is INSECURE
Mar 18 08:49:04 dnsmasq[929]: reply ocsp.sectigo.com is 151.139.128.14
Mar 18 08:49:04 dnsmasq[929]: query[A] admin.microsoft.com from 192.168.2.17
Mar 18 08:49:04 dnsmasq[929]: forwarded admin.microsoft.com to 127.0.0.1
Mar 18 08:49:04 dnsmasq[929]: query[A] prod.msocdn.com from 192.168.2.17
Mar 18 08:49:04 dnsmasq[929]: forwarded prod.msocdn.com to 127.0.0.1
Mar 18 08:49:04 dnsmasq[929]: query[A] spoprod-a.akamaihd.net from 192.168.2.17
Mar 18 08:49:04 dnsmasq[929]: forwarded spoprod-a.akamaihd.net to 127.0.0.1
Mar 18 08:49:04 dnsmasq[929]: dnssec-query[DS] office.com to 127.0.0.1
Mar 18 08:49:04 dnsmasq[929]: dnssec-query[DS] akamaihd.net to 127.0.0.1
Mar 18 08:49:04 dnsmasq[929]: validation result is INSECURE

Could it be possible that DNSSEC validation (for some reason) gets very slow and thus slows down the whole request? I'll test this theory by disabling DNSSEC validation for now.

Edit: Disabling DNSSEC didn't bring any relief. Interestingly, I think this issue also appears on BigBlueButton video calls at my university – those lag sometimes when I have set my Pihole as the client's DNS server. If I switch the DNS server to 1.1.1.1, the lags are gone as well.

A post was split to a new topic: Internet is slow using Pi-hole

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