4 ms·
Wouldn't help here, since most people have to use DDNS to connect back home since residential IPs change constantly. And with no DNS resolver, no DDNS lookup, n
by yabones 4y ago
Wouldn't help here, since most people have to use DDNS to connect back home since residential IPs change constantly. And with no DNS resolver, no DDNS lookup, no phone home.
Best way to handle it is to just reconfigure your router to hand out the pihole dns server to all the clients on your network. That way it's automatic when at home, and doesn't override anything when you're away.
- HelenePhisher 4y agoYou could just use Tailscale.
- robby_w_g 4y agoI think tailscale could handle this problem pretty well: https://tailscale.com/kb/1114/pi-hole/ https://tailscale.com/kb/1114/pi-hole/ You can configure the default DNS for devices when they connect to tailscale. This way, pi hole is opt in for users who want to set up tailscale. Disclaimer: I haven't tried this myself since I have Mullvad ad blocking setup and I'm lazy
- feet 4y agoMy method is to set up wireguard from my home network to a cheap VPS. I can then VPN into that VPS and get into my home network since the VPS has a static IP But as others mention tailscale also works
- dspillett 4y agoAnother option is to make your pi-hole semi-public, so you can see it what-ever network you are on. You don't want the world and his dog's flees using your DNS resolver though, so you'd have to arrange some for of port-knocking or other authentication solution to temporarily open up the relevant ports to you (or at least just the network local to you) and not everyone. Another hack to consider is running pi-hole in a VM or container on the laptop itself, and have it act as a filtering cache for a more public resolver. Though this imparts an administrative load, you no longer have a single pi-hole so either need to configure it separately or arrange for it to be able to sync with config on your main instance. Both these arrangements will have trouble if you find yourself on a network that blocks DNS requests to anything other than its local resolvers (though for the pi-hole-on-laptop you can always reconfigure pi-hole to look at the local resolvers if/when needed), so the VPN option is better where available. If you have no static IP at your base of operations, there is always the option of a cheap VPS somewhere to be the VPN endpoint – essentially my first paragraph but your “port knocking” is connecting to the VPN, with pi-hole either on that machine or a machine also connected to the same VPN to get around its lack of fixed public address. Though back to the adversarial local network problem: if the network blocks DNS queries to non-local resolvers it is not unlikely to try block VPNs too.