So, check this little idea that I have - I want to browse the internet without all sorts of unscrupulous actors collecting every little bit of metadata on me and my family they can possibly get their hands on.
You specifically shouldn’t run two DHCP servers on the same network. It can cause IP conflicts when two servers assign the same address to different devices. Because the device doesn’t care which DHCP server gave it an address; It just listens to whichever one happens to respond first. And each DHCP server will have its own table of reserved/in-use addresses. And if those tables don’t match, IP conflicts can occur.
Device 1 connects to the network, and requests an IP address. DHCP server 1 checks its table of available addresses, and responds with “your address is 192.168.1.50.” It marks that address as in-use, so it won’t assign it to anything else in the meantime. Device 2 connects to the network, and requests an address. DHCP server 2 checks its table of available addresses (which doesn’t match server 1’s table) and responds with “your address is 192.168.1.50.” Now you have two devices occupying the same IP address, which breaks all kinds of things.
The largest reason to run two is because DNS queries are split amongst the primary and secondary DNS servers. If you only have a primary pihole, you’ll still occasionally get ads when devices use their secondary DNS servers.
I’ve got two piholes running on the home network, and they are both DHCP servers - with different ranges, i.e. #1 serves 192.168.0.11 - 100, and #2 serves 101-200. Each uses option 6 to specify DNS servers, and they both reference each other. It doesn’t matter if one goes down because each client will have the both piholes specified as DNS servers. I’ve never had an address conflict problem.
Sorry, uh… I didn’t mean run them at the same time. I had to have a DHCP server stand in for it when I had to take that device itself down (the pi). That was ages ago. But I was still starting out!
The way secondary DNS works is that a client distributes DNS requests across the primary and secondary DNS servers. So if you have pihole as your primary DNS and, say, 8.8.8.8 as your secondary DNS, you’re sending half of your DNS requests to google unfiltered. And if your pihole DNS goes down, half of your DNS queries time out.
The way to have redundancy with DNS is with a standby server that takes over the IP of the primary server if it goes down. You can do this with keepalived.
And what do you set that secondary DNS entry to? Operating systems may use both, so you need the secondary to point to a pi hole or else you’re letting ads through randomly.
Randomly? No, only when your pi goes down. Or when ever you’re looking at something that gets around the simple DNS based ad filtering pinhole does. It’s foolish to spend twice as much money for this level of fail over protection to prevent ads. It’s not like if you see an ad you’re going to die lol. If you’re that opposed to them, sure, go for it, but you’re better off spending your time doing other things to stop ads than maintaining two pi holes because one might fail.
And like the other person said, just use ad guard’s public DNS. I use it on my router and on my phone.
Why call it secondary then, that’s so counterintuitive lol 😭 I guess “the second hardest problem in computer science” applies because I can’t think of a better name either.
Sure, if your router supports DoH or DoT. Most consumer routers don’t. I know that Mikrotik supports it out of the box, and OpenWRT has a package for that.
Adguard Home has been absolutely rock solid for me, and it offers DoT and DoH servers so you can easily connect devices over those protocols if you want to.
honestly don’t find it necessary. raspberry OS basically never needs to be rebooted and if you really need planned maintenance you can just use a normal DNS server til you’re done.
Interesting… And this is not a criticism, simply an observation…
I’ve a single Pihole instance running on a RPi 4 and have experienced not a single instance of any of the 3 probs you mention. Except, of course, the very few minutes it takes for a reboot which I can schedule and am aware when it’s happening…
Raspberry Pies (is that how you pluralize it?), and especially their SD cards are not the most reliable pieces of hardware. I’ve already had a few die on me.
As for how annoying outages are, I guess that depends on how many people and services you have on your network relying on a functioning DNS. I am running two pihole instances on separate hardware in a keepalived virtual IP setup, with a replicated configuration. Sounds complicated, but it’s really easy.
It’s just nice to be able to reboot or perform maintenance on my pihole knowing it won’t impact DNS, and not having to worry about interrupting my girlfriend streaming her Netflix series or whatever. For example, just a couple of weeks ago I converted my bare-metal pihole installation to a dockerized one, which was a couple of hours of work, without any DNS downtime at all.
I’d say part of it comes down to what your log level is set at. My pi-hole ran on the pi for like 3-4 years before it destroyed the sd card and crashed. I know some people make immutable filesystems for them etc. If you’re writing to the sd card it’s just a matter of when, not if it will fail.
Literally just had my pihole hard crash this weekend due to a bad update to FTL. Apparently they had a major version upgrade and didn’t bother to read the notes so I had to do a full OS reinstall.
Back up your configs people. Had to dig through documentation to find the sqlite file and then parse through it like some sort of animal.
Literally just had my pihole hard crash this weekend due to a bad update to FTL. Apparently they had a major version upgrade and didn’t bother to read the notes so I had to do a full OS reinstall.
The v6 upgrade was such a disaster. I was bitten by it too, it started the upgrade then halfway through decided it didn’t like my OS (debian-testing) and crapped out … leaving me with a b0rked installation. Luckily I was able to return to v5 using my system backup. It was a right pain to figure out how to restore though, because they write files all over /opt, /etc, /usr/bin, /usr/local and /var.
For this reason I have since dockerized my pihole installation. Not only does this allow you to choose the exact pihole version you want (a bare metal install only supports the latest version), but it allows you to centralize your configuration files neatly under a docker volume, so you only have to backup the volume.
I waffled back and forth on a docker install. Outside of the initial panic to reinstall the OS (Ubuntu 24.04 for me), it was relatively straightforward outside of the config. It may be worth it to dockerize it so I can git control the config but not sure how easy it is under v6. They really changed how the files are parsed.
Before pihole was essentially a frontend for dnsmasq but it seems like it’s a bit more than that now. I haven’t had the chance to look too much under the hood.
If I’m being honest, I’ve wanted to off-load pihole to my router but lack the time and patience these days. I’ve reached the point in my life where IT isn’t the most important thing anymore and just need it to work.
I’ve a single Pihole instance running on a RPi 4 and have experienced not a single instance of any of the 3 probs you mention. Except, of course, the very few minutes it takes for a reboot which I can schedule and am aware when it’s happening…
Yeah, I believe it can vary depending on how you host it.
In my experience whenever I brought down the PiHole instance (Docker Compose) I would lose all internet access, which is expected since I’m essentially taking away my devices one and only library, so to mitigate this I spun up PiHole on another device and set that as my secondary (backup) DNS resolver.
This way I can take a container down, update it and all without losing resolution to the internet.
Right, I didn’t have any issues running it on a pi for years too. The problems came when I started messing with things. So, really my advice is to help save people from ideas like mine.
I decided one day to take a bunch of old laptops and create a proxmox cluster out of them. It worked great, but I didn’t have a use for them, I was just playing. So, I decided to retire the pi and put the pihole on the cluster. HA for the win!
I did that and came woke up a few days later to my family complaining that they had no internet. I found the pihole container on a different node and it wouldn’t start. Turns out with proxmox you need separate storage for HA to work. I had assumed that it would be similar to jboss clustering which I’m familiar with, and the container would be on all the nodes and only one actice at a time, with some syncing between nodes. Nope.
What’s worse is the container refused to move back to the origional node AND wouldn’t start. The pi was stored away at this point so I figured it would be easier to just create a new container, but duh, no internet. Turn off dns settings on the router, bam have internet.
Eventually set up the old pi again, and it took me a while to figure out what I had done wrong with proxmox. But while I was figuring it out it was nice to have the backup.
Now I always have two running on different hardware, just in case.
I recommend having two. Otherwise your home internet goes down everytime you update or reboot or it crashes.
Yes especially if you’re using DHCP on Pi-hole
You specifically shouldn’t run two DHCP servers on the same network. It can cause IP conflicts when two servers assign the same address to different devices. Because the device doesn’t care which DHCP server gave it an address; It just listens to whichever one happens to respond first. And each DHCP server will have its own table of reserved/in-use addresses. And if those tables don’t match, IP conflicts can occur.
Device 1 connects to the network, and requests an IP address. DHCP server 1 checks its table of available addresses, and responds with “your address is 192.168.1.50.” It marks that address as in-use, so it won’t assign it to anything else in the meantime. Device 2 connects to the network, and requests an address. DHCP server 2 checks its table of available addresses (which doesn’t match server 1’s table) and responds with “your address is 192.168.1.50.” Now you have two devices occupying the same IP address, which breaks all kinds of things.
The largest reason to run two is because DNS queries are split amongst the primary and secondary DNS servers. If you only have a primary pihole, you’ll still occasionally get ads when devices use their secondary DNS servers.
I’ve got two piholes running on the home network, and they are both DHCP servers - with different ranges, i.e. #1 serves 192.168.0.11 - 100, and #2 serves 101-200. Each uses option 6 to specify DNS servers, and they both reference each other. It doesn’t matter if one goes down because each client will have the both piholes specified as DNS servers. I’ve never had an address conflict problem.
Sorry, uh… I didn’t mean run them at the same time. I had to have a DHCP server stand in for it when I had to take that device itself down (the pi). That was ages ago. But I was still starting out!
Huh? Typically you have a secondary DNS entry on your router
Secondary DNS is not for redundancy!
The way secondary DNS works is that a client distributes DNS requests across the primary and secondary DNS servers. So if you have pihole as your primary DNS and, say, 8.8.8.8 as your secondary DNS, you’re sending half of your DNS requests to google unfiltered. And if your pihole DNS goes down, half of your DNS queries time out.
The way to have redundancy with DNS is with a standby server that takes over the IP of the primary server if it goes down. You can do this with keepalived.
That’s so weird wtf why don’t they call it something like “DNS pool” then?
I have two piholes - they serve different DHCP ranges (e.g. 1-100 and 101-250), and option 6 references each other.
And what do you set that secondary DNS entry to? Operating systems may use both, so you need the secondary to point to a pi hole or else you’re letting ads through randomly.
Randomly? No, only when your pi goes down. Or when ever you’re looking at something that gets around the simple DNS based ad filtering pinhole does. It’s foolish to spend twice as much money for this level of fail over protection to prevent ads. It’s not like if you see an ad you’re going to die lol. If you’re that opposed to them, sure, go for it, but you’re better off spending your time doing other things to stop ads than maintaining two pi holes because one might fail.
And like the other person said, just use ad guard’s public DNS. I use it on my router and on my phone.
Not how secondary DNS works. It round robins the requests across primary and secondary DNS servers.
Why call it secondary then, that’s so counterintuitive lol 😭 I guess “the second hardest problem in computer science” applies because I can’t think of a better name either.
dns.adguard.com
Sure, if your router supports DoH or DoT. Most consumer routers don’t. I know that Mikrotik supports it out of the box, and OpenWRT has a package for that.
They have IPs too: https://adguard-dns.io/en/public-dns.html
94.140.14.14
94.140.14.15
Adguard Home has been absolutely rock solid for me, and it offers DoT and DoH servers so you can easily connect devices over those protocols if you want to.
I just use their free public option. It’s basically as good as pihole. With pihole I still got some ads. I still get some like this.
Great, I recommend having two Adguard Home instances.
honestly don’t find it necessary. raspberry OS basically never needs to be rebooted and if you really need planned maintenance you can just use a normal DNS server til you’re done.
Right, I never said two raspberry pis, I meant two instances. Like one pi and a container run elsewhere.
Mine never crashed until the latest major update, now it’s down every time I come home. Am mad
Yep, if you have somewhere to put a docker container or VM you can have redundancy.
Interesting… And this is not a criticism, simply an observation…
I’ve a single Pihole instance running on a RPi 4 and have experienced not a single instance of any of the 3 probs you mention. Except, of course, the very few minutes it takes for a reboot which I can schedule and am aware when it’s happening…
🤷♂️
Raspberry Pies (is that how you pluralize it?), and especially their SD cards are not the most reliable pieces of hardware. I’ve already had a few die on me.
As for how annoying outages are, I guess that depends on how many people and services you have on your network relying on a functioning DNS. I am running two pihole instances on separate hardware in a keepalived virtual IP setup, with a replicated configuration. Sounds complicated, but it’s really easy.
It’s just nice to be able to reboot or perform maintenance on my pihole knowing it won’t impact DNS, and not having to worry about interrupting my girlfriend streaming her Netflix series or whatever. For example, just a couple of weeks ago I converted my bare-metal pihole installation to a dockerized one, which was a couple of hours of work, without any DNS downtime at all.
I’d say part of it comes down to what your log level is set at. My pi-hole ran on the pi for like 3-4 years before it destroyed the sd card and crashed. I know some people make immutable filesystems for them etc. If you’re writing to the sd card it’s just a matter of when, not if it will fail.
Literally just had my pihole hard crash this weekend due to a bad update to FTL. Apparently they had a major version upgrade and didn’t bother to read the notes so I had to do a full OS reinstall.
Back up your configs people. Had to dig through documentation to find the sqlite file and then parse through it like some sort of animal.
The v6 upgrade was such a disaster. I was bitten by it too, it started the upgrade then halfway through decided it didn’t like my OS (debian-testing) and crapped out … leaving me with a b0rked installation. Luckily I was able to return to v5 using my system backup. It was a right pain to figure out how to restore though, because they write files all over /opt, /etc, /usr/bin, /usr/local and /var.
For this reason I have since dockerized my pihole installation. Not only does this allow you to choose the exact pihole version you want (a bare metal install only supports the latest version), but it allows you to centralize your configuration files neatly under a docker volume, so you only have to backup the volume.
I waffled back and forth on a docker install. Outside of the initial panic to reinstall the OS (Ubuntu 24.04 for me), it was relatively straightforward outside of the config. It may be worth it to dockerize it so I can git control the config but not sure how easy it is under v6. They really changed how the files are parsed.
Before pihole was essentially a frontend for dnsmasq but it seems like it’s a bit more than that now. I haven’t had the chance to look too much under the hood.
If I’m being honest, I’ve wanted to off-load pihole to my router but lack the time and patience these days. I’ve reached the point in my life where IT isn’t the most important thing anymore and just need it to work.
Yeah, I believe it can vary depending on how you host it.
In my experience whenever I brought down the PiHole instance (Docker Compose) I would lose all internet access, which is expected since I’m essentially taking away my devices one and only library, so to mitigate this I spun up PiHole on another device and set that as my secondary (backup) DNS resolver.
This way I can take a container down, update it and all without losing resolution to the internet.
Right, I didn’t have any issues running it on a pi for years too. The problems came when I started messing with things. So, really my advice is to help save people from ideas like mine.
I decided one day to take a bunch of old laptops and create a proxmox cluster out of them. It worked great, but I didn’t have a use for them, I was just playing. So, I decided to retire the pi and put the pihole on the cluster. HA for the win!
I did that and came woke up a few days later to my family complaining that they had no internet. I found the pihole container on a different node and it wouldn’t start. Turns out with proxmox you need separate storage for HA to work. I had assumed that it would be similar to jboss clustering which I’m familiar with, and the container would be on all the nodes and only one actice at a time, with some syncing between nodes. Nope.
What’s worse is the container refused to move back to the origional node AND wouldn’t start. The pi was stored away at this point so I figured it would be easier to just create a new container, but duh, no internet. Turn off dns settings on the router, bam have internet.
Eventually set up the old pi again, and it took me a while to figure out what I had done wrong with proxmox. But while I was figuring it out it was nice to have the backup.
Now I always have two running on different hardware, just in case.
🤷♂️
I didn’t have a problem on my Pi-hole for a very long time too. OP has that probably because s/he’s using it as a DHCP server as well.
Certainly possible though not so versed in Pihole capabilities that I can imagine how that happens…
My DHCP is handled by an EdgerouterX…
My Pihole is limited to DNS only.