41–50 of 75 posts
A simpler solution: Deploy one Pi-Hole instance and then set clients to use Pi-Hole as the primary resolver and your ISP/router as the secondary. In the rare circumstance that the Pi-Hole device is down, you fallback and get the "normal" ISP DNS service.
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.
in fact I think this is just prompted me to do that.
Earlier quoted context omitted.
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…
> 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 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.
Earlier quoted context omitted.
> it's not like the Pi-Hole can block embedded ads in adware apps like YouTube on the iOS Thanks for the info. I thought this was possible and it was the sole reason why I considered setting one up. Now I procrastinated on that project long enough to learn I can cancel it.
Use YT on the web. If you have an iPhone, get Stop the Madness, which can make the ads very short and easily skippable. It also removes a lot of annoying web behaviors and is highly customizable.
A simpler solution: Deploy one Pi-Hole instance and then set clients to use Pi-Hole as the primary resolver and your ISP/router as the secondary. In the rare circumstance that the Pi-Hole device is down, you fallback and get the "normal" ISP DNS service.
It’s an approach I assumed would work when I did my first setup, but since there’s really no such thing as primary and secondary (or tertiary) resolver, I quickly realized it did not work consistently on most devices.
A simpler solution: Deploy one Pi-Hole instance and then set clients to use Pi-Hole as the primary resolver and your ISP/router as the secondary. In the rare circumstance that the Pi-Hole device is down, you fallback and get the "normal" ISP DNS service.
I did that. Then saw that filtering was inconsistent. It turns out that some systems treat the DNS list as alternatives, not as primary and failover. The spec only says the dns IPs should be specified in preference order. Nothing says to treat it as primary and failover.
I've got her on an exclusion list because she just cares about being able to click on Google ads also known as "search results".
But I might not have added her on the backup Pihole now that I think of it...
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.
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, eithe…
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.)
A simpler solution: Deploy one Pi-Hole instance and then set clients to use Pi-Hole as the primary resolver and your ISP/router as the secondary. In the rare circumstance that the Pi-Hole device is down, you fallback and get the "normal" ISP DNS service.
Have you tried this for yourself? It’s an approach I assumed would work when I did my first setup, but since there’s really no such thing as primary and secondary (or tertiary) resolver, I quickly realized it did not work consistently on most devices.
If anyone wants a redundant system and is happy not to self-host, then I can recommend NextDNS. Works great, but not free over a certain number of requests. Can’t speak to its privacy levels though - as with anything, assume records will be supplied to authorities when required. But overall it has been great - provides network wide DNS filtering and has clients for mobile and desktop devices! With a good dashboard, r…
The product seems to be pretty stagnant as well, whereas ControlD has been improving on a regular clip. I _think_ it's more expensive than NextDNS, but I don't remember it being extremely so. (Not so expensive that I know the price offhand, after all.)