Pihole DNS Not Working After Restart of Pi and Router

The issue I am facing:
I accidentally power cycled my router and my pihole at the same time and now I'm not getting DNS on my wifi network afterwards. They were working perfectly fine before, and oddly, my computer that's connected by ethernet seems to be still getting DNS. I also can't access the pihole web interface (pi.hole/admin doesn't work and neither does the ip address itself in my browser) on any devices, including my computer hooked up by ethernet. I can still SSH into my pi and run the debug flag and got the following token:

Details about my system:
Apologies because I set all this up over a year ago, then started having this issue as I was unplugging/replugging things getting ready for a move. Accidentally power cycled these guys and nothing has worked since. I'm now in a new house and set everything up again, and still having same problem. It's an ubiquiti router and raspberry pi 4 running ubuntu 20.04 LTS. I followed the pihole instructions on installing pihole alongside openvpn.

What I have changed since installing Pi-hole:
Changed nothing since I first got it up and running. The only deviations I made from a regular install was to install it alongside openVPN and get my router setup such that all devices on my network should've been using the pihole for DNS. Sorry everyone, I feel like this is a pretty nooby/generic post but I don't fully remember everything I modified on the ubiquiti system and pihole to get things just right when I first set it up. No idea why power cycling would have changed anything. They were hooked up to a UPS though so despite power outages to my old house occurring in the past year, it might be true that this is the first time they ever lost power since I first did the initial setup.

Your debug log shows your Pi-hole to be fully operational with full IPv4 and link-local IPv6 connectivity, receiving, filtering and forwarding queries:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] datacar40.net.daraz.com is on lo (
[✓] datacar40.net.daraz.com is on eth0 (
[✓] datacar40.net.daraz.com is on tun0 (
[✓] doubleclick.com is via a remote, public DNS server (

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] vaf.gaznf.xyz is :: on lo (::1)
[✓] vaf.gaznf.xyz is :: on eth0 (fe80::<redacted>33)
[✓] vaf.gaznf.xyz is :: on tun0 (fe80::<redacted>99)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
*** [ DIAGNOSING ]: contents of /var/log
-rw-r--r-- 1 pihole pihole 16K Jul 29 17:29 /var/log/pihole-FTL.log
   -----tail of pihole-FTL.log------
   [2022-07-23 02:10:14.363 1918M] Imported 34143 queries from the long-term database
   [2022-07-23 02:10:14.364 1918M]  -> Total DNS queries: 34143
   [2022-07-23 02:10:14.364 1918M]  -> Cached DNS queries: 6320
   [2022-07-23 02:10:14.364 1918M]  -> Forwarded DNS queries: 11398
   [2022-07-23 02:10:14.364 1918M]  -> Blocked DNS queries: 16328
   [2022-07-23 02:10:14.364 1918M]  -> Unknown DNS queries: 0
   [2022-07-23 02:10:14.365 1918M]  -> Unique domains: 1106
   [2022-07-23 02:10:14.365 1918M]  -> Unique clients: 9
   [2022-07-23 02:10:14.365 1918M]  -> Known forward destinations: 2

What makes you think that DNS isn't working?

From a client that you observe to lack DNS resolution, what's the output of the following commands:

nslookup pi.hole
nslookup flurry.com
nslookup flurry.com

Thanks for looking at the logs and explaining for me! I don't know if it's the DNS not working or my router isn't working or I just had something dumb I configured and don't remember.

I ran the commands you suggested, here's the results.

nslookup pi.hole:

** server can't find pi.hole: NXDOMAIN
nslookup flurry.com:

Non-authoritative answer:
Name:   flurry.com
Name:   flurry.com
Name:   flurry.com
nslookup flurry.com
;; connection timed out; no servers could be reached

So it's checking my router but then nothing happens? Also FWIW, I figured out I set the DHCP Name Server in my Ubiquiti router to point to the pi.hole address for the LAN network. I thought maybe it's my router, but I really can't figure out why putting (static IP of my pihole) doesn't load the admin web interface.

Thanks for any advice!

The first two results show that your clients are using for DNS rather than Pi-hole.
Though it would be preferred if your client would talk directly to Pi-hole for DNS, that would still be a valid configuration if your router would use Pi-hole as its upstream DNS server and forward your client's DNS requests to it, ultimately allowing it e.g. to correctly resolve pi.hole.
That doesn't seem to be the case, as there is no answer for pi.hole.
You should check your router's DNS settings. Post-Install - Pi-hole documentation may help.

When forcing nslookup through Pi-hole (assuming, no DNS server could be reached.
There may be several reasons for that, e.g. it could happen if your router wouldn't provide a route to that IP, or if Pi-hole would be configured for a DNS loop.
As our debug log does not contain any hints at the latter, it seems likely that something is amiss with your network configuration.

That makes sense. The only setting I think I have on my router was what I did to follow the post install steps to have the router tell DHCP clients use the pi.hole as their DNS server. I verified this is what I have set.

On my laptop, I rand ipconfig /all and see that it says it has the DNS server set correctly...

Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . : localdomain
Description . . . . . . . . . . . : Qualcomm QCA61x4A 802.11ac Wireless Adapter
Physical Address. . . . . . . . . : A4-FC-77-6C-48-DD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::cd37:be3c:75d:73d9%17(Preferred)
IPv4 Address. . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
Lease Obtained. . . . . . . . . . : Friday, July 29, 2022 10:52:14 PM
Lease Expires . . . . . . . . . . : Saturday, July 30, 2022 10:52:13 PM
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 346356855
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-24-76-FE-C5-C8-F7-50-5D-7D-A0
DNS Servers . . . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Enabled

Does that seem correct? Yet when I do the nslookup commands, it's trying to use the router, as you said. I might just try to disable DHCP server on my router entirely and make the pihole the dhcp server.

Ok I feel like a dummy. So when I first got my whole setup working, I think it's accurate that my pihole didn't restart for about a year straight. So my symptoms were that after rebooting, I wasn't getting DNS resolution on my clients - they'd connect to my network and would fail to load any domains, and I couldn't see the web interface for the pihole either, but I could ssh into the pihole and the pihole said it was running fine. My router was set to be the DHCP server and it was successfully handing out a DNS server address that was set to my pihole.

Out of exasperation, I finally try to prove that one of my clients could see the pihole on port 53. And I could not see the pihole on port 53. But I could see it on port 22, and could ssh in. So I SSHed in and ran ufw allow 53 to ensure the port was open. And lo and behold, I started getting DNS on my network again! I did the same for port 80, and I could see the web dashboard again. So in conclusion, I was a real dummy when I first setup my pihole and was messing around with the firewall, probably unnecessarily, and what I finally ended up with that worked, did not stick after a restart.

So tl;dr if anyone else finds this, check your pihole's firewall

** EDIT **
I have so much to learn and internalize. So I just put that I wasn't sure about what I was seeing from nslookup still. But I was running nslookup from WSL2 on windows... and of course I knew that there's some networking magic that happens between the host and WSL2 so I did nslookup on windows command prompt instead and finally got the results I expected - which were different than what I see in WSL2.

So anyone else finding this, don't diagnose from a virtual machine... seems obvious yet here I am lol

1 Like