Why DNS: the one question every device asks first
Before your TV, phone, or doorbell can send a single byte to a tracker, it has to ask one question: what is the address of that server? That question is DNS, and by default your router hands it to your ISP, who answers every one of them and keeps the list.
HiveNet puts a small computer of mine in front of that question. Every device on the network asks the Pi instead. If the name belongs to an ad network or a tracker, the Pi answers with a dead address and the request goes nowhere. If it is a real site, the Pi asks an encrypted upstream resolver and passes the answer back.
Why it matters
This is network-wide. Smart TVs, guest phones, cameras, the things you cannot install a blocker on, all get covered because they all ask the same question. No subscription, no cloud account, no company in the middle.
The build: a Pi 5 and AdGuard Home
The hardware is a Raspberry Pi 5, a microSD card, its power supply, and an ethernet cable to the router. Wired, not Wi-Fi; DNS is the thing everything else waits on, so it does not get to drop.
Flash Raspberry Pi OS Lite, 64-bit with the Imager. Set the hostname to hivenet, enable SSH, and add your public key at flash time so you never type a password at it. Boot it, find it on the network, and connect.
The wizard takes a minute: listen on all interfaces, DNS on port 53, web UI on port 80, create an admin user. Accept the default blocklists. From a blank card to a working resolver was about 20 minutes, and that includes the apt upgrade.
Why it matters
Everything the Pi does lives in one file, /opt/AdGuardHome/AdGuardHome.yaml. Back that file up and a dead SD card is a 20 minute rebuild, not a lost weekend.
Encrypted upstreams: the Pi asks two resolvers, over HTTPS
Blocking trackers is half the job. The other half is who answers the questions the Pi cannot answer itself. Left at defaults, that is still your ISP, in plain text. I point HiveNet at two privacy-focused resolvers over DNS over HTTPS and let it race them.
Parallel mode sends each question to both and takes the first answer, so two providers cost no latency. The bootstrap entry is the one plain DNS server the Pi uses once, to learn the addresses of the encrypted ones. Measured from a laptop on the network, lookups average around 14 ms.
Why it matters
Two independent upstreams means one provider having a bad day does not take your house offline. Encryption means the coffee shop next door and your ISP see connections to a resolver, not the list of every site you visit.
The cutover: point the router at the Pi, and know the way back
First, give the Pi a fixed address. In your router's DHCP settings, reserve one for the Pi's MAC address so it never moves. Mine is 192.168.1.53, easy to remember because 53 is the DNS port.
Test it on one machine before the whole house. Set that laptop's DNS to the Pi by hand, browse for an hour, and watch the query log fill up. When ads vanish and nothing you need breaks, go to the router's internet settings and set both the primary and secondary DNS to the Pi. If you leave the secondary pointing at the ISP, some devices will quietly use it and leak around the whole setup.
Why it matters
When DNS is down, the internet is down for everyone in the house, and they will not care that it is a fun project. The rollback is one router setting. Knowing that step cold is what makes it safe to run this at home.
Living with it: blocklists, logs, and the morning report
Leave the blocklists at defaults for the first week. Overblocking is the failure mode that kills this project: one broken login page and someone in the house wants it gone. Earn trust first, tune later.
Shorten the query log. AdGuard keeps 90 days by default. I cut it to 7. The log is a record of every site every person in the house visited, and it lives on an SD card that wears out from writes. Less of it is better on both counts.
Automate the check-in. A short script runs from cron at 8 AM, authenticates to the AdGuard API as a dedicated read-only reporter user, pulls the day's stats, and emails a summary: total queries, how many were blocked, the top blocked domains, average response time. AdGuard has no real role separation, so the separate account buys you auditability and a password you can revoke, not less privilege. Know that going in.
Expect some devices to cheat. Some smart TVs and cameras hardcode Google's 8.8.8.8 and skip the router's DNS entirely. They will not show up in your query log, and they are not being filtered. The fix is a firewall rule that redirects all outbound port 53 to the Pi, which most consumer routers cannot do. Mine cannot. That is the next project, not a reason to skip this one.
Why it matters
The first version of HiveNet is done in an evening. The version that survives in a real house is the one with conservative blocklists, a short log, a rollback plan, and a morning email that tells you it is still alive.
Your HiveNet checklist
Do these in order and you end up with a resolver you can trust, and a house that never notices when you work on it.
Revisit this list when you change routers or add a batch of new devices. A completed checklist records your work, not a security audit.
The next field note.
Straight to your inbox.
The next HiveNet build is the firewall rule that catches the devices that cheat. Drop your email and I'll send it when it's live. One message, no spam, and you can reply to it. Or just follow on Instagram.