DNS filtering for schools and families

Every classroom and every living room has the same problem now: a pile of devices, most of which you don't fully control. The school-managed laptop is easy. The student's own phone on the Wi-Fi, the smart TV, the games console, the e-reader, the visiting cousin's tablet — those refuse to take your endpoint agent, your browser extension, or your carefully crafted profile. You can't install software on a fridge. And yet the fridge talks to the internet.

This is precisely why DNS filtering earns its keep in schools and homes. Almost everything that connects has to ask a resolver "where is this name?" before it can fetch anything. If you own that answer, you have a single, device-agnostic control point that covers the managed and the unmanageable alike — without touching the device. The catch is that DNS filtering is not magic, it has well-understood limits and a couple of genuinely confusing failure modes. This guide walks through what to turn on, how to verify it, and where it stops.

Why the DNS layer is the right altitude

Content filtering can live in several places: on the device, in the browser, on a transparent web proxy, or at the resolver. Each layer sees a different slice of reality and carries a different cost. The resolver layer is the only one that is both network-wide and device-blind — it doesn't care what operating system the client runs, whether you can manage it, or whether the traffic is HTTPS-encrypted (which, today, it almost always is). A web proxy that wants to inspect content has to break TLS, which means deploying a root certificate to every device — bringing us straight back to the devices you couldn't touch in the first place.

DNS filtering sidesteps that entirely. The resolver makes its decision on the name being requested, before any connection is opened, so it never needs to see — or decrypt — the page content. The trade-off is bluntness: DNS works at the domain granularity, so you block example-bad-site.com, not one offending video on an otherwise allowed platform. For category and adult filtering that bluntness is usually a feature, not a bug.

Category and adult filtering

The workhorse of any school or family deployment is category-based blocking. Instead of maintaining your own list of bad domains, you enable curated categories — adult content, gambling, drugs, weapons, hate, malware, phishing — each backed by a maintained mapping of domains to categories. UnveilDNS draws on curated threat-intelligence and content feeds for this, and exposes the categories as simple toggles so you switch on what your policy requires and leave the rest off.

Adult/parental filtering deserves a special mention because it has two complementary implementations, and understanding both helps you reason about what's actually happening:

The first is a list you own and can adjust. The second is a service you forward queries to that already enforces a family-safe policy. Combining them gives defence in depth: the upstream catches things your list misses, and your list catches things the upstream's policy doesn't cover. The important consequence — and the source of one of the most common support tickets — is that two different layers can be rewriting the same answer. Keep that in mind; it returns below.

SafeSearch enforcement

Category blocking handles the obvious bad domains. SafeSearch handles a subtler problem: a search engine that you want to allow, which will happily return explicit images and results unless you force its safe mode. You can't block the search engine — students need it — so instead you compel its SafeSearch variant.

The major search engines publish dedicated SafeSearch hostnames, and the resolver enforces safe mode by rewriting the search domain to point at that safe-mode address (or by appending the provider's safe-search signal). Because it's done at the DNS layer, it applies to every device on the network with no per-browser configuration. A managed laptop and an unmanaged phone both land on the safe-mode endpoint.

SafeSearch enforcement is the clearest example of DNS filtering doing something an outright block can't: it keeps a useful service available while constraining what it's allowed to return.

Enable SafeSearch globally for school networks and for the children's group at home; you'll typically leave it off for staff or adult devices. Which brings us to the most famous SafeSearch puzzle of all.

The two faces of YouTube Restricted Mode

Sooner or later someone reports that YouTube is hiding comments or showing "Restricted Mode has hidden this video," and you didn't knowingly turn that on. There are two completely independent causes, and the fix for one does nothing for the other. Diagnosing which one is active first will save you a frustrating afternoon.

Cause 1 — an upstream is rewriting the answer

If you forward queries to a family-filtering upstream, that upstream may resolve YouTube's hostnames to YouTube's own restricted-mode addresses. Your resolver never made a SafeSearch decision; it simply passed along an answer that arrived already rewritten. The video API that controls comments is the one most often affected.

Cause 2 — your resolver is enforcing SafeSearch itself

If your resolver's SafeSearch has a YouTube option enabled, the resolver rewrites the answer locally — regardless of what the upstream returned. This is a deliberate policy you set, but it's easy to forget it's on, especially when it was enabled as part of a "safe browsing" bundle.

Telling them apart with two queries

The clean diagnosis compares what your resolver returns against what a neutral public resolver returns. Point the second query at any plain public resolver — a placeholder address is used here:

# 1. What does YOUR resolver return for the comments API?
dig @127.0.0.1 youtubei.googleapis.com +short

# 2. What does a neutral public resolver return?
dig @203.0.113.10 youtubei.googleapis.com +short

Now read the result:

For Cause 1, the targeted fix is to forward just the affected YouTube hostnames through a non-family resolver while leaving everything else on the family upstream — UnveilDNS lets you scope upstream rules to specific domains for exactly this. Resist the temptation to whitelist the whole shared API domain; you'd drag every service that shares it back through unfiltered DNS.

Closing the bypass routes

DNS filtering only works while devices actually use your resolver. A motivated teenager — or a well-meaning app vendor — can route around it, and a serious deployment has to close those doors deliberately.

• Encrypted DNS on the device. Modern browsers and operating systems can speak DNS-over-HTTPS (RFC 8484) or DNS-over-TLS (RFC 7858) directly to a third-party resolver, tunnelling right past your network DNS. Vendors generally honour a network signal that says "this network manages DNS, don't auto-enable your own" — block the small set of probe/canary domains those features check, and the device falls back to your resolver. UnveilDNS ships this as a toggle so you don't have to maintain the list by hand.
• Hard-coded resolver addresses. Some devices and apps point straight at a fixed public resolver IP on port 53, ignoring whatever your DHCP hands out. The fix is at the firewall, not DNS: redirect or block outbound port 53 (and 853 for DoT) to anything except your resolver, so all plaintext DNS is forced through you.
• Personal hotspots and cellular. A phone on its own mobile data isn't on your network at all. DNS filtering has no reach there — that's a device-management or physical-policy question, and it's honest to say so up front rather than pretend the resolver covers it.

None of these are exotic. They're the standard escape hatches, and a school network that hasn't closed the port-53 redirect and the encrypted-DNS canaries has a filter that any curious student can step around in two minutes.

Age-appropriate policy per device and group

One policy for the whole network is a blunt instrument. A kindergarten tablet, a sixth-form research laptop, and the staffroom should not share filtering rules. The practical move is to define client groups and attach a policy to each, keyed off the client IP (or a static DHCP reservation so the identity is stable).

The per-group approach also keeps your decisions auditable: when a parent or a teacher asks "why was this blocked for my class but not next door," you can point at a named policy rather than guessing. Assigning policy by client means an unmanageable device still inherits the right rules the moment it picks up its reserved address — no agent required.

The privacy and over-block balance

Two failure modes sit at opposite ends of the same dial, and good filtering is the art of staying off both extremes.

Over-blocking is the quiet killer of filtering projects. Block too aggressively and you catch a sex-education resource, a breast-cancer charity, a town called Scunthorpe, or the CDN that a dozen legitimate sites quietly depend on. Each false positive is a help-desk ticket and a small erosion of trust, and enough of them lead staff to demand the whole system be switched off. Bias your defaults toward the narrowest category that meets the requirement, make the unblock path fast, and review what you've blocked rather than setting and forgetting.

Privacy is the other edge. A resolver sees every domain every device asks for — which is a lot of behavioural data about minors. Decide deliberately how much query logging you keep, for how long, and who can read it. For a home, that might be near-zero retention. For a school it'll be shaped by your jurisdiction's data-protection rules (GDPR and its equivalents treat children's data as a special category). The principle is the same either way: collect what your policy genuinely needs to function, keep it only as long as that purpose requires, and don't quietly turn a safety tool into a surveillance archive.

DNS filtering for schools and families is not about building the highest wall. It's about putting a sensible, verifiable, device-blind control at the one chokepoint every device has to pass through — then being honest about where that control ends, and disciplined about not over-reaching with what it can see.