Updated DietPi and Pihole; now high CPU usage and lost connection

[Scintillation]

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

I am running Pihole on DietPi. Prior to yesterday, it was working fine. However, I updated Dietpi using sudo apt-get update && sudo apt-get upgrade, due to the sudo bug that was recently mentioned.

Since then, my pihole has been unstable. Htop does not show the reason for the huge spike in CPU usage. I believe it has something to do with a loop happening between the router (latest DDWRT) and the Pihole.

Expected Behaviour:

Pihole functioning normally. No loop between router and pihole.
No ".verizon.net" after hostname for devices.

Actual Behaviour:

The CPU usage of Pihole is spiking to 100%. High number of requests relating to "wpad.verizon.net" and "_ldap._tcp.dc._msdcs.verizon.net" . I have blacklisted "wpad.verizon.net" but the problem has not been resolved.

Also, I am not sure why the client names have ".verizon.net" after them. In DDWRT I do not specify a hostname. I am setting the DNS server to be 192.168.1.128, the static IP for DietPi device. I do not have "forced DNS redirection" under DNSmasq settings.

I also have this setting for DNSmasq: dhcp-option=6,192.168.1.128

I am not sure what is causing this high number of requests, and the loop between the router and the Pi.
Prior to yesterday, this did not happen. Upon changing the router DNS to 1.1.1.1, the CPU usage drops back to 0% and the web interface then loads again.

Debug Token:

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

[DL6ER]

Looking at your debug token, this seems to come from conditional forwarding. You set up

    REV_SERVER=true
    REV_SERVER_CIDR=192.168.1.100/24
    REV_SERVER_TARGET=192.168.1.1
    REV_SERVER_DOMAIN=verizon.net

so when DDWRT (on 192.168.1.1) uses the Pi-hole as well as upstream destination, an (at least partial) loop may be happening here. This will surely be the reason for the .verizon.net top-level domains.

Even when my own DDWRT experience is some maybe five years old, something seems to be odd with your router. As DHCP server it should consider itself the authorative name server for the network and reply to all the requests instead of looping around.

We have a proposed fix for this looping killing the dashboard, but it is, of course, only a symptomatic fix:
https://github.com/pi-hole/FTL/pull/1052

My suggestions at this point:

1. Change the verizon.net in your Conditional Forwarding settings to the domain of your local network.
2. Back when I used DDWRT, there was a setting like Use dnsmasq for DHCP. If that still exists, you may want to try it.
3. Tell the DDWRT router that .verizon.net (or to whatever you changed it) is your local domain and it should not be forwarding back (= looping) in this case.

If you sticl with this TLD, "real" verizon.net domains may not resolve on your network. As to why this was triggered by the update: I don't know. My best assumption is that the misconfiguration had been there before (maybe old tests/tries a longer time ago) and the update just somehow applied them.