Hacker News Reader

Comment by Humphrey | Hacker News Reader

I am also running a Pi-Hole and have wondered about what happens when/if the Pi-Hole goes down.

Is there a simple way to have a failover/fallback DNS configured rather than requiring two Pi's? On failure, I'd like my DNS to just fallback to my routers default DNS - yes I'd get ad's but I think that's acceptable.

View on HN

Usually in your router/DHCP you can configure two DNS servers. Define the PiHole as the first, and whatever upstream fallback IP you want as the second.

Note that this quite often results in round robin between the two DNS servers, not a primary and fallback as intended.

There are two ways a home router can control your DNS:

A) Each client has one DNS server: the router's local IP address. The router runs dnsmasq or whatever to proxy the DNS requests.

B) Each client has one or more DNS servers, with the router's IP address not listed, or listed last.

If you set up B, I think most operating systems will usually use the servers in order, i.e. only fall back to the second (ISP) server if the primary (pi-hole) doesn't respond.

Nice. I'm using method B, but I cannot remember if I added a second IP or not. I'll need to try this when nobody else is at home.

At least on macOS I found that if:

DNS Server 1 = Pi-Hole

DNS Server 2 = ISP DNS Service, OpenDNS, your router whatever

when pi-hole blocks the ad's DNS query, macOS will treat that as a DNS failure and use DNS Server 2 as a fallback. Resulting in the ad being shown.

Doing (A) was my first attempt and at least using a Ubiquiti router, if Pi-hole blocked a DNS query it would always fallback to the secondary DNS server. In my environment, the only way I was able to get pi-hole to work consistently was to set the pi-hole server as the only DNS server in the DHCP server.

> when pi-hole blocks the ad's DNS query, macOS will treat that as a DNS failure and use DNS Server 2 as a fallback. Resulting in the ad being shown.

My experience with OSX and Pi-Hole doesn't match your experience. There's a difference between appearing to be in a failure mode (i.e. timing out) and returning blocked (null/0.0.0.0) results.

I set this up a few years ago and now that time has passed I'm not confident enough to claim what exactly led me to that conclusion. I never got around to setting up a second pi-hole server which is what led me to click on the article above. 3 years in and I've never had a blip in service so I just haven't prioritized it.

I did go and test this now, and agree with you. On macOS I set my primary DNS to pi-hole and secondary to 8.8.8.8. running dig on api.segment.io (blocked on pi-hole by default), it resolved to 0.0.0.0 via pi-hole and did not try 8.8.8.8 on any attempt. So my earlier comment is incorrect above and setting a secondary DNS server as a back-up may work.

FWIW I had to undo B) just yesterday. I thought the same thing about resolving records in order but it does not. I didn’t dive too far in, but my proxy server would occasionally query my router instead of the pihole for DNS requests. Maybe I just did it wrong :)

For the record I was assigning these DNS server IPs via docker compose. So perhaps that makes a difference.

Even better than failover is reliability. I fought with pi-holes for years. Now I have a pfsense firewall and I'm no longer hacking together half solutions to networking challenges or rerolling an OS on a new SD card once a year.

It seems like concern over reliability of the PiHole is a common concern (between the original post and the comments). I guess I'm just not sure why. I just run one, and have for quite a while. I've never had any issues, which suggests to me that the probability of failure is pretty low. But more importantly, the impact of failure is (in my opinion) almost zero. It's a home network. If the PiHole has a problem, either fix it, or change your DHCP server to hand out a different DNS server and renew a few leases.

If you have other, less technical family members on your network, this becomes a bigger problem, especially if you work from an office or take business trips.

What’s a 60 second side quest for us is a “wifi’s down” for them. (Any outage at my house is reported as a WiFi problem.)

I’ve had problems a couple of times in several years. Part of the issue is that it is rare—so that when it does happen, I just figure the ISP is being flaky instead of my mind immediately jumping to DNS problems.

With my new home network setup, my main pihole will run on docker, but my failover will be running on an old raspi that I have no other good use for. If the first goes down I'll know because my heimdall page won't load, and I'll set up some sort of ping check for the second just in case it goes down.

DNS isn't really suitable for an active/backup solution. Generally, you can't do that without some automation or some explicit support from the device, which is basically non-existent.

In my mikrotik device I do have a small script to replace my DNS entry with Cloudflare in case it becomes unresponsive (and then back again once it's up). That is not very transparent though and devices will get errors until the switch happens.

Reply on news.ycombinator.com