Slow DNS Resolution from PiHole every 5 minutes

[walterpwnz]

Hello,

After a series of brownouts and power outages, my Raspberry Pi with Pi-hole and Unbound has been experiencing slow DNS resolution on a 5 minute interval. See below for what my Internet Connection Dashboard shows and please note this does surface when I'm browsing whenever one of the spikes happen. I've also noticed that additional sustained durations happen whenever more requests than usual are being sent to the Raspberry PI.

I've tried several things to try and resolve the issue

• Completely rebooting my modem, router and raspberry pi multiples times, but the issue persists.
• Changed my upstream DNS server from Unbound to Google, Cloudflare and OpenDNS.
• Tried only using IPv4 DNS servers for the above 3 external providers.
• Noticed an error message regarding "Maximum Number of Concurrent DNS queries reached", double checked my router config and tested this fix. Ended up removing that config after it didn't resolve the issue I was seeing

Thanks in advance, I'm completely stumped on why this is happening. Not sure what else to try and I'd greatly appreciate assistance. Please let me know if there's any more information I can provide.

Expected Behaviour:

DNS Resolution has consistent behavior, like it did before the power outages.
-operating system: DietPi v9.7.1
-hardware: RPi 4 Model B

Actual Behaviour:

Extremely slow DNS resolution every 5 minutes.

Debug Token:

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

[walterpwnz]

I've also now tried a potential solution mentioned here

Unbound intermittenly fails to resolve anything

With a validating recursive resolver, it would be expected that lookups take longer on average than with a caching DNS server. This is obviously for two reasons: Recursion itself takes longer, as it involves communicating with multiple authoritative DNS servers, and DNSSEC validation comes on top of that. Of course, unbound would cache DNS replies for as long as a domain's TTL allows, serving cached reply records almost instantaneously. Sporadic long resolution times may (re)occur when a cach…

That doesn't seem to have made a difference as well, unfortunately.

Additionally, I've noticed something interesting in the Query Logs for Pi-hole, before there were requests coming from the Docker container running the "ping" to google, apple, and GitHub under localhost (which was expected). Now I no longer see those requests from localhost, starting around the time the power outage took out my network.

Finally, I ran an nslookup within my raspberry pi

nslookup google.com
Server:		::1
Address:	::1#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.68.110
Name:	google.com
Address: 2607:f8b0:4007:813::200e

And noticed that it's returning an IPv6 address instead of an IPv4 for the DNS server. I think this may be the issue, since Docker doesn't support IPv4. What's confusing me is why this has major impact on the overall performance of the Pihole + Unbound.

[smokingwheels]

Is your DNS Cache Evictions 0?

[Bucking_Horn]

Your debug looks normal, but your machine running Pi-hole is not aware of a DNS server - its /etc/resolv.conf is reported as empty.
If you check that now, is that currently still the case?

What is generating that spiked graph screenshot?
Obviously, it isn't a Pi-hole one, and it shows HTTP request durations, not DNS resolution times.

If you suspect DNS to be involved, would correlating Pi-hole's Query Log output with the peaks of your HTTP duration show any peculiarities, like a sudden spike of DNS requests or unusually slow response times?

In particular, would "Maximum Number of Concurrent DNS queries reached" occur at those HTTP peak, or was that just a one time occurrence after your power outage?

RPis don't come with a battery backed RTC, so they lose time information on powerdowns, requiring to sync time with an NTP time server on successive reboot.

At the same time, DNSSEC validation requires accurate time information, or all validations of DNS requests will fail - including the DNS requests for an NTP time server domain, potentially even preventing your RPi to sync time.

Also, after a powerdown, unbound would have to walk the full recursion for any requests, which makes responses take a bit longer, until both unbound and Pi-hole have populated their caches.

While this may have caused issues directly after your recent outages, I don't see how that would trigger a five minute peak of HTTP requests, specifically if that observation persists after switching Pi-hole to public upstreams.

@walterpwnz

nslookup google.com
Server:		::1
Address:	::1#53

::1 is the IPv6 localhost address.
Since that nslookup was run on your RPi hosting Pi-hole, that DNS request should have been registered and processed by your Pi-hole.
If you see the corresponding queries in Pi-hole's Query Log, then there's nothing to worry about.

@walterpwnz

And noticed that it's returning an IPv6 address instead of an IPv4 for the DNS server. I think this may be the issue, since Docker doesn't support IPv4.

On the contrary, Docker is IPv4 only by default.

But how do you expect Docker to be involved here at all?

Your debug log shows that you are running both your Pi-hole as well as unbound directly on DietPi.

Do you run another DNS server as a Docker container?