Pi-hole client filtering without DHCP?
Pi-hole client filtering without DHCP?
Hi all - please tell me if I'm doing this wrong:
My 12yo spends all day on YouTube shorts. I want to block it, but can only block YouTube entirely. Blocking for everyone would upset my 15yo, so I need per-client domain filtering.
That was easy on Pi-hole. But my Raspberry died and I heard praise for Adguard Home so now I run that as a Docker container.
- I can't figure out how to block YouTube for only some devices. Is that not possible with Adguard? Claude gives me complicated nonsense; you can easily do better.
I want to ditch Adguard and go back to Pihole. The caveat is that I must let Pihole run the DHCP server, in order to get correct per-client blocking. That's a pity, as I have a neat UniFi network set up.
- Can I get Pihole's per-client blocking without Pihole as DHCP?
I don't mind setting it all up in Pihole again because I know it works (it's how I had it before the Raspberry died). But I would love to know if I am going about this the wrong way? Thank you!
You're viewing a single thread.
Pihole can set up "groups" for different blocklists. You specify client by IP or MAC address so it doesnt matter what the dhcp server is, so long as there's a static IP or static MAC address. My pihole server doesn't have dhcp set up and I'm able to do this fine
Though from personal experience this just becomes a game of cat and mouse, and if you have a motivated teenager then they will find a way to circumvent this. For example android can rotate MAC addresses, and IP addresses are trivial to spoof as well.
Just curious - what’s the progression if they setup client allowlisting to require manually approving new ips or macs.
- Custom DNS servers specified on the device to circumvent the pihole
- dns over https or tls
- hotspot from approved device
- alternative YouTube front ends
These are just off the top of my head. Best case scenario the blocking does work and the teen never tries to bypass it. They'll still just move onto "wasting" time on something else. This is treating the symptom and not the root cause.
You are correct - this isn't a tech issue at its root. But it is one of the arrows in the quiver.