DNS resolved even when Pi-hole is off


I run Pi-hole on a NUC. I pointed the primary dns in my TP-Link router to Pi-hole's ip address. I am not using Pi-hole as my DHCP server. Everything works fine (websites load, ads blocked).

I've been wondering how to deal with a possible failure of my Pi-hole server (e.g. having Pi-hole on a second device like some people discuss on here). So I tried shutting down Pi-hole just to see what would happen. The result was that I could still load websites no problem (I guess ads weren't blocked anymore, but that was fine). I thought I would completely lose the ability to reach the internet, which is why I thought people might want Pi-hole running on a second device. Or is this only an issue when using Pi-hole as DHCP server?

Anyways, I feel like I am missing something. Can someone please help me understand? Thanks.

This could be explained by a couple of things. If the website domains had previously been resolved, the browser would already know their IP addresses and not need to look them up for a while and so it's not even talking to the Pi-hole. It could also be that there is another DNS server available and being used without you realising it. For example the DNS in your router might still be getting handed out to clients and they are using both. And some clients might be using external DNS, such as Google, directly.

The way I deal with this here is I only have one Pi-hole covering the whole network and I use it as the DHCP server and of course the DNS server. The Pi-hole DHCP server hands out addresses from .20 to .139. The router DHCP server is turned off but that is configured to hand out addresses from .140 to .254, and it has its own DNS server which sits there unused by anything and blocked by the router's firewall. External DNS is also blocked. This ensures the only way to talk DNS directly is via the Pi-hole. The Pi-hole is the only device allowed to talk DNS to the Internet.

If the Pi-hole goes offline (fails, maintenance, whatever) then the internet becomes unreachable without a DNS server available. In that case I can go into the router and enable the DHCP server. I then just have each client disconnect and reconnect to the network. It picks up a new IP address, this time from the router's upper range. This ensures there's no clash, and I can see from its IP address whether a device is still "on the Pi-hole" or has switched.

Once the Pi-hole is working again I can go into the router and turn off the DHCP server and once again reconnect clients. They pick up an IP from the Pi-hole's lower range and it's back to normal.

So in normal use it's

Clients --> Pi-hole (DHCP lower range, DNS) --> Pi-hole upstream DNS (Unbound running on Pi)
            Router (DHCP disabled, DNS running but blocked by firewall)
            External DNS, eg Google (blocked by firewall)

If Pi-hole is offline it's

            Pi-hole (offline for maintenance)
Clients --> Router (DHCP upper range, DNS, firewall turned off) --> Router upstream DNS (ISP servers)
            External DNS, eg Google (available if something wants it)

and it's a few clicks and a reconnect to switch between these two situations

1 Like

Thank you very much for the detailed response! I'm going to share some follow up thoughts below.

Your explanation confirms one suspicion I had, so thanks for mentioning it. However, I can rule this out since I intentionally visited websites I don't normally visit to make sure this wasn't the case.

That's something I hadn't considered. I never changed the DNS settings on any of my devices, so they should all be getting this from my router, I think. Are there devices (like maybe some IoT devices) that could be set to use an external DNS by default and override my network settings? That would be concerning...

This is something I have been wondering about. More specifically, my router has an optional setting called "Default Gateway" that defaults to the router's own ip address. This is just above the "Primary DNS" line, which is where I put the ip of my Pi-hole server, so I was wondering if it could be related. Is it possible that this setting was causing DNS queries to be sent back to my router when my Pi-hole server was offline? Or could there be another similar setting on my router that might be responsible for this?

The rest of your post describes a setup that is more complicated than what I care to handle at this time, but thank you for the details! My concerns come from the desire to have a simple fail safe that ensures the internet remains reachable without requiring any user intervention (especially that of less tech savvy household members) if my Pi-hole goes offline. Honestly, if my router is capable of handling this, I would be perfectly fine dealing with a few ads for the time it takes to fix the problem and not having to set up Pi-hole on a secondary device.


Devices with embedded networking are more prone to this. A 2020 paper mentions some stats and goes into the reasons why further on.

Smart home IoT devices are often configured with hard-coded DNS servers such as Google public DNS. 98% of smart assistants and 72% of smart TVs use hard-coded Google DNS servers to resolve DNS queries instead of using the default DNS server configured at the home gateway. [...] For instance, the Google Chromecast is hard-coded with Google DNS server addresses to prevent access to geo-locked content [...] Other reasons include preemptively avoiding problems caused by mismanaged DNS servers hosted by ISPs, which leads to users blaming the device for the problems.

If the router supports more advanced networking it can redirect external DNS queries to your Pi-hole so nothing escapes. Or else if it has a firewall, that can usually block "LAN to WAN" DNS from anything except the Pi-hole, though that might upset something, like the Chromecast mentioned there.

I've not seen this behaviour before (may be worth checking with TP-Link). I'd guess it's more likely that there's another DNS server being used, and when Pi-hole was offline the other DNS server was used by virtue of being one that was still responding. A lot of OSs now will contact all configured DNS and go with whichever one is responding the fastest. That's probably Pi-hole while it's up and running, and anything else while Pi-hole is offline.

Some Android phones automatically add an extra Google DNS, which is annoying.

You can get an idea of which DNS services are in use by going to DNS leak test and running the Extended test. If you're seeing various services like Google in there then that's a good indication it is another DNS server. The reference to "leak" is more for VPNs, it's not really a leak in this use-case, but still a handy tool.

Pi-hole itself is very stable and if it's running on a Pi with a decent quality SD card and good (eg official) power supply, in my experience it's been rock solid for years. One risk in that setup is if there is a power failure. You can buy a mini-UPS add-on (eg this one) for the Pi which allows it to stay up for a short while and can shut down cleanly if there's a power cut.

Take periodic backups with Settings > Teleporter so you can restore your settings to a fresh image if something does go wrong.

Handy tip – Real VNC provides a free of charge license to Raspberry Pi users for non-commercial use. You can enable VNC in raspi-config, create a free account at RealVNC and then sign in to that from the VNC icon on the Pi OS desktop. Now you can use VNC Viewer on any computer anywhere and access your Pi OS desktop. This means you can jump on to a desktop on your home network if needed, and it doesn't need any ports exposing to the Internet.

Edit – just remembered you said you run it on a NUC. Hopefully still useful info for Pi users, and if you can sort a UPS solution for the NUC then the same applies.

Thanks again for the detailed response!

I tried the extended DNS leak test you linked to and its only showing Cloudflare servers, but I may have to repeat my previous test in case some other device was on at that time.

Good to know Pi-hole is reliable. And my NUC is plugged into a UPS, so I should be good for some time.


1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.