Running pihole -d for debug/diagnosing reports the following errors:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
dig: '' is not a legal name (unexpected end of input)
[✗] Failed to resolve via localhost (127.0.0.1)
dig: '' is not a legal name (unexpected end of input)
[✗] Failed to resolve via Pi-hole (192.168.1.101)
[✓] doubleclick.com is 172.217.22.110 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Pi-hole processes
[✗] dnsmasq daemon is inactive
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active
With V4.0 of Pi-Hole, dnsmasq code is embedded into pihole-FTL and dnsmasq does not run. The debug log will show dnsmasq as inactive or failed. The developers are looking at changing that section of the debug log in a future release.
Not related to your original question, but your debug shows no domains in gravity - this is driving the errors for failure to resolve. What is the output of:
So, first things first: the output of pihole -d is only reporting dnsmasq daemon is inactive:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] counter28.bravenet.com is 0.0.0.0 via localhost (127.0.0.1)
[✓] counter28.bravenet.com is 0.0.0.0 via Pi-hole (192.168.1.101)
[✓] doubleclick.com is 172.217.22.110 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Pi-hole processes
[✗] dnsmasq daemon is inactive
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active
I don't see any errors with that output. The dnsmasq component is not necessary anymore (it was moved to FTL), but the check for it wasn't removed from the debugger. You can check the dnsmasq logs for errors by looking in /var/log/pihole.log, and any options passed after the -- parameter in pihole-FTL -- will be passed to dnsmasq (but this is not recommended, since FTL runs automatically).