Category filtering goes on for a whole flat one evening, quietly, without anybody being told. The first casualty is almost always a school portal, which loads a worksheet viewer from a domain one of the lists decided was a tracker, so a homework submission fails at ten at night. What happens next is the more instructive half: the teenager shrugs, switches to mobile data, and finishes the work in four minutes. Both of those point at one mistake. A household’s internet is not a technical problem to be solved on a Raspberry Pi, it is an arrangement between people who live together, and an arrangement nobody agreed to is one they will quietly route around. Filtering that was discussed out loud, and aimed narrowly at tracking, malicious hosts and accidents rather than at everything, is easier to live with and considerably more useful.
agree the rules before you touch the router
The conversation costs you one evening and saves months of quiet friction. Not a lecture, a negotiation, with everyone who uses the connection in the room, including the teenager who will absolutely notice changes you did not mention.
Four things worth settling first. What are we trying to prevent, stated concretely rather than as “bad stuff”? Which of that is the network’s job and which is a conversation? Who do you tell when something legitimate breaks? And what will not be watched, so filtering does not become surveillance of the people you live with?
Announce what you changed, too. Secret filtering produces a household that assumes the connection is unreliable and a child who learns to route around problems quietly. A filter everyone knows about produces the behaviour you want: somebody tells you when a site breaks.
what dns filtering can and cannot do
Be precise about the tool, because overestimating it is how families end up with a false sense of safety. A filtering resolver answers name lookups. It does not read pages, inspect content, or understand context. It refuses a name or it does not.
| Goal | DNS filtering | Better tool |
|---|---|---|
| Block known adult and gambling domains | Works well for the big, catalogued ones | Add device-level controls for a young child |
| Stop tracking and telemetry across all devices | Good at this | Nothing simpler exists |
| Keep malicious and phishing hosts unreachable | Strongest use of all | Plus a browser blocker on laptops |
| Filter one video on a platform you allow | Cannot see inside a domain | Platform-level restricted mode |
| Limit screen time | Wrong layer entirely | Router schedules or per-device settings |
| Know what a child is going through | No, and it should not try | A conversation |
The bottom row is the one I would underline. A query log tells you that a domain was asked for by a device. It does not tell you why, who was holding the phone, or whether the child was worried about what they found. Treating DNS logs as insight into a young person’s life is both technically unsound and a fast way to lose their trust.
one policy for the house, or one per device
The simplest arrangement is a single filtering resolver handed out by the router’s DHCP, so every device gets the same treatment. It takes ten minutes and covers the television, the speaker, the tablet nobody remembers buying. The drawback is obvious: your six-year-old’s rules now apply to your mother’s phone.
Per-device policy is the better answer once children differ in age. Both Pi-hole and AdGuard Home can group clients by IP or MAC address and apply different lists to each group. Give the kids’ tablets a stricter group, leave the adults’ phones on tracker and malware filtering only, and put the smart TV in a group of its own because it deserves it.
- Reserve fixed addresses in your router’s DHCP for the devices you want to treat differently, or groups will drift as leases change.
- Name every client in the filter’s interface. “android-3f2b” tells you nothing at eleven at night.
- Keep the default group permissive and the strict groups explicit, so a new device joining the network does not silently inherit the tightest rules.
AdGuard Home handles per-client rules more comfortably out of the box, which is one of the few places the two tools differ; I set out the rest in AdGuard Home versus Pi-hole. Either way, the router side of the work is the same, and my Pi-hole setup guide for Indian homes covers the DHCP quirks on the routers most ISPs here supply.
devices that bring their own resolver
Here a tidy plan meets reality. Plenty of devices ignore what DHCP tells them: smart TVs with a public resolver compiled in, apps carrying their own encrypted DNS, Chrome using its own secure DNS regardless of your network. Your policy is advisory unless you do something about it.
The usual countermeasure is to redirect plain DNS leaving the LAN back to your own filter, so a hardcoded resolver address gets answered by you anyway.
# Generic Linux router with iptables. 192.168.1.10 = filter, br-lan = LAN bridge.
# Exclude the filter's own upstream queries, or they loop back to it.
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 \
! -s 192.168.1.10 ! -d 192.168.1.10 -j DNAT --to-destination 192.168.1.10:53
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 \
! -s 192.168.1.10 ! -d 192.168.1.10 -j DNAT --to-destination 192.168.1.10:53
# The filter is on the same subnet, so rewrite the source as well,
# or its replies bypass the router and are dropped by the client.
iptables -t nat -A POSTROUTING -o br-lan -p udp -d 192.168.1.10 --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -o br-lan -p tcp -d 192.168.1.10 --dport 53 -j MASQUERADE
# Optional: refuse DNS-over-TLS so devices fall back to plain 53
iptables -A FORWARD -i br-lan -p tcp --dport 853 -j REJECTTwo catches. Redirected queries now reach the filter from the router’s address, so per-device groups cannot tell those particular devices apart. And on OpenWrt 22.03 or newer the firewall is nftables-based (firewall4), so create this as a port-forward/redirect rule in LuCI or /etc/config/firewall rather than typing iptables commands, which also do not survive a reboot.
DNS-over-HTTPS is harder, because it looks like ordinary web traffic on port 443. The practical approach is a blocklist of known encrypted-DNS endpoints, which both filters can consume, plus turning the setting off in the browsers you control. Be honest about the limits: this is maintenance, not a solved problem, and a new endpoint appears whenever you stop paying attention.
Before you reject port 853 across the board, remember that an adult in the house may be using it deliberately on their phone, as in my notes on Android Private DNS. Exempt their device or expect a puzzled question.
safe search, which dns does handle well
This is the one content control that fits the DNS layer properly. The big search engines publish alternative hostnames that always return filtered results, so you point the normal name at the restricted one and every device on the network gets it without installing anything.
# AdGuard Home: switch on Safe Search in its settings (per client if needed).
# Pi-hole v6 has no Safe Search switch, and a file in /etc/dnsmasq.d is
# ignored unless misc.etc_dnsmasq_d is enabled. dnsmasq's cname= also only
# works when the target is a name it already knows locally. Instead, look
# up the restricted addresses...
dig +short forcesafesearch.google.com
dig +short restrictmoderate.youtube.com
# ...and add them in Pi-hole under Local DNS -> DNS Records:
# Google: www.google.com, www.google.co.in (and any other Google
# country domain your family uses) -> forcesafesearch address
# YouTube: www.youtube.com, m.youtube.com, youtubei.googleapis.com,
# youtube.googleapis.com, www.youtube-nocookie.com
# -> restrictmoderate address
# Re-check those addresses occasionally; they are Google's to change.
# Bing (strict.bing.com) and DuckDuckGo (safe.duckduckgo.com) publish
# equivalents; confirm against their current help pages before adding.AdGuard Home’s switch is less fiddly and harder to get wrong. Either way, verify it afterwards rather than assuming: Google’s own check is google.com/safesearch. And tell the family it is on. A teenager who discovers restricted results by accident will assume worse things are happening than actually are.
time limits belong on the router
People try to build bedtime rules into their DNS filter, and it goes badly. Refusing names after ten o’clock produces applications that retry forever, notifications that pile up, and a device that behaves strangely rather than obviously being off.
Do it at the layer that owns access. Many routers can cut a device’s connectivity by MAC address between set hours; check whether your Airtel or JioFiber router has a schedule or parental-control page, and if it does not, OpenWrt does it cleanly with a firewall rule. When the Wi-Fi is off it is off, and nobody spends twenty minutes wondering why one app is broken.
A practical point about Indian homes: a scheduled cut-off that also kills your own evening work is a rule that will be switched off within a week. Apply the schedule to specific devices, never the whole network.
privacy for the people you live with
An older child has a reasonable expectation of privacy, and a filter logging every lookup gives you far more visibility than you need. Set retention short and do not browse the log out of curiosity. It exists to explain a breakage or find a chatty appliance.
- Keep the admin interface off the open internet and behind a real password. It holds the household’s browsing history.
- Shorten log retention to days rather than months, or enable the anonymous logging mode both tools offer.
- Tell everyone what is logged and for how long. Say it once, plainly, and stick to it.
- Never use the log to start an argument. If you would not say “I looked at your browsing”, do not look.
Reading a query log well is a skill in itself, and mostly a diagnostic one. What it does and does not reveal is covered in reading your Pi-hole query log, including the part where the chattiest device in the house turns out to be a television.
a determined teenager will get around this
Say it out loud, because pretending otherwise makes the filter look like a challenge. Mobile data sits outside your network. A friend’s hotspot is one tap away. A VPN app installs in two minutes, and nothing at your router stops an encrypted tunnel without breaking legitimate work.
What filtering does achieve is still worth having. It removes accidental exposure, the mistyped domain and the malicious advert on a page nobody sought out. It cuts tracking on devices with no settings of their own. It makes the default path the safer one. It does not substitute for knowing what your children are dealing with, and any product claiming otherwise is selling comfort.
One more thing to keep in view. Filtering advertising for the whole house also affects the news sites, recipe pages and video channels your family reads, and those are funded by ads. Keeping the ones they value on an allowlist while still refusing trackers and malicious hosts is a reasonable, consistent choice, and it makes the filter much easier to justify at the dinner table.
FAQ
is a public family resolver enough, or do i need my own box?
For many households a public filtering resolver with a family profile is plenty, with no hardware to maintain. You give up per-device policy and your own allowlist, and the operator sees your lookups. Run your own if you want per-child rules, and if you are willing to be the person who fixes it on a Sunday.
what about the smart tv and the voice speaker?
They are why network-level filtering is worth the effort, since neither can run anything you install. Expect the television to be the chattiest device you own, and expect some of its telemetry domains to be worth refusing. Test the apps your family uses afterwards; occasionally a blocked endpoint makes a TV app sulk, and you allowlist that one entry.
a school site stopped working. what do i check first?
Open the query log, filter by that device’s address, and reload the page. The blocked entry will usually appear in the seconds around the failure, and it is often a content-delivery or analytics domain that the portal depends on. Allowlist that single domain, not a wildcard, and note down why you did it. If it takes more than three entries, remove the list that caused it.
should i tell the kids what is filtered?
Yes, in age-appropriate terms. For a small child, “the internet here has a filter so rubbish does not get through” is enough. For a teenager, be specific about what is blocked and what is logged, because they will find out anyway and the discovery is worse than the disclosure. Honesty also buys you the thing you need most: being told when something legitimate breaks.
The technical part of this takes an evening; the agreement takes one conversation and holds up far longer. Filter for accidents and tracking, put time limits on the router, and keep the log short and boring.
Update history: replaced the safe-search setup, which Pi-hole v6 ignores, and corrected the DNS-redirect rules so the filter’s own queries no longer loop back to it.
Sources
- AdGuard Home configuration wiki — per-client settings, safe search options and logging controls.
- Pi-hole gravity database documentation — how lists and allowlist entries are applied, including per-group assignment.
- RFC 8484 — DNS Queries over HTTPS — why an application can resolve names without your network’s involvement.