A student opens network settings, types 8.8.8.8, and every category your filter blocks resolves normally. Nothing was hacked. The network simply allowed a client to choose a resolver outside the policy.

DNS filtering is the most common content control in K-12, and it is only as strong as the rule that forces clients through the resolver you control.

Where the policy lives

Client → DNS query → filtered resolver → verdict → answer or block page

Three things must be true for that to work:

  1. The client uses the filtered resolver.
  2. The client cannot reach another resolver.
  3. The client cannot encrypt its way around the resolver.

Most districts get the first one right (DHCP), skip the second, and have never considered the third.

Control 1: hand out the right resolver

DHCP option 6 should point at the filtered resolver — for students, staff, and guests. For domain-joined machines, that is the domain controllers, which forward to the filter. For everything else, it is the filter directly.

The failure mode is subtle: if the DC's forwarder points at 1.1.1.1, every domain-joined device bypasses filtering while appearing to use the DC.

Control 2: block everyone else

A resolver allowlist, expressed as firewall policy:

# Source Destination Port Action
1 All internal 10.0.0.3, 10.0.0.4 53 Allow
2 All internal Filter resolver IPs 53 Allow
3 All internal Any 53, 853 Block
4 All internal Known DoH providers 443 Block

Rule 3 is what makes rule 1 meaningful. Rule 4 covers the encrypted case: a browser using DNS over HTTPS sends queries to a public resolver on port 443, which looks like ordinary web traffic.

Two paths to the same answer: one filtered, one that bypasses policy entirely.

Control 3: the client-side settings

Blocking DoH at the firewall is necessary but blunt — it breaks legitimate services that share infrastructure. The cleaner control is policy on the device:

  • Chrome and ChromeOS: disable secure DNS, or set a custom resolver to your filter. Managed by Google Admin, so it applies to every district Chromebook.
  • Windows: disable DoH via Group Policy or the registry.
  • Firefox: disable DoH via policies.json.

Browser-level policy is the difference between "we block 443 to a list of providers" and "the browser never tries."

Apple and Google devices probe for connectivity

Phones and tablets check for internet access by resolving a known name. If you block public resolvers without allowing those probe domains through your filter, devices will report "no internet" while everything else works. Allow the captive-portal probe domains explicitly.

What filtering cannot see

  • CNAME cloaking. A tracker served from a first-party subdomain resolves through a CNAME to a blocked domain. If the filter only inspects the original name, it misses it. Modern filters follow the chain; verify yours does.
  • Embedded IP addresses. A client that connects to 203.0.113.10:443 never asks DNS.
  • VPN and proxy apps. A tunnel moves the query off your network entirely.
  • DNS tunneling. Data exfiltration encoded in long subdomains. Detectable by shape: high volume of TXT queries, unusually long labels, one parent domain.

Worked example: the student who knows about 8.8.8.8

Before:

  • DHCP hands out 10.0.0.3.
  • Student sets 8.8.8.8 manually.
  • Queries resolve, filtering does nothing.
  • The firewall's Allow DNS rule permits any destination on 53, so nothing stops it.

After:

  1. DHCP still hands out 10.0.0.3.
  2. Firewall: allow 53 to 10.0.0.3/4 and the filter; block 53/853 to everything else.
  3. Firewall: block 443 to the major DoH endpoints.
  4. Chrome policy: secure DNS disabled on managed devices.
  5. Log the blocks; a device repeatedly hitting the block rule is a signal, not just noise.

The student can still change the setting. It simply does not work.

What breaks in production

  • A hardcoded resolver in an appliance. Some IoT devices ignore DHCP and use 8.8.8.8. They break when you block it, and you find out weeks later.
  • DoH left open. Filtering looks healthy and half the district is bypassing it.
  • Blocking all 443 to a provider that also hosts legitimate services, causing an outage.
  • Captive portal probes blocked, so phones report no connectivity.
  • No logging, so you cannot tell whether the policy is working or merely configured.

Checklist

  1. Every client gets a resolver that enforces the filter.
  2. Ports 53 and 853 are blocked to everything except your resolvers.
  3. DoH is disabled by device policy on managed fleets.
  4. Captive-portal probe domains are explicitly allowed.
  5. Query logs are retained and reviewed for bypass attempts and tunneling shapes.
  6. The DCs' forwarders point at the filter, not at a public resolver.

Next

The remaining security articles cover the enforcement points themselves: object-based policy, 802.1X, and TLS inspection.

  • DNS
  • Filtering
  • DoH
  • Securly
  • Policy