How does this compare to using Brave Browser with ad blocking?
It blocks a lot of the phone-home from Apple devices that is built in to the OS and happens outside of the browser.
Setting up a Pi Hole made my home network faster
31–40 of 249 posts
Re: Setting up a Pi Hole made my home network faster
#32I use OpenWRT and Ad blocking on my router - is the pi hole solution superior?
Re: Setting up a Pi Hole made my home network faster
#33Earlier quoted context omitted.
If they're really evil, they'd proxy all traffic through a single host (eg. d2v3i0u0qtn52v.cloudfront.net), so you have to choose between no IOT features, or getting subjected to all the ads/telemetry.
>so you have to choose between no IOT features I'll bring out the fainting couch. These devices are enough of a poison pill that you're better off without them. You can problem block them with Pihole, but you're one update away from either circumventing the Pihole, or breaking your IoT device because something got changed on the manufacturer's end.
At that point you're better off not connecting the device to the internet at all.
Re: Setting up a Pi Hole made my home network faster
#34Won't be long now until IoT and other crap-ware devices catch on to this trend and start hard-coding DNS servers in code, or worse, using DNS encryption to avoid this sort of routine blocking by end-users. I wonder how people are thinking about solving this problem.
I solve this with a DNS based firewall.
Essentially it's just DNS filtering on steriods. You start with an empty (or preseeded) ipset, and a firewall rule that says to reject/drop all outbound traffic if the destination isn't in the ipset. Dnsmasq is setup as the default dns provider in DHCP, and it's setup to add all resolved IPs to the ipset (with an expiration so stale entries get removed).
Then it's just DNS filtering per the usual. DoH, DoQUIC, DoT, etc don't work as their hardcoded IPs are blocked by default, and DNS filtering knocks out domain resolution of the endpoints. Even if an alternate resolver is allowed through the firewall, none of it's responses get into the ipset, so it's still broken (and is a sign I need to update the DNS filter).
Works a treat on my IoT devices
Re: Setting up a Pi Hole made my home network faster
#35I keep seeing posts about Pi Holes and it looks good, but I have previously dealt with ads by appending their delivering sites to my /etc/hosts, i.e.
0.0.0.0 trashsite1.com
0.0.0.0 trashsite2.com
The only downside I see is that my approach is not network-wide. Any other reasons I should reconsider?
Re: Setting up a Pi Hole made my home network faster
#36How does this compare to using Brave Browser with ad blocking?
It’s different but has some similarities. This blocks all kinds of configured (DNS) requests from your devices, even from apps and operating systems, whereas Brave browser only blocks ads on the browser. One drawback is that this solution does DNS level blocking, and cannot handle any web page element-level blocking that may be possible in some browsers.
Re: Setting up a Pi Hole made my home network faster
#37I know some folks are anti Ubiquiti Unifi on here, but you can run pihole (along with a bunch of other stuff) right on a UDM/UDM-Pro. IMO it makes the most sense to run this on the router, and you can run it in a docker container. If you're looking for a fun hour or two project, check out: https://github.com/boostchicken-dev/udm-utilities/tree/maste...
I run a PiHole and a Tailscale exit node on my Unifi routers (previous generation). The Tailscale exit node lets me do both site-to-site VPNs and site-specific egress. The one thing keeping me from site network nirvana is that I haven't quite figured out how to set up a wifi network on the Ubiquiti device that routes all traffic through a given other exit node, however. Someday!
Re: Setting up a Pi Hole made my home network faster
#38Won't be long now until IoT and other crap-ware devices catch on to this trend and start hard-coding DNS servers in code, or worse, using DNS encryption to avoid this sort of routine blocking by end-users. I wonder how people are thinking about solving this problem.
This is already happening. The likes of Google Home et al already hardcode their own servers. I noticed that no DNS requests were being made through my Pi Hole, so when I looked, it turned out their DNS servers were hardcoded. However, I'm more worried about when they start hardcoding DoH servers.
On my router I redirect all outbound port 53 traffic not coming from my local recursive DNS server to my local recursive DNS server.
The next step in the arms race is DoH. Afaik no one has a generic answer to that beyond "treat devices behaving hostilely as hostile".
Re: Setting up a Pi Hole made my home network faster
#39Earlier quoted context omitted.
This is already happening. The likes of Google Home et al already hardcode their own servers. I noticed that no DNS requests were being made through my Pi Hole, so when I looked, it turned out their DNS servers were hardcoded. However, I'm more worried about when they start hardcoding DoH servers.
In the case of just using a PiHole, a hard-coded server would easily get around it. But if the network outright blocks random DNS requests, that only leaves DoH, which would require fixed IPs, which should be able to be detected and blocked, right? Sure, the setup becomes a bit more involved...
Surely you can have firewall redirect rule that bounces all outgoing dns to your Pi hole?
This doesn’t work with DNS over https of course.
Re: Setting up a Pi Hole made my home network faster
#40I know some folks are anti Ubiquiti Unifi on here, but you can run pihole (along with a bunch of other stuff) right on a UDM/UDM-Pro. IMO it makes the most sense to run this on the router, and you can run it in a docker container. If you're looking for a fun hour or two project, check out: https://github.com/boostchicken-dev/udm-utilities/tree/maste...
Ah I just opened this thread to ask why isn't this a standard feature on routers at this point, and lo and behold.
I hope it becomes more ubiquitous (hah) even on lower cost ones eventually.