Originally published on Medium. Link to medium post - The First Thing I Installed on My Raspberry Pi (and how it quietly broke my entire home internet)
In my previous post, I talked about getting my Raspberry Pi into a clean, predictable state - fresh OS, minimal configuration, no assumptions.
At that point, the Pi was sitting there quietly.
Healthy. Boring. Useless.
Which meant it was time to ruin that peace.
The obvious next question was:
What should be the first real project?
Not the flashiest project.
Not the most impressive one.
But the one that would force me to think like an operator instead of a tinkerer.
That's how I ended up choosing Pi-hole.
Why Pi-hole? (And why this wasn't about ads)
Let's get one thing out of the way.
- I didn't pick Pi-hole because:
- I hate ads (okay, I do)
- I wanted a pretty dashboard
- I needed a "home lab starter project"
I picked Pi-hole because it sits at the most unforgiving layer of the network.
DNS.
Quick one-liner for context:
DNS (Domain Name System) is what turns google.com into an IP address your machine can actually talk to.
When DNS works, nobody thinks about it.
When DNS breaks, everyone thinks the internet is down.
Perfect.
If I was going to run infrastructure at home, I wanted something that:
- everything depends on
- fails loudly
- teaches lessons fast
DNS ticks all the boxes.
Installing Pi-hole (the calm before the storm)
Installing Pi-hole itself is… almost suspiciously easy:
curl -sSL https://install.pi-hole.net | bash
If this were a tutorial blog, I'd now tell you what options to click.
This is not that blog.
What mattered to me wasn't how fast it installed, but what changed in the system because of it.
First thing I checked:
systemctl status pihole-FTL
Good - it's a service.
Not a script. Not a process I have to babysit.
Next, I checked what it was actually listening on:
sudo ss -lntp | grep -E ':(53|80)'
That's when it really sank in.
Port 53 - DNS - now belonged to this Raspberry Pi.
This wasn't a "project" anymore.
This was a responsibility.
Testing Pi-hole: "It works!" (famous last words)
To test Pi-hole, I pointed a client device to use the Pi as its DNS server and ran:
nslookup google.com
On the Pi itself:
dig google.com @127.0.0.1
Everything resolved.
Queries showed up in the dashboard.
Ads were getting blocked.
🎉 Success, right?
Well… yes. Technically.
But this was still safe success.
Nothing depended on it yet.
So I did the thing that turns experiments into infrastructure:
I tried to route my home network through it.
The original plan (aka: how it should have worked)
The plan was clean. Elegant. Architecturally sound.
"Configure DNS at the router level so every device uses Pi-hole automatically."
No per-device config.
One place to control everything.
Pure network-level enforcement.
If you've ever designed systems, you already know what comes next.
Reality check: ISP routers don't care about your architecture
I'm using a SKY router.
And here's the short version:
You don't fully control DNS on it.
Some settings look configurable.
Some partially apply.
Some get overridden silently.
The result was… confusing.
- Some devices used Pi-hole
- Some ignored it completely
- Phones behaved differently from laptops
- VPN usage changed things again
At first, this felt like Pi-hole was flaky.
It wasn't.
This was my first big lesson:
Your design can be correct and still be impossible to enforce.
Consumer ISP hardware has opinions.
And those opinions outrank yours.
Symptoms that made me doubt my sanity
Things I observed:
- Pi-hole dashboard showing fewer queries than expected
- Ads blocked on one device but not another
- Same phone behaving differently on Wi-Fi vs mobile data
- Turning VPN on/off changing DNS behaviour
This is the point where many people rage-quit.
Instead, I slowed down and asked a better question:
"Which DNS server is this device actually using right now?"
That question alone saved hours.
The pivot: choosing pragmatism over purity
After enough fighting with the router, I made a decision.
I stopped trying to force DNS centrally and switched to manual DNS configuration per device.
Yes, it's less elegant.
Yes, it's more work.
But it has huge advantages:
- explicit behaviour
- predictable results
- easy debugging
Each device now pointed directly to the Raspberry Pi's IP as its DNS server.
Suddenly:
- behaviour made sense
- Pi-hole statistics matched reality
- debugging became sane again
This was a mindset shift more than a technical one:
Early infrastructure benefits more from visibility than from architectural perfection.
What this project actually taught me
Before this, DNS was background noise.
After running Pi-hole:
- DNS became a dependency chain
- a failure domain
- a trust boundary
- the first thing to verify when "the internet is broken"
My troubleshooting style changed too.
Instead of guessing, I verified.
Instead of restarting everything, I checked ownership:
sudo ss -lntp | grep :53
That single command tells you:
- who owns DNS
- what's listening
- whether your assumptions are wrong
(Spoiler: they usually are.)
Why Pi-hole was the right first project
This project mattered because:
- it introduced real consequences
- it exposed real-world constraints
- it forced trade-offs
- it changed how I think about "control"
Most importantly, it turned the Raspberry Pi into something other devices depend on.
That's the moment a system stops being a hobby.
What's next
At this point, DNS was running - but it was fragile.
Which led to the next uncomfortable question:
How do I secure this?
And how do I access it safely when I'm not at home?
That's where DNS hardening and secure access come in - Unbound, Tailscale, and a whole new set of lessons.
That's the next post.
Top comments (0)