DEV Community: Siddesh Bathi

I Could Block Ads. I Had No Idea What Else Was Happening.

Siddesh Bathi — Tue, 31 Mar 2026 08:37:55 +0000

By the end of my last post, the setup looked pretty solid.

Pi-hole blocking ads. Unbound resolving DNS privately. Tailscale keeping everything accessible without exposing anything publicly.

From the outside, the network looked healthy.

The problem was I had absolutely no idea what was actually going on inside it.

Pi-hole showed me DNS queries. That was it.

Bandwidth? No idea. Traffic patterns? No idea. Which devices were chatting at 2am without telling anyone? Absolutely no idea.

For someone who spends their working day talking about observability, visibility, and “you cannot manage what you cannot measure” — this was a bit embarrassing.

The Obvious Answer

Search for “Raspberry Pi network monitoring” and the internet will confidently point you at two things.

Prometheus. Grafana.

Rich dashboards. Beautiful graphs. The kind of setup that makes your home network feel like it deserves its own on-call rotation.

I genuinely considered both.

Then I did something that saved me a lot of pain.

I checked how much RAM they actually need.

Prometheus, even lightly configured, wants a meaningful chunk of memory to store and process metrics. Grafana adds more on top. Together they are designed for machines that have resources to spare.

The Raspberry Pi Zero 2W has 512 megabytes total. That is not a recommendation. That is the whole machine.

Pi-hole lives there. Unbound lives there. Tailscale lives there. The operating system lives there.

There is no spare capacity sitting around waiting to host a metrics pipeline.

Asking Prometheus and Grafana to run alongside everything else would have been like inviting two large house guests into a studio flat. Technically possible. Practically a disaster for everyone already living there.

So I asked a more honest question.

What Do I Actually Need?

Not “what would look impressive?”

What do I actually need to see?

The answer, when I was honest about it, was pretty simple.

I wanted to know what traffic was flowing through my network right now. I wanted to know how much bandwidth I was using over time. And I wanted to know which devices were actually on my network.

Three questions.

Three lightweight tools. One for each.

darkstat

darkstat watches your network interface passively and builds a picture of what is flowing through it.

It uses almost no resources. It serves a small web interface. It does not try to be anything more than what it is.

sudo apt install darkstat -y

Once running, the web interface lives at http://<your-pi-ip>:667. Nothing to configure. Just open it.

Getting it installed was easy. Getting it to actually run properly was a different story.

darkstat ships with an init script that was written before systemd became the standard. The two do not get along well. The service would start, report that everything was fine, and then quietly do nothing at all.

Port 667 stayed closed. The web interface never appeared. And systemd had no idea anything was wrong because as far as it was concerned, the job was done.

The fix was to stop trusting the init script entirely and write a proper systemd unit file instead. One that ran darkstat in the foreground, so systemd could actually keep track of it.

That one change fixed everything.

This is something I keep learning with older Linux tools. They were written in a different era. They make assumptions that no longer hold. When a service reports success but nothing is actually running, the culprit is usually somewhere in that gap between how the tool was designed and how the system expects it to behave.

vnstat
darkstat tells you what is happening right now.

vnstat tells you what happened over the last hour, day, week, and month.

It is the difference between glancing out the window and checking your weather history. Both are useful. They just answer different questions.

vnstat runs as a tiny background daemon, samples your network interface quietly, and keeps a running record of bandwidth usage over time.

sudo apt install vnstat -y

Once it has been collecting for a few minutes, these two commands become your best friends:

vnstat -i wlan0 -d   # daily breakdown
vnstat -i wlan0 -m   # monthly totals

The daily and monthly breakdowns became something I checked more than I expected.

There is something grounding about seeing actual numbers. Not estimates. Not assumptions. Just a record of what moved through the network and when.

One small surprise: vnstat automatically tracked both my main Wi-Fi interface and the Tailscale VPN interface separately. I had not asked it to. It just did. That turned out to be more useful than I anticipated, because now I could see VPN traffic independently from everything else.

nmap

The third question was the one I had been quietly avoiding.

Which devices are actually on my network?

I knew the ones I had deliberately connected. But modern homes are messier than that. Smart TVs. Printers that update themselves overnight. Devices from visitors that technically never left. Things that connect to Wi-Fi without making a sound about it.

sudo apt install nmap -y

Running a quick scan answered the question immediately.

sudo nmap -sn 192.168.*.*/24

The first time I did this, I counted more devices than I expected.

I thought I had about eight.

That is not a rounding error. That is a visibility problem.

Some I recognised straight away. Some took a moment. A couple made me walk around the house and think harder than felt entirely comfortable.

That last part is not paranoia. It is just what happens when you go from zero visibility to any visibility at all. You find things you did not know were there.

I set this up to run automatically every hour via cron and write results to a log file.

Now there is a timestamped record of every device that has appeared on my network, every hour of every day. If something new shows up at 3am, I will know about it. Eventually.

What This Actually Cost

After all three tools were running alongside Pi-hole, Unbound, and Tailscale, I checked the memory.

The combined overhead was under 10 megabytes.

To put that in perspective: a single Chrome tab uses more memory than this entire monitoring stack.

The Pi-hole kept running. Unbound kept resolving. Nothing noticed anything had changed.

That last part matters more than it might sound.

The Pi-hole is not optional. Every device in the house depends on it for DNS. If it struggles, the internet stops working for everyone. Everything else on this machine runs at the Pi-hole’s pleasure, not the other way around.

A monitoring stack that threatens the thing it is supposed to monitor is not a monitoring stack. It is a liability.

What Chagned?

Before this: DNS was visible. Everything else was dark.

After this: I could see live traffic. I had bandwidth history going back weeks. I knew every device on my network by IP and MAC address.

And I got there without adding anything that put meaningful load on a machine that was already doing important work.

The right tool for the constraints you actually have, rather than the constraints you wish you had, is not a glamorous engineering lesson. Nobody writes conference talks about it.

But it shows up in every system that actually keeps running.

What Is Next
Three tools. Three data sources. Three separate places to look.

The obvious next step was to pull all of that into one place.

So I built a small dashboard in Flask that brought everything together in a single page.

If you think “a dashboard sounds like a small project”, I admire your confidence.

It was not a small project.

That is next.

Running DNS Is Easy. Trusting It Is Not.

Siddesh Bathi — Wed, 04 Feb 2026 10:49:39 +0000

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.

The First Thing I Installed on My Raspberry Pi (and how it quietly broke my entire home internet)

Siddesh Bathi — Tue, 27 Jan 2026 09:07:00 +0000

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.

Preparing a Raspberry Pi Like a Real Server (Before Installing Anything)

Siddesh Bathi — Fri, 23 Jan 2026 09:53:24 +0000

Introduction

In my previous post, I wrote about why I enjoy running small pieces of infrastructure at home and pressure-testing ideas outside of work.
This post is where that thinking turns practical - and where I had to actively stop myself from installing everything on day one.

Before installing any services, I wanted to understand the Raspberry Pi in its most honest, unmodified state - a fresh operating system, minimal configuration, and no assumptions. The goal wasn't to make it useful yet, but to make it predictable.

I approached the Pi the same way I would a new Linux server. establish a clean baseline, observe how it behaves under default conditions, and understand where disk, memory, and network boundaries actually are.

Before diving into services, I want to document the baseline and mindset that shaped every decision that follows - including the exact steps and commands I ran to get there.

Nothing runs on this machine yet - and yes, that's a deliberate choice. Because the reliability of everything that comes later depends on the discipline applied at the start.

Before we start: prerequisites

Before setting anything up, this is what I used. Nothing fancy -just the basics needed to get a clean, predictable system up and running.

Hardware

Raspberry Pi Zero 2 W
32 GB microSD card
Power supply for the Raspberry Pi
Laptop or desktop (macOS / Linux / Windows)
microSD card reader (if your laptop doesn't have one)

Software

Raspberry Pi Imager
Raspberry Pi OS Lite (Debian Bookworm–based)

No fancy gear - just the essentials needed to get a Raspberry Pi off the ground.

Downloading Raspberry Pi OS and flashing the SD card

To prepare the operating system, I used Raspberry Pi Imager, the officially supported tool from the Raspberry Pi Foundation.
You can download it from:

https://www.raspberrypi.com/software/

Here is how the website looks like!

After installing Raspberry Pi Imager on my laptop, I followed these steps:

Insert the microSD card into the laptop
Open Raspberry Pi Imager
Select Raspberry Pi OS (Other) -> Raspberry Pi OS (Legacy, 64-bit) Lite
Choose the SD card as the target storage

Before writing the image, I opened the advanced options and configured:

SSH (enabled)
Username and password
Wi-Fi SSID and password
Locale and timezone

This allows the Raspberry Pi to boot and be reachable over the network immediately - no monitor, keyboard, or desk gymnastics required.

Once configured, I flashed the OS to the SD card and safely ejected it.

Choosing the boring OS on purpose - less UI, fewer surprises later.

At the time of setup, this option installs a Debian Bookworm–based 64-bit Raspberry Pi OS Lite image.

Pre-configuring SSH and Wi-Fi to enable a fully headless first boot.

The rule I set before installing anything
Before touching any services, I set a simple rule for myself:
This Raspberry Pi would be treated like a server, not a project board.

It's tempting to install DNS filters, VPNs, dashboards, and security tools immediately - especially when every tutorial on the internet starts with "just install this first." But that approach often hides problems rather than solving them.

I wanted to understand how this system behaves before it does anything useful:

How much disk space is actually available?
How tight is memory?
What does a normal idle state look like?

By delaying installations, I could observe the Pi in a clean state and establish a baseline I could trust. That baseline becomes the reference point for every change that follows.

In practice, this meant resisting progress that only looked like progress - and choosing predictability over speed, even when speed felt more satisfying.

First boot and accessing the Raspberry Pi

With the SD card prepared, I inserted it into the Raspberry Pi, connected power, and let it boot.

Since SSH was already enabled, I connected from my laptop using the pattern below:

ssh <username>@<hostname-or-ip>

In my setup, the username is sid and the hostname is pihole.local.

Once logged in, I confirmed I had stable access and landed in a normal Linux shell.

Successful SSH access to the Raspberry Pi after first boot.

Establishing a baseline I could trust

Before installing anything, I wanted a clear picture of what this Raspberry Pi looked like in a known-good, idle state.

The first step was updating the system - not because it's exciting, but because debugging problems on an outdated OS is even less exciting.

sudo apt update
sudo apt upgrade -y

Once updated, I started checking the basics - not to optimise anything yet, but to understand the constraints I was working within.

Disk usage

df -h

This shows how storage is laid out and how much space is genuinely available on a fresh install. On small devices, storage fills up faster than expected, so this becomes an important reference point.

Disk layout and available storage on a Raspberry Pi OS installation.

Memory availability

free -m

This gives a clear picture of RAM and swap usage before any background services are installed. Whatever runs later will eat into these numbers - so this becomes my baseline.

Memory and swap usage at idle

At this point, nothing useful was running - but I now had something more important than features: a baseline I could trust.

From here on, every change could be measured. If disk usage spikes, memory tightens, or latency appears later, I'll know exactly when - and why - it happened.

CPU (identity, not usage)

lscpu

This confirms the system is running on a 64-bit ARM architecture (aarch64) with a small number of CPU cores - exactly what you'd expect from a Raspberry Pi Zero 2 W.

At this stage, I'm not interested in how busy the CPU is, only in what kind of CPU I'm working with. Actual usage only becomes meaningful once services are running.

What I deliberately chose not to install (yet)

At this stage, it would have been very easy to start installing services - and I had to consciously not do that.

DNS filtering, secure remote access, monitoring, and hardening were all already on my list. But I deliberately held back.

Installing services before understanding the baseline only creates noise. When something breaks later, it becomes difficult to tell whether the issue lies with the service itself or with assumptions made earlier.

By stopping here, I kept the system in a known, explainable state - no background daemons doing work I hadn't measured, and no configuration drift I couldn't account for.

This wasn't a delay. It was a checkpoint.
This was the point where I closed the terminal and walked away - on purpose.

Closing

In the next post, I'll start adding the first real service to this system - DNS.
With a clean baseline in place, it becomes much easier to see what actually changes once something starts running.
That's where things begin to get interesting.

Final note

Screenshots in this post are taken from a real, already running system.
Your output may differ depending on hardware, storage size, and usage - and that's expected.

What a Tiny Raspberry Pi Taught Me About DNS, Privacy, and Control at Home

Siddesh Bathi — Mon, 19 Jan 2026 18:58:05 +0000

Originally published on Medium. Link to medium post - What a Tiny Raspberry Pi Taught Me About DNS, Privacy, and Control at Home

Most people never think about DNS.

It’s one of those things that quietly works in the background — like plumbing.
Until one day it doesn’t… and suddenly nothing on the internet makes sense.

As a Cloud Engineer, I spend a lot of time thinking about systems at organisation scale.
But at home, I realised something ironic — I was blindly trusting my ISP for something as fundamental as DNS, without visibility, without control, and without much thought.

This blog is about how a tiny Raspberry Pi quietly became my practice ground for real infrastructure ideas — without production incidents, without pressure, and without angry users.

This is not a polished success story.
It’s the beginning of a learning journey.

Why I Needed a Raspberry Pi at Home?

I didn’t start this project because I was bored.
And I definitely didn’t start it just to block ads (that was a nice side effect).

What bothered me was this:

Ads everywhere
Tracking everywhere
DNS requests happening silently
Zero visibility into where those requests were going
DNS is the first step of the internet.
Every website, every app, every API call starts there.

At work, we talk about security, observability, trust boundaries, and reliability.
At home, I had none of that.

So instead of spinning up another cloud VM, I decided to bring those ideas down to home scale — using something small, cheap, and always on.

That’s when the Raspberry Pi made sense.

Not as a toy.
But as a tiny piece of infrastructure that other devices would depend on.

Why Raspberry Pi Zero 2W (Not Raspberry Pi 5)?

When people hear “Raspberry Pi”, the conversation often jumps straight to performance.

“Why not just get a Raspberry Pi 5?”

Fair question — but the wrong starting point.

I intentionally chose the Raspberry Pi Zero 2W, and that decision shaped the entire learning experience.

The Zero 2W is:

Cheap
Silent
Extremely low power
And very limited And that’s exactly why it’s such a good teacher.

At work, when something is slow, we add resources.
At home, this Pi politely says: no.

It forces you to:

Think before installing things
Understand what each service is doing
Respect CPU and memory constraints

You don’t need a Ferrari to learn driving.
You need a small car, narrow roads, and a few mistakes you’ll remember forever.

This Pi gave me all three.

Cost Breakdown (Keeping It Honest)

This project didn’t start with a shopping spree.

All of this runs on hardware that cost roughly £25 — cheaper than most monthly cloud bills.

It needed:

One Raspberry Pi Zero 2W
One SD card — 32GB recommended.
One power adapter
Laptop (of course 😄) , don’t bother about Mac or Windows.

That’s it.

No rack.
No switch.
No cloud bill quietly judging you at the end of the month.

For a device that runs 24/7, the power cost is almost negligible.
The learning return, on the other hand, shows up every single day.

At a high level, a Raspberry Pi sits between my home devices and the internet, handling DNS requests centrally.

First Service: Pi-hole

The first service I installed was Pi-hole.

Not because it’s fancy — but because it provides immediate, visible value.

Every device on your network constantly asks:

“Where is this website?”

Pi-hole sits in the middle and calmly replies:

“Sure”
“Okay”
“Absolutely not, that’s an ad tracker”
And it does this before ads even get a chance to load.

This happens at the DNS level — not in a browser trying its best to block things.

The result?

Cleaner browsing
Faster apps
And the quiet satisfaction of watching ad counters go up

At this point, the project stopped being “just learning” and started being genuinely useful.

Pi-hole dashboard showing DNS queries and blocked domains across my home network.

Making It Accessible Anywhere: Tailscale

One small problem remained.

The Raspberry Pi lives at home.
I don’t.

Port forwarding was an option — a bad one.

Instead, I used Tailscale, which creates a private, encrypted network between my devices.

No public IP exposure
No firewall gymnastics
No “hope this is secure” feeling

Just private access, the way it should be.

This made the Pi feel less like a local gadget and more like a real, managed system.

Improving Privacy with Unbound
Blocking ads was great.
But I still wanted to know where my DNS queries were going.

By default, many setups forward DNS to public resolvers.
That works — but it’s still outsourcing trust.

Adding Unbound turned the Raspberry Pi into a recursive DNS resolver:

It talks directly to root servers
It builds trust step by step
It reduces dependency on third parties This is where the setup stopped feeling like a hobby and started feeling like real infrastructure, just smaller.

Proof That It Works

This is where theory turns into confidence.

I could now actually see:

Total DNS queries
Ads being blocked
Traffic patterns across devices
DNS was no longer invisible.

And that visibility alone changed how I thought about my home network.

Screenshot without Pi-hole
(using my phone without network-level blocking)

Screenshot with Pi-hole enabled
(using my home DNS setup)
The difference was noticeable immediately.

Closing Thoughts

At this point:

DNS was running reliably at home
Ads were being blocked across devices
Privacy was improved

And this tiny Raspberry Pi had become an always-on system I could learn from.
Nothing here was enterprise-scale — and that was the point.

This was about practicing real ideas safely, at home, without breaking production.

There’s still a lot more to explore.
But for now, this was a solid foundation.

If you want to build this exact setup yourself, the next post will walk through the step-by-step installation.