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.
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…
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.
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.
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.
Edit: Apparently years of seeing it called primary and secondary led to a fundamental misunderstanding of how it works lol. Just use a pi and ad guard.
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.
Different Operating Systems call it different things. Windows calls it Alternate. Even if it was only used when the primary was down, DNS doesn’t provide any sort of guidance or standard on when to switch between primary and secondary. Is one query timeout enough to switch? How often do you reattempt to the first DNS server? When do you switch back? With individual queries, you can timeout and hit another NS server, but that’s a lot easier at an individual level than to infer a global system state from one query timing out.
I recommend having two. Otherwise your home internet goes down everytime you update or reboot or it crashes.
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…
🤷♂️
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.
deleted by creator
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.
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.
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.
Edit: Apparently years of seeing it called primary and secondary led to a fundamental misunderstanding of how it works lol. Just use a pi and ad guard.
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.
I don’t think that’s even the official naming. It probably comes from what Windows 95 called it back in the day:
On Linux, it’s just an additional “nameserver x.x.x.x” line in
/etc/resolv.conf, with no indication of which is the “primary” or “secondary”.Different Operating Systems call it different things. Windows calls it Alternate. Even if it was only used when the primary was down, DNS doesn’t provide any sort of guidance or standard on when to switch between primary and secondary. Is one query timeout enough to switch? How often do you reattempt to the first DNS server? When do you switch back? With individual queries, you can timeout and hit another NS server, but that’s a lot easier at an individual level than to infer a global system state from one query timing out.