This post was originally published on Medium.
You can find the original version here:
https://medium.com/@sidbathi/running-dns-is-easy-trusting-it-is-not-e5eec77b2d50
By the end of my last post, DNS in my home was working.
Pi-hole was up.
Ads were blocked.
The internet felt faster.
Everything looked fine.
And that was exactly the problem.
Because when I stepped back and actually thought about what was happening, I realised something uncomfortable:
DNS was running — but I didn’t really trust it.
Not the way I’d trust infrastructure that people depend on every day.
Control is not the same as ownership
At a glance, it felt like I was “running my own DNS”:
- Queries flowed through Pi-hole
- I had visibility into requests
- I could block, allow, and tweak behaviour
But under the hood, most DNS queries were still being forwarded elsewhere. I was filtering traffic, not resolving it. Trust was being outsourced.
If my upstream resolver lied, failed, or behaved unexpectedly, I had no real way of knowing — or proving it.
That distinction matters.
DNS sits at an unforgiving layer of the network. It’s invisible when it works, catastrophic when it doesn’t, and deeply sensitive from both a privacy and security perspective. If you’re going to run it yourself, you need to be honest about where trust actually lives.
That’s where things started to feel fragile.
Why forwarding DNS never felt “done”
Forwarding DNS is convenient. It’s also easy to forget what you’re implicitly trusting:
- External resolvers you don’t control
- Network paths you don’t see
- Policies you didn’t design
None of this is wrong. But it is a trade-off.
At this point, I wanted fewer assumptions — not better ones.
That led me to recursive resolution.
Unbound: fewer shortcuts, more responsibility
Adding Unbound wasn’t about performance or optimisation. It was about changing the trust model.
Instead of forwarding queries upstream, Unbound resolves them recursively, validating responses along the way. The resolver stops being a middleman and starts being the authority that decides what to trust.
The first time I realised my Raspberry Pi was now responsible for resolving the internet, it stopped feeling like a fun project.
A few things changed immediately:
- DNS resolution stayed inside my network for longer
- DNSSEC validation became explicit, not assumed
- Failure modes became clearer — and closer to home
It also increased complexity, and that part matters.
Running a recursive resolver means accepting more responsibility. Latency can increase slightly. Debugging becomes more subtle. There are more moving parts that can fail quietly.
But the mental model improved.
DNS stopped feeling like a feature and started feeling like infrastructure.
That shift changed how seriously I treated everything that came after.
Secure access is not “opening a port”
Once DNS became more critical, another question followed naturally:
How do I access and manage this safely when I’m not at home?
The obvious — and dangerous — answer is port forwarding. It works, and it also quietly turns internal services into public attack surfaces.
That’s when I introduced Tailscale.
Not because it’s trendy or “easy”, but because it forces a different way of thinking about access.
With Tailscale:
- Nothing is exposed publicly
- Access is identity-based, not network-based
- Devices authenticate to each other directly
- The Pi-hole admin interface stays private
Remote access stopped feeling risky.
I wasn’t punching holes in my router anymore. I was shrinking the blast radius.
This wasn’t about convenience. It was about removing entire classes of mistakes.
Exposure versus identity. One of these removes an entire category of risk.
The cost of doing this properly
It would be dishonest to pretend this simplified things.
Adding Unbound and Tailscale introduced:
- More dependencies
- More configuration surface
- More subtle failure modes
The system became safer — but also less forgiving.
That’s the trade-off real infrastructure always makes. Safety doesn’t come from fewer components. It comes from clearer boundaries and deliberate design.
What changed wasn’t just the setup.
It was how I thought about it.
A mental model of DNS ownership
A mental model, not a wiring diagram.
This isn’t an implementation diagram.
It’s a way of thinking about responsibility and trust.
What this unlocked (quietly)
After this phase, something shifted.
I wasn’t just blocking ads anymore. I was:
- Owning DNS resolution end-to-end
- Making trust decisions explicitly
- Accessing critical infrastructure securely, from anywhere
- Thinking about failure before it happened
The system still looked small. Still ran on a Raspberry Pi.
But the mindset had changed.
And that set the stage for the next lesson — one I didn’t see coming at the time:
Visibility is not awareness.
Dashboards don’t wake you up.
Alerts do.
That’s where things broke next.
What’s next
Hardening DNS solved one problem.
It quietly created another.
The system was safer — but still blind.
That’s where uptime, alerting, and observability enter the story.
Top comments (0)