How I Took Over My Family's DNS with AdGuard Home

One night in November, a voice came from the kitchen: "Why does this WeChat mini-program keep spinning?" I was still looking at the DNS query curve in Grafana, thinking: probably another filter list just blocked some analytics domain. The real difficulty of running whole-house DNS was never the YAML or the upstream choice — it's whether the humans and the network policy can live together long-term.

First, get the house on the same page: what gets blocked, what doesn't

I spelled out the rules plainly. By default we block ads, tracking, and malicious domains; we do not block normal services, and we never block banks or payments. When something breaks, there are two escape hatches: the phone switches to a "bypass filtering" profile temporarily, or someone yells in WeChat and I go check the Query Log. I won't accept a silent failure where DNS is down for the whole house and nobody knows, and I won't accept being on call for every little thing like "SSH into the server room" on demand.

The query log retention window is deliberately short — just for troubleshooting, no long-term profiling. The admin panel is reachable only from the LAN or over VPN, never from the public internet. Those two rules do more than any "privacy statement": when the family knows what level of logging you're actually keeping, they're more willing to cooperate.

Which machine should run DNS

I ended up putting it in an LXC next to the soft router, with the fixed address 192.168.1.53. It doesn't compete with the main router for CPU, and it doesn't fight the NAS's media tasks for disk. Some people install AdGuard directly on OpenWrt to save a machine, but then a router upgrade, a firmware reflash, or a plugin conflict takes DNS down with it — the cost for the whole family is too high. Others run it in Docker on the NAS, and you get resolution hiccups whenever the NAS reboots or the storage pool scrubs. The feel is bad.

My conclusion is conservative: DNS is the network's directory service, so it should be independent, lightweight, and easy to restart. A container or LXC is plenty; 2 cores and 1 GB of RAM is overkill for a home. The main router's DHCP hands out AdGuard as the single DNS entry. People tell me to "add an ISP DNS as a backup" — that immediately bypasses the blocking. Devices start randomly asking the second resolver, ad domains work sometimes and not others, and troubleshooting gets more painful. I chose single point plus monitoring: process supervision, disk-not-full checks, an alert if port 53 stops answering, and scheduled config exports.

Picking upstreams, and how to stack lists

For upstreams I use DoH / DoT from a provider I trust in-country; stable latency beats "a cool global Anycast" any day. Whether DNSSEC can be enabled depends on whether the upstream supports it fully — forcing it on over an unstable upstream just manufactures random failures. And keep the division of labor clear: the upstream turns names into addresses, the filter lists decide "this name shouldn't be answered at all."

The list strategy is few but good. A base ad list plus one malicious-domain list is enough. Every extra list widens the false-positive blast radius, and a complaint about "the app won't open" costs far more than a few extra banners blocked. My cadence: add a list → watch the Query Log and family feedback for a week → then decide on the next batch. When something gets over-blocked, I add an allowlisted domain rather than deleting the whole list, and I note every allowlist entry so I don't wonder six months later why a domain was let through.

Hardware and the devices with hard-coded DNS

Phones and laptops take the DHCP-assigned resolver with zero fuss. The hard cases are smart TVs, some IoT gear, and the odd game console — they ship with 8.8.8.8 or the vendor's own DNS burned in. Two paths: DNAT traffic headed to port 53 on the firewall over to AdGuard, or give them their own VLAN and let them use public DNS. Be careful with hijacking — validate it on a test VLAN first, and make sure you don't drive the guest network and the printers crazy too. Some devices also use DoH to skip local port 53 entirely; then it's block known DoH endpoints at the firewall, or accept that this particular screen can't be blocked.

On the hardware side I didn't buy a dedicated box — the LXC is enough. But if your soft router is weak and you want heavy filtering anyway, a low-power always-on mini PC dedicated to DNS and NTP is a reasonable call: fixed address, clearly labeled, and never mixed in with the entertainment machine.

When the complaints come in

Standard flow: look at that device's recent blocked domains in the AdGuard query log → decide whether it's an ad SDK or a real business domain → allowlist and record the reason if it's business, or explain "that's a stats/tracking redirect" if it's an ad. The stats panel helps you phrase it well: it wasn't me being trigger-happy with your app, a rule in some list matched. Turning off filtering for one client temporarily is safer than a global kill switch — with a global one you'll forget to turn it back on.

If AdGuard dies, the whole house's resolution can go down with it — that's the price of the single point. Process supervision, config exports, and monitoring alerts are the floor. If you can, run two instances and hand out a primary and secondary DNS via DHCP; if you can't, at least guarantee "back up within five minutes." I fold the config export into my regular backup job, so a restore can stand up the same address on another LXC (or repoint DHCP) within half an hour. That's more real than talking about high availability.