How did you configure your router's IPv6 DNS settings?
Do you have any logs (thinking about the files pihole.log and FTL.log in /var/log/pihole) you could show us when there are these sluggishness issues? From your debug log everything seems to have worked just fine at the time you generated that.
You could upload them securely using something like
tail -n 250 /var/log/pihole/FTL.log | pihole tricorder
tail -n 250 /var/log/pihole/pihole.log | pihole tricorder
If upload doesn't work at these times, you could copy them elsewhere before and upload after a restart.
chrislph: Not really. Only SAMBA is running but only in use when I scan documents.
jfb: Done. 
Bucking_Horn: The same like IPv4. Routed DNS traffic for LAN and WAN to my Pihole.
DL6ER: Sure. Here you go:
FTL.log: https://tricorder.pi-hole.net/gRcd64eD/
pihole.log: https://tricorder.pi-hole.net/Sfyjjnrt/
What type of IPv6 address are you using for your router's IPv6 DNS configuration:
Public GUA (range 2000::/3), ULA (range fd00::/8) or link-local (fe80::/10)?
In the router's DNS it's 2a02:810d:b63f:fdc8:72c3:243d:e38:93e0 for the Pihole and in the Pihole there is no custom IPv6 DNS set. Here a screenshot of the config:
These are the IP's of my router:
johannes@johannes:~$ nslookup fritz.box -6
*** Invalid option: 6
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: fritz.box
Address: 192.168.178.1
Name: fritz.box
Address: fd00::464e:6dff:fe7f:2341
Name: fritz.box
Address: 2a02:810d:b63f:fdc8:464e:6dff:fe7f:2341
You should avoid using a GUA address:
It's not stable, as its prefix is subject to change at the discretion of your ISP.
As the prefix changes, clients wouldn't be able to reach Pi-hole via its deprecated GUA anymore. Dual-stack clients will fall back to IPv4 after a while, which may contribute to your observation.
Use one of your Pi-hole's ULAs or link-locals instead.
You may also want to consider to prevent your router from propagating an IPv6 DNS server address as local DNS server to its clients altogether - provided your router supports it.
The FritzBox line-up should do so, see e.g. Unresolved ipv6 adress in my top list - #4 by Bucking_Horn.
All right, thank you! I hope that will do the trick.
But... when I set now fe80::b4ab:c4d0:9c7f:72db as DNSv6 for internet does it work anyway? I have a dual stack xDSL connection I don't want to use my ISP's DNS.
I only have to options here. Either to use a custom DNS or use the ISP's one.
Yes, as long as your Pi-hole host machine is on the same link as your FB.
In home networks, that's usually the case.
More complex networks with additional routers or L3 switches may split your networks into multiple links/segment, in which case you should use ULAs.
But as you are showing the upstream DNS settings of your FB, and I can tell from your debug log that you've enabled Pi-holes Conditional Forwarding:
Note that by pointing your router to use Pi-hole as its upstream DNS server, you are closing a partial DNS loop. In particular, requests from your guest networks for unknown domains.as well as reverse lookups for similar IPs would loop.
This may also contribute towards your observation of sporadic slowdowns, primarily for clients in your guest network, but could also affect your home network due to the sudden surge in your DNS traffic during loops.
Pi-hole's diagnostics would usually raise some rate limit or DNS max concurrency warnings in that case, but those were absent from your debug log. EDIT: As those are flushed by a restart, this doesn't mean they never occurred. If you observe slowdowns again, you may want to take a look at Tools | Pi-hole diagnosis before restarting Pi-hole.
If you could live with your guest network being unfiltered (spares you from some legal considerations as well), you could simply enter some public DNS resolvers of your choice into your FritzBox's DNS servers at Internet | Zugangsdaten | DNS-Server.
Your home network is taken care of by distributing your Pi-hole's IPv4 via DHCP.
1 Like
Ah okay, thank you!
Do you maybe have a how-to for me to config PI-Hole and FritzBox properly? My intent simply is to avoid using my ISP's DNS and use Pi-Hole as an Ad-Blocker.
It would depend on individual network's features as well as on personal preferences what you'd consider proper, so there can be no definite answer here.
You may refer to Pi-hole's FritzBox guide (available in Deutsch as well) for suggestions that also try to highlight potential drawbacks and benefits of available options.
But ultimately, it's your choice what combination of settings you'd end up to be happy with. 
1 Like
Do you have any domains in this time interval that were problematic? I checked through your log lines and everything seems to have worked fine. Every query immediately received a reply either from an upstream server or from cache. I have not been able to identify a single query that did not receive a reply respectively had a delay of one second or even more.
edit
But I see you specified eight (!) upstream DNS servers. As you might know, Pi-hole tries to pick the fastest upstream every now and then. If this choice happens to be a server that replies fast but maybe not to all queries or which doesn't respond every now and then, then this perfectly explains what you are observing: The "fastest" DNS server is re-picked after a restart so the unreliable server is gone until it might eventually be selected again. Reducing the number of upstream servers is very likely to resolve this issue easily.
1 Like
Not that I know of. But I really had some some of this loops that Bucking_Horn mentioned above in the past. Then I fiddled a bit around and it was gone. Don't know anymore what I've done.
Hmm, yes. I had also checked Cloudflare as spare DNS. But when you say it's contra-productive I remove Cloudflare and let only DNS.WATCH checked.
Okay, now I got such a DNSMASQ_WARN again (Maximum number of concurrent DNS queries reached (max: 150)). Here's the log: https://tricorder.pi-hole.net/eqGmBuMS/
So I think I have to redo my FritzBox and Pi-Hole config.
Let's take a look where those excessive requests come from.
Run from your Pi-hole host machine, what's the output of:
pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db \
"SELECT client, count(domain) FROM queries \
WHERE timestamp BETWEEN strftime('%s','2023-03-02 03:14:40+01:00') AND strftime('%s','2023-03-02 03:14:43+01:00') \
GROUP by client ORDER BY count(domain) DESC LIMIT 10;"
The output is:
192.168.178.1|131
2a02:810d:b63f:fdc8:72c3:243d:e38:93e0|87
192.168.178.23|58
192.168.178.21|52
192.168.178.28|32
2a02:810d:b63f:fdc8:6531:3642:376d:73a9|30
192.168.178.64|29
192.168.178.34|14
192.168.178.30|14
fe80::464e:6dff:fe7f:2341|10
- 192.168.178.1 is the Router
- 2a02:810d:b63f:fdc8:72c3:243d:e38:93e0 is the Pi-Hole
- 192.168.178.23 is my Android Tablet
- 192.168.178.21 could be the Vodafone GigaTV 2 Cable Receiver
- 192.168.178.28 is my OctoPi #2
- 2a02:810d:b63f:fdc8:6531:3642:376d:73a9 is unkown and now unreachable
- 192.168.178.64 is my homeassistant
- 192.168.178.34 is my Android Smartphone
- 192.168.178.30 is my OctoPi #1
- fe80::464e:6dff:fe7f:2341 might be the Gateway?
Edit:
And I also followed now the instructions of the Pi-hole's FritzBox guide and I hope it's now all correctly configed. https://tricorder.pi-hole.net/NEa7FeOm/
I also did the IPv6 DNS section and set a ULA and set it in the FritzBox DNS-Section.
Those domain counts are too low - that output doesn't cover the timeframe when the 'maximum concurrent' warning was logged.
That's quite likely my fault, of course - I forgot to have you adjust the SQL statement for your local time zone.
Assuming your Pi-hole host machine is configured for a timezone matching UTC +01:00 (e.g. WAT or CET), please run the following statement:
pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db \
"SELECT client, count(domain) FROM queries \
WHERE timestamp BETWEEN strftime('%s','2023-03-02 03:14:40+01:00') AND strftime('%s','2023-03-02 03:14:43+01:00') \
GROUP by client ORDER BY count(domain) DESC LIMIT 10;"
If your timezone differs from UTC+01:00, please substitute both(!) of +01:00 literals trailing the two datetimes in the above statement.
No problem. But I think it's useless now because I rebooted the Pi.
192.168.178.32|8
192.168.178.24|8
192.168.178.64|4
fe80::464e:6dff:fe7f:2341|3
192.168.178.1|3
192.168.178.21|1
Those are even fewer. 
Your debug log shows the warning as follows:
*** [ DIAGNOSING ]: Pi-hole diagnosis messages
count last timestamp type message
----- ------------------- -------------------- ------------------------------------------------------------
1 2023-03-02 03:14:42 DNSMASQ_WARN Maximum number of concurrent DNS queries reached (max: 150)
Are you sure you applied the correct time modifier?
You may check your timezone via timedatectl.
That shouldn't matter. The SQL statement is searching the long-time database.
Well, this does not necessarily have to come from an excessive amount of queries in a short time but can also mean you are not receiving m/any replies. Guess you send two queries per second but never receive answers from upstream. This would make 150 concurrent (as in actively waiting for a reply at the same time) in litte more than one minute.
This somewhat matches the overall title of this topic. You seem to have either reliably picked now those servers that are unreliable or there are other things in your network that are causing (partial?) network failures. While normal Internet traffic (using the TCP protocol) can easily be re-requested when packets get lost in transit, the DNS protocol (utilizing UDP) cannot do this causing you to be affected by intermittent Internet access much stronger.
Now it should be correct.
192.168.178.32|1429
192.168.178.24|1058
192.168.178.21|1045
192.168.178.64|982
192.168.178.1|586
fe80::464e:6dff:fe7f:2341|564
192.168.178.26|242
192.168.178.22|120
192.168.178.23|82
2a02:810d:b63f:fdc8:6531:3642:376d:73a9|70
Edit:
Interesting... 32 is my TP-Link C200 IP-Cam, 24 my TP-Link LB130 Smart Light Bulb and 21 the Vodafone GigaTV2 Box. 64 is my homeassistant.