Pihole v5 Upgrade - Slow response?

Help
1

Hey everyone! I've been running into some issues with DNS response times after upgrading my PiHole to v5. I currently have my router pointed to the PiHole, and the PiHole is using 1.1.1.1 (+ https) for its upstream DNS. I've already tried switching the upstream DNS to Google's and just Cloudfare's (without https) on the PiHole, and I still run into the same issues. Cached websites load very quickly, but uncached websites take a good 5-10 seconds to resolve. When I point my router to 1.1.1.1 (as well as 8.8.8.8) directly, all requests load very quickly. Could someone help me figure what's going on?

Here is my Debug Token: https://tricorder.pi-hole.net/4jb602s9fs

Thanks!

2

You are currently configured to use Cloudflared as your upstream DNS resolver. Let's run a few queries through that resolver and Pi-hole. From the Pi terminal, what is the output of the following.

time dig bild.de @127.0.0.1

time dig bild.de @1.1.1.1

1 Like
3

Thanks for the quick response!
Here's the output from the first command:

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> bild.de @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49289
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
bild.de.                12      IN      A       145.243.248.20
bild.de.                12      IN      A       145.243.240.20

;; Query time: 189 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 17 08:57:22 EDT 2020
;; MSG SIZE  rcvd: 82


real    0m0.268s
user    0m0.055s
sys     0m0.024s

Here's the output from the second:

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> bild.de @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8354
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
bild.de.                1400    IN      A       145.243.248.20
bild.de.                1400    IN      A       145.243.240.20

;; Query time: 3 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Aug 17 08:58:46 EDT 2020
;; MSG SIZE  rcvd: 75


real    0m0.080s
user    0m0.043s
sys     0m0.034s
4

Both are quite fast. The problem may lie in some element of a page that is being blocked. Use these tools to determine what is being blocked that may cause a problem.

5

Would this apply even if I was just the default blocklist that PiHole provides? I just have a little hard time believing that this would affect browsing Youtube and Google searches. I can see it affecting smaller websites with obscure ad domains, but I am having a little trouble believing that this is affecting the bigger, well known domains.

6

You do have a number of added regex, some of which are redundant.

7

Hmm... I had added those redundant domains because one of the adlists for some reason wasn't working correctly. I've removed those domains to see if that will help.

Are you also able to determine why one of my added adlists don't work correctly? Is there an issue with the way I've set it up?

Btw, just want to extend my thanks again for helping me through this, definitely really helpful!

I've generated a new token just in case my changes are not reflected live: https://tricorder.pi-hole.net/ivipezmma8

8

A few thoughts from your new debug log. This blocklist is only partially compatible with Pi-hole. The first section is single domains, which is OK. The last two lines are regex, and these cannot be imported into the Pi-hole gravity list. In this case, they are skipped, but be careful when you select lists - this may not always be the case.

https://raw.githubusercontent.com/d43m0nhLInt3r/socialblocklists/master/TikTok/tiktokblocklist.txt

# ===============================================================

(^|\.)muscdn\.com$
(^|\.)musical\.ly$

This blocklists has a number of problems and I would not use it. I see you have it disabled. The problem with these lists is that they can cause a lot of false positives.

[i] Target: https://raw.githubusercontent.com/CamelCase11/UnifiedHosts/master/hosts.all
  [✓] Status: Retrieval successful
  [i] Received 1557939 domains, 29554 domains invalid!
      Sample of invalid domains:
      - 001linker.net;1
      - 0104joe.com;1
      - 01cas.info;1
      - 02troy84.net;1
      - 0d1dnfu-x5esmlc-m6u1x2.com;1

Now to the regex - all of yours appear to have problems.

(\.|^)http://192\.168\.1\.50/$
(\.|^)https://1337x\.to/$

First, https: is never part of a domain name, it is part of a URL and precedes the domain name. Second, blocking an IP address has no effect in Pi-hole. If the client already has the IP, it won't need to resolve anything and it will just use the IP to load the page.

Run your regex through regex101.com and check the syntax. Both of these examples fail.

The best way to create a regex to wildcard block a domain (which will block the domain and all subdomains) is to enter the plain domain as a wildcard, and let Pi-hole convert it to regex. An example would be adding 1227x.to as a wildcard, and Pi-hole will create the regex (\.|^)1227x\.to$

9

Okay, I appreciate the insights. I've completely removed the bad blocklist (I had also determined that it gave a lot of false positives, which is why it was disabled) and I have gotten rid of pretty much all of my regex edits. I went ahead and added the two regex mentions that are skipped from the adlist. I have regenerated my debug log and here is the new token: https://tricorder.pi-hole.net/4yaroa0ywi

If you don't find anything else out of the ordinary, then I suspect that the PiHole could possibly not be the issue and its probably an issue with my ISP itself or router config. I recognize that this is now probably bleeding into non-PiHole territory, but do you happen to know of any other way I could go about troubleshooting and pinpointing what the issue is?

10

I can't view the tricorder logs but I had a similar issue when upgrading to v5. First visit to some sites would have very long initial page load, after it would be fine. I didn't dig deep enough to see why this worked but disabling IPv6 resolved the issue for me. Give it a shot if you don't require IPv6 support.

11

Did you disable IPv6 on the PiHole or the client? I just took a quick glance on the PiHole settings and I couldn't find anything relating to disabling IPv6

12

I use docker and set the env variable IPv6: false, I think it corresponds to the setting on Settings -> DHCP -> Advanced DHCP settings -> Enable IPv6 support

13

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