Show HN: Pi-hole deployed at the edge on Fly.io and accessed via TailScale

[mtremsal]

https://github.com/mtremsal/pihole-fly-tailscale

Hi, I just saw this tweet[^1] by @QuinnyPig that mentions accessing your Pi-hole while traveling thanks to TailScale and wondered how to deploy Pi-hole at the edge, instead of a home lab, for improved latency.

My simple solution involves running it on Fly.io to make it easy to relocate anywhere, and embedding tailscale into the same firecracker VM (né docker container) to keep the infra dead simple and cheap.

Naively deploying a publicly accessible DNS resolver is not ideal[^2] so the main constraint was to secure the VM by 1) keeping all public ports closed and 2) having Pi-hole listen only on the private network interface created by TailScale.

It's all very straightforward but it's noticeably improved my bandwidth usage and page loading times across my laptop and mobile phone, so I figured I'd share. Suggestions for improvement are also welcome!

[^1]: https://twitter.com/QuinnyPig/status/1558521941538983936

[^2]: https://www.cloudflare.com/learning/ddos/dns-amplification-d...

[mdeeks]

This is great! I was just looking into buying some hardware for a Pi-hole but this is a much easier way to try it out.

I think you can solve this limitation by passing in a static machine key.

  Redeploying or upgrading Pi-hole leads to a new Fly.io instance, with a new TailScale private IP, thus requiring an update to the DNS configuration. This is rare enough for me as to be a non-issue, but it might be quite annoying for very frequent travelers.

It is stored in a json in /var/lib/tailscale/tailscaled.state. It's a bit off the beaten path but I believe that'll make the new instance keep the same 100.x IP address.

[mtremsal → mdeeks]

I think you're correct. The machine key[^1] is really just the public-private key pair that drives identity across tailscale. It should be possible to store it on a persistent fly.io volume or to store it as a secret passed on startup. It feels a bit too dirty for my taste haha.

[^1]: https://github.com/tailscale/tailscale/wiki/Glossary#machine...

[spockz]

I would use this, or just use my existing Tailscale setup. However, on my iPhone using Tailscale drastically reduces battery life. So much in fact that where normally I have 50-70% left before sleeping, I need to charge the phone at dinner when using Tailscale. According to iOS Tailscale was responsible for 60-80% off battery use.

So maybe I’ll just run it over the open Internet..

[mtremsal → spockz]

iOS says Tailscale used 3% of my battery in the past 24 hours, far far beyond Firefox at 70%. If so, this setup might actually save me battery life by reducing how much I need to download and render when browsing.

I imagine that everyone’s battery usage is a bit different though. Based on their blog post on how they achieve NAT traversal, I could see some network topologies requiring aggressive efforts to keep everything connected. YMMV.

[spockz → mtremsal]

That is interesting. I’m not using my phone intensively. So I suppose any work Tailscale does in the background will have a lot of impact.

I do use Tailscale to also proxy all my traffic over my exit node. This means it has to be always active. For just dns I wouldn’t need to do that of course. Might save a lot of battery.

[xrd]

I'm a little worried HN will meltdown given this is a post with both Fly.io and Tailscale in the title. I would keep your hands off the keyboard after clicking the link...

Seriously, this is super interesting and useful.

[mtremsal → xrd]

Well, truthfully, I happen to be a product guy looking for a job, and I really wanted to kick the tires of both Fly.io and Tailscale to see if I'd enjoy working on either. @QuinnyPig's tweet connected the dots for me with a use case that's 1. actually useful, 2. easy enough to build in a few hours, and 3. tailor-made to combine both products. So, not exactly a coincidence, but hopefully not shoehorned either. ;)

[kd913]

Why run this on other people's infrastructure or on the edge?

For 8 quid a year, I own my own cloudflare domain which I can use for DDNS purposes. I run this on top of wireguard, and now I have a globally accessible VPN which I can use to access my personal home infrastructure wherever I go.

I wouldn't put pihole as something that needed to individually be run on the edge.

[mtremsal → kd913]

Yep, that's completely fair. In fact, I'm pretty sure that's the setup described by @QuinnyPig with a Pi-hole in their home lab and all devices meshed together via Tailscale (so WireGuard really).

I have a bit of latency reaching my home lab when I'm traveling, hence my approach with Fly.io.

There's also the appeal of having a single self-contained Docker image solving a specific problem. I'm quite adverse to running critical services, or anything that I can't redeploy trivially, so overall I'd rather pay a bit of money for the peace of mind that a PaaS offers.

[syntaxing]

Really neat idea but using nextDNS is so much easier without the need for a VPN of any sort.

[mtremsal → syntaxing]

Agreed! In fact, I have NextDNS listed as an alternative in the README.

To be fair though, the "VPN" here is peer-to-peer and, in the case of the Pi-hole, only used for DNS. We're not talking about tunneling all traffic. According to https://ping.nextdns.io/ the latency is similar.

I'd also imagine that on iOS the NextDNS app is implemented as a VPN, no? How else would they enforce the DNS config across networks? How would they avoid annoying tricks like ISP intercepting DNS?

But overall, I agree my setup probably only makes if you're already using tailscale for other things. :p

[syntaxing → mtremsal]

Very fair point, it is a VPN on android but you don’t have to use the app and set the DNS manually in the settings. As for iOS, it is not a VPN but a network profile (?, not sure what the exact name is). My home setup has nextDNS CLI locally running with all DNS request piped through iptables and masquerading.

[mtremsal → syntaxing]

Very interesting!

This made me realize that if someone is willing to give up the NextDNS apps and simply rely on their DNS nameservers, then they might still want to use Tailscale as a way to automatically enforce NextDNS nameservers for all enrolled devices. Kind of the best of both worlds.

[syntaxing → mtremsal]

Very true, the magicDNS on tailscale is pretty amazing. Though the downside of this method is that when tailscale is off, the internet most likely will stop working (which might be a good thing in this case)

[armatav]

This is awesome - had one at home for a long time and couldn’t use it while traveling

[maxfan8]

I’m curious: what kind of latency do you observe on this setup?

[mtremsal → maxfan8]

From Pi-hole deployed on the closest edge pop, I'm seeing 32 ms roundtrip on average for ICMP pings. Definitely negligible compared to the time saved from _not_ loading a bunch of trackers and ads.

[maxfan8 → mtremsal]

Fair! Those seem like reasonable stats for a cool setup.