Way back this was a solid way of systems management, write a collection of packages that did things and then system config would be a matter of installing a list of packages.
System as declarative configuration? It sure does seem we've been spinning in circles for the past few decades, creating a complexity stack of failed attempts at solving the same problems.
Wonder how much of that is social. E.g. processes and function calls are effectively equivalent: command line arguments are effectively positional or named parameters, while environmental variables are equivalent to dynamic binding - a powerful technique all but excised from programming languages, except for the Lisp family. And yes, this makes the shell a REPL. The main difference between a program and a function then feels like the relationship with programmers: a program is expected to be a named thing to distribute and sign with your name; a function is more ephemeral. But does this difference warrant having each in a separate, distinct, complex layer?
> Having a single DNS server for your network is very stressful
Common... He's talking about a home network.
I also have one of my Pi set up as a DNS server (running unbound directly not PiHole though) and this thing is rock stable solid.
We're talking about Linux here. I've had a Linux server reach years of uptime (kids: don't try this at home, it's not secure but it was a test of Linux's stability).
Redundancy is great though but I really wouldn't lose sleep over it. If anything you can "dd" the Pi's SD card to another one and just replace the Pi (or the SD card) should anything go wrong.
I switched last year from NextDNS to ControlD and highly recommend it. NextDNS continually gave me issues and the support is non-existent (not "oh, support is slow" but more "there is no support"). May be less of an issue for the HN crowd, but it got to be too much of a hassle.
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.)
NextDNS seems to be maintaining its DNS infrastructure, but the mobile apps are almost abandoned and don’t even work many a times. The NextDNS forums have a lot of posts without any assistance or response from the main team.
To me, it seems like the founders are not focused on customer support or making the NextDNS ecosystem better.
I agree. I use Pi for inside my network, and NextDNS as the upstream/failover and the in-the-wild DNS for my phones. For like $10 a year is good stuff.
I have two PiHole instances plugged on opposite sides of the house. Instead of the mentioned GravitySync, I just occasionally copy the backup file from the primary to the secondary pihole instance (both of which are dockerized on Raspberry Pi hardware)
Works great. Rarely need to think of it. I recommend looking up the recommended whitelist and adding anything there that looks relevant to you.
Last downtime was a month ago when external circumstances forced me to move both servers. Yhe RPi, lacking a real time clock or its neighbor to bootstrap DNS, couldn't get the current time ir dns, and thus had out-of-date certificates for dnssec... Solution was to add the direct ip address to an NTP server temporarily to the list of websites to use for NTP.
If you've got a machine running docker on your network, I definitely suggest checking out Orbital-Sync. It's a container that syncs a 'primary' pihole to as many other piholes as you need. It was a breeze to configure.
Having two main servers hosting Pi-Home works great - until both of them are offline for any random reason.
So I added a third Pi-Hole following Techno Tims easy to follow guide.
By using keepalived and VIP I can update, restart and tinker with the two servers as much as I want.
https://youtu.be/hPfk0qd4xEY
> I have never used macvlan (or ipvlan) networking with Docker, I don’t know how to set it up, and I’ve read conflicting and confusing reports about how easy it is to use with Pi-Hole
macvlan is cool in theory. it lets you broadcast a "real" MAC address through your container's veth. this allows it to get a real IP from your router. you can even use VLAN trunking to assign the MAC to a VLAN on your physical NIC.
that said, i only learned about it to discuss it in my course. my dockerized Adguard Home instance uses host-mode networking since that binds the physical ifaces into the container and is just as fast as any other networked process. it's also WAY WAY WAY easier than trying to get pi-hole working in bridge mode, I've found.
(I used to use pi.hole for a long time but AdGuard Home is nicer and updates itself automatically out of the box.)
macvlan can help get you slightly better networking performance by avoiding internal SNAT but it's marginal at best in most cases compared to the work required to maintain macvlan/ipvlan containers. it's also, as you pointed out, not very well documented (because it's not used very often).
This feature along with storage drivers are relics from a time when Docker was poised to own the container orchestration space with Swarm. All of the third-party contributions to Docker Engine basically died once Kubernetes reached critical mass, which was somewhere between 2018 and 2020. Weaveworks was probably the only company with an actively maintained networking driver for Docker Engine, but they are gone now :(
I recently set up a Pi-Hole for the first time, but I spun it down pretty quickly. On desktop / mobile I already have client-side ad-blocking, and it's not like the Pi-Hole can block embedded ads in adware apps like YouTube on iOS, so I just couldn't really justify keeping it powered.
I suppose if you have a house full of Samsung / Huawei / etc. IoTs that you really need to keep connected to the Internet for whatever reason, I could sort of see it, but I don't and I genuinely can't figure out other use cases for it. I'm far from a networking whiz though. Am I missing something?
There's a lot of advertising activity that ublock doesn't catch, but Pi-Hole does. Usually it's tracking APIs rather than ads themselves.
It's also useful for clients where I can't install client-side adblocking, ie smart TVs (which try to phone home a _ton_ of advertising/analytics information). I also don't use client-side adblock on my work laptop (can't install unapproved extensions) nor my iPhone, so Pi-Hole still lets me browse ad-free on those.
Back when I was working (a few years ago now), my company laptop had some lame Cisco DNS proxy installed in the name of "security." The laptop ignored the DNS servers provided by DHCP and the proxy used a pinned company DNS server. Any DNS requests that could not be resolved would redirect to some questionable server on the open Internet that also happened to have an ssh server on port 22.
None of this bothered me until the time I tried to ssh into one of my local boxes, was and redirected to the bogus server, which prompted me for my password, which I stupidly provided out of habit.
So now some random server on the open Internet has collected the hostname, username, and password for my local machine. I reported this to the company IT department and their response was a shrug.
I run a pair as my DNS. For me they're mostly there to block tracking over ads. Approx 10% of my DNS lookups get eaten by it using the standard ad list. Ublock / privacy badger grabs a bunch, the piholes still kill a bunch more.
> 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.
Some people (like me) primarily consume YT content on their TV. I also set up a pihole with the intent of blocking YT ads on my TV, but pihole is useless for that. Instead, it broke after a few weeks and had to be rebooted. So, sure, if you look into the logs, you see it blocked a lot of tracking chatter, but other than that, it had a perceived negative value if you ask me.
Instead I sideloaded SmartTubeNext on my Fire TV and just live with the banner ads.
Patreon – no. You pay a subscription to YouTube and you don't get served ads. Some of the money from these subscriptions is then divided between the creators, similar to how Spotify works.
YouTuber makes more money on average when a YouTube Premium user watches their video than what they would get from the ad-view if the person wasn't on Premium.
All in all it's reasonable IMHO. I might purchase it some time. The only issue is that this of course doesn't remove sponsorships baked into the videos, which annoy me just the same as the YT ads. So, I would still need Sponsorblock.
Mine still runs happily on a PI Model B Plus with no downtime except for maintenance.
Some DNS/Netwrk fallbacks on the DSL Router.
Imho the risk/consequences of a downtime don't justify having some hardware draining power.
If all goes down ansible will have provisioned a new pi in no time.
Nevertheless i applaud the effort and am happy to have learned some things from the article
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.
Quite a few DNS clients don't make any distinction between "primary" and "secondary". You may enter them in order when configuring them but that has no bearing on which ends up being the server queries are sent to.
I found windows to be like this. It has no specific order on primary or secondary. However, occasionally it will latch on to one of them and continue sending several lookups to that one.
The problem is that many devices instantly spill over to the secondary Pi-Hole. And rogue devices bypass the primary altogether once they begin to get blocked for a short period of time. Having a secondary without blocking nearly negates the benefit of having the primary pi-hole, for the devices that it matters for most.
This is why you need a port 53 ban on your network that blocks all traffic except to your piholes ips. Keeps rogue machines from reaching the internet for queries
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.
I did, and according to the man page of /etc/resolv.conf the order is taken into account unless you specifically set the option not to. Which covers macOS, i(Pad)OS and Linux, and afaik also my Windows machine (I haven't checked the latter though).
I did this and started to wonder why every web page opened reeaaallly slowly.
Turns out the Pi-Hole Raspberry Pi had borked and wasn't answering at all, my computer was waiting for the primary DNS _every_time_ for multiple seconds before trying the secondary one.
What it should've done (IMO) is query both and pick the fastest.
Swapped to NextDNS and haven't looked back, I set it on my router and mobile devices once and that's it.
def don't do this unless you want dns leaks all over the place. the pi-hole should be the only dns server in its networks. you can also use it as a dhcp server to work around ISP routers blocking DNS modification.
Redundancy is good and I considered doing this too, but my pi-hole runs as a VM on the same hypervisor that hosts my router, so any hardware failure takes down the whole network anyway.
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.
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.
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.
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.
I have AdGuardHome running in a Docker on the PVE that also hosts my router (OpnSense) in a VM. They both have an uptime of 341 days (which was the last time I did a scheduled kernel upgrade on the host machine). There is no reason for a redundant DNS server on a typical home network.
I used to do it that way.
However, when I did a restore to my opnsense server it could not reach the internet to update or install the adguard package because the dns wouldn't resolve!. I had to do the extra steps to move the dns externally, update/install adguard and then reimport the backup settings (or change the dns to adguard again).
I settled on virtualising Opnsense and Adguard separately on a proxmox instance.
Why not use a tunnel like Wireguard so that you don't need an IP filter on the rental box side? That way if your home public IP is reassigned you don't have so much work to do. Bonus encryption for DNS traffic, too.
Here you go, no package required:
[0] - https://github.com/cdzombak/apt-daily-clean