Ad-blocking that follows you — and can't take the house down
The last part introduced the home anchor — a small always-on computer on the tunnel — and promised the first thing it carries would be the reason I leave the tunnel connected all day. This is it: Pi-hole — network-wide ad and tracker blocking, done at the level of the network rather than in each browser. It’s a small service with one design decision behind it that I think is the best call in the whole build.
Blocking at the network level
Most ad-blocking happens inside the browser, as an extension. That works, but it only covers that browser — not apps, not smart devices, not other browsers, and nothing on your phone outside the one app that has the blocker built in.
The alternative is to block at the point where every device asks “where is this website?” — the DNS lookup that happens before any connection is made. A small service on the home anchor answers those lookups, and when a device asks for a known ad or tracker domain, it simply answers “nowhere.” The ad never loads because the device is never told where to find it. This covers everything on the device at once — every app, every browser, the background chatter of the operating system itself — because it works one layer below all of them. It also runs on a tiny amount of the anchor’s resources; answering DNS lookups is light work.
That part is standard and well-trodden. The interesting decision is who it applies to.
The decision: scope it to the tunnel, not the house
The obvious way to deploy network-wide blocking is to point the whole household at it — set the home router so every device, for everyone in the house, uses the blocker for DNS. Maximum coverage. I deliberately didn’t do that, and the reasoning is the heart of this part.
If the entire household depends on the anchor for DNS, then the anchor becomes a thing that can break everyone’s internet. The moment it’s down — a failed drive, a crash, an update gone wrong, or just me tinkering with it — every device in the house is suddenly unable to look up any website at all. To everyone else, the internet appears broken, and the cause is a hobby box I was fiddling with. For a home network shared with people who just want things to work, that’s an unacceptable failure mode. A device whose whole purpose is to be reliable shouldn’t also be a single point that takes the household down when it isn’t.
So instead of forcing it on everyone at the router, I scoped the blocking to the tunnel. Only devices connected to the tunnel use the anchor for DNS; every other device in the house uses ordinary public DNS and never touches the anchor at all. The router is left completely out of it.
What that choice buys
Scoping it to the tunnel instead of the house looked at first like less — fewer devices covered — but it turned out to be the better deal in every way that matters to me.
The anchor can never break the household’s internet. Because nothing outside the tunnel depends on it, it can fail, reboot, or be taken apart on the bench and the rest of the house doesn’t notice. If it’s down and I want blocking back, I just… don’t connect to the tunnel, and I’m on normal internet like everyone else. It’s optional by design. That safety is exactly why I was comfortable making it always-on and building more onto it later — it carries no risk to anyone but me.
The blocking follows my devices everywhere. This is the part I didn’t fully appreciate until I lived with it. Because the blocking rides the tunnel rather than the home network, it comes with me. My phone gets the same ad and tracker blocking on mobile data, on café Wi-Fi, on any network anywhere in the world — as long as the tunnel’s up, which for my own devices it almost always is. Home-router-based blocking stops at the front door; this doesn’t. The coverage isn’t tied to being home; it’s tied to being me.
Those two properties are the same coin. By refusing to make the anchor the household’s DNS, I gave up whole-house coverage and got back something better for my purposes: a blocker that’s personal, portable, and completely safe to depend on because nobody else does. It’s the clearest example in the build of a choice that looks like a limitation and is actually the point.
The quiet everyday payoff
This is also the answer to a question the tunnel part left open: why leave the tunnel connected all the time, rather than switching it on only when needed?
Because this is running on it. Once the blocking follows my devices everywhere and costs nothing to leave on, there’s no reason to keep switching the tunnel off — and every day it’s on, everything I browse is quietly cleaner, everywhere I am. The security benefits of the tunnel were the reason I built it; this is the reason I actually use it, all day, without thinking about it. The most-used feature of the whole setup turned out to be a small DNS service on a tiny computer, doing one thing well, for exactly the people it should and no one it shouldn’t.
Next in the series, the anchor takes on something with more weight to it — storage — and with it the first service where a wrong move risks actual data.