
Gather the Exact Details First
- The network name, subnet, or IP range involved
- Whether the device is district-managed, guest, BYOD, or otherwise unmanaged
- The device platform and approximate location on campus
- The exact URL or domain you used to test filtering
- The time of the test and, if available, any related DNS log entry
Check the Filtering Path
- Verify that the device is connected to the expected campus or guest network, not a cellular hotspot, VPN, or another path outside your filtered network design.
- Check that the relevant subnet, IP range, or network segment is part of the DNS filtering configuration your district intended to protect.
- Verify that the traffic is being evaluated as the correct user category, such as student, staff, or guest, and that the expected filtering behavior exists for that target.
- If the device is managed, verify whether agent awareness or another Admin filtering path is changing the expected DNS result.
- Look for the request in the DNS logs and review the user-level, IP-level, subnet, category, or alias-domain details available in Admin.
- Test the device again with a known validation URL from the same network path so you can separate configuration issues from one-off site behavior.
Identify Common Causes
Know When to Escalate
- The network and IP-range setup appears correct, but requests still do not show in DNS logs
- The device behavior changes unpredictably between managed and unmanaged devices
- DNS logs do not explain why the site is being allowed or bypassed
- You need help validating how DNS filtering should interact with your existing Admin deployment
Resources
Understand DNS Filtering
Review the feature model and configuration assumptions behind school-network filtering.
Understand Filtering Contexts
Use this concept page to identify which filtering path is actually active for the device.
A Site Is Blocked Unexpectedly
Use this troubleshooting page when traffic is filtered, but the specific site result is wrong.