Content filtering that holds up: categories, parental control, and what NIS2 expects

Turning on a content filter is a checkbox. Building a filtering policy that actually does what you think it does — and that you can defend to an auditor — is not. The gap between the two is where most DNS filtering deployments quietly fail: a blocklist that's silently overridden, a "blocked" service that resolves anyway, a parental filter a browser routes around.

This piece is about that gap. How DNS-level filtering works, the one ordering rule that explains almost every "why isn't this blocked?" ticket, and how the whole thing maps onto the compliance frameworks that increasingly expect it.

Why filter at the DNS layer at all

Because it's the one chokepoint every device shares. A phone, a smart TV, an IoT sensor and a laptop have nothing in common except that they all ask DNS where to find things. Block the lookup and you block the connection before a single packet reaches the destination — no per-device agent, no certificate to install, no app to manage. One resolver policy covers the whole network.

UnveilDNS stacks several kinds of filtering on that single layer:

The rule that explains every conflict

Stack six filtering mechanisms and they will eventually disagree about the same domain. A domain on your personal blacklist that's also on a cloud whitelist — which wins? The answer is not "the stricter one." It's a fixed evaluation order, and knowing it is the difference between a policy that works and one that mysteriously doesn't.

Strongest first, the chain evaluates like this:

This isn't a quirk; it's the filter engine behaving exactly as specified. But it's invisible until it bites you, and "I blacklisted it and it still resolves" is the single most common filtering support ticket there is. Now you know why.

Parental control has two completely different failure modes

Take a concrete case we see constantly: YouTube comments suddenly hidden behind "Restricted Mode." There are two independent mechanisms that cause it, and the fix for one does nothing for the other:

• The upstream rewrote the answer. A family-filtering upstream returns YouTube's restricted CNAME for several domains. The fix is to whitelist those specific domains so they bypass the family upstream.
• The resolver rewrote the answer. SafeSearch's YouTube enforcement rewrites the response itself, regardless of what the upstream returned. Whitelisting does nothing here — you have to turn off the SafeSearch YouTube toggle.

The diagnosis is a two-line dig: ask the upstream directly, then ask your resolver. If the upstream already returns the restricted IP, it's mechanism one; if the upstream is clean but your resolver isn't, it's mechanism two. Filtering is full of cases like this where the symptom is identical and the cause — and cure — is not. Treating "parental control" as one switch is how you end up with a policy nobody can reason about.

Block, don't just hope: closing the bypass routes

A filter that a device can route around isn't a filter. Two bypass routes matter most:

• The device's own DoH. A browser or OS that quietly switches to a public DNS-over-HTTPS endpoint skips your resolver entirely. Neutralising the canary domains these clients probe forces them back to the local resolver.
• Hard-coded public resolvers. A device pointed straight at a public resolver bypasses DNS policy at the network edge — which is a firewall/NAT redirect job, not a resolver one, but worth closing in the same breath.

Where compliance comes in

DNS filtering used to be a "nice to have." Under the EU's NIS 2 directive it's edging toward "expected." NIS 2 widened cybersecurity obligations to medium and large entities across 18 sectors, and its baseline asks for technical measures around access control, network security and incident handling. DNS-layer filtering and logging is a clean, low-friction way to evidence several of those:

On the privacy side the same logging that helps you evidence controls is also personal data — client IPs and queried domains. Under GDPR that means a retention policy and a purpose you can state, not an indefinite firehose. UnveilDNS aggregates raw query tables into daily summaries and drops the granular hourly tables behind them, so you keep the trends without hoarding per-query personal data forever. For French deployments, ANSSI's hygiene guidance points the same direction: encrypt the resolver path, control egress DNS, log what matters.

The compliance framing isn't a sales gimmick. It's the same controls you'd want anyway — block the bad, see what's happening, keep the logs honest and time-bounded — with a paper trail attached.

The short version

• Filter at DNS because it's the one layer every device shares.
• Learn the chain order — rewrites > allowlist > blocklist > services > parental — and most "why isn't this blocked" questions answer themselves.
• Parental control isn't one switch; diagnose upstream-rewrite vs resolver-rewrite separately.
• Close the DoH bypass with canary blocking, or your policy is optional.
• Treat your query logs as both an audit asset and personal data — retain deliberately.