Allow the educational game through the child’s app or device controls first. If DNS policy caused the block, identify only the domains required for the complete learning journey, add a narrow exception to that child’s resource, and retest. Do not allow a whole games category or weaken an enforced family rule.
Define the one learning journey
Write down the exact outcome before changing a filter: “This child can sign in to the assigned maths game, open today’s lesson, save progress, and sign out on the homework tablet.” This is narrower than “allow games.” It gives the family a reproducible test and reveals which supporting functions are actually required.
Confirm that the title, publisher, teacher link, and account are legitimate. A school message or app-store listing is stronger evidence than a hostname noticed in a long activity list. Check whether the teacher expects a browser edition, installed app, school identity provider, classroom code, or a particular child account. Those paths can use different services.
Find which layer stopped the game
| Observed failure | Check first | Do not assume |
|---|---|---|
| App cannot be installed or opened | Child account, age rating, and device app controls | That DNS blocked it |
| Website shows a block response | Matched DNS or browser policy | That the whole category is wrong |
| Sign-in loops or fails | School identity and required cookies or app permissions | That the game domain alone is enough |
| Lesson media stays blank | Content-delivery and media dependencies | That every concurrent domain is required |
Google Family Link lets a parent block or allow supported apps and manage app limits on a child’s Android device or Chromebook.1 Apple Screen Time can manage allowed apps, content ratings, communication, and purchases for a child.2 When the obstacle is an app permission or age decision, correct it there. A DNS allow cannot override an operating-system restriction.
Discover dependencies without opening a category
If a DNS rule is responsible, begin a short observation window on only the affected resource. Close unrelated apps, start a fresh session, and walk through sign-in, lesson selection, media, saving, and sign-out. Compare the blocked hostnames with the game publisher’s and school’s official support information. Repeat the journey once to separate stable dependencies from background noise.
A lookup near the failure is evidence to investigate, not automatic permission to allow. Apps contact analytics, advertising, crash-reporting, notification, and shared delivery domains. Some dependencies serve many unrelated products. DNS cannot see page content, chats, voice audio, a lesson answer, or the button that caused a request. It only evaluates domain lookups on the governed resolver path.
Build an exception that can expire
- Record the child resource, game, learning purpose, person approving the change, and date of the test.
- Confirm that the failure came from baseline policy rather than an enforced policy or a non-DNS control.
- Allow the smallest verified hostname or service dependency instead of the games category, publisher portfolio, or content-delivery network.
- Keep the exception on the homework device or child context when parent, sibling, and guest devices do not need it.
- Add a review date aligned with the course, school term, or assignment rather than leaving the exception unexplained forever.
- Preserve a quick rollback: know which rule changed and remove it if the game still fails or unrelated content becomes available.
If the match came from enforced Space policy, a child resource cannot override it. Verify whether the domain was classified correctly and review the enforced policy itself with the responsible caregiver. Do not create a misleading local allow that appears to solve the problem but can never take precedence.
Prove the game and the boundary
Test the complete assigned journey from the child’s normal account and device. Confirm launch, school sign-in, lesson content, saving, and sign-out. Then test one unrelated game or destination that should remain unavailable, plus an ordinary school site that must keep working. A successful exception proves both sides: the learning task works and the surrounding boundary remains intact.
Repeat the check from the network path the child actually uses. A device may use mobile data, a VPN, or application-selected encrypted DNS instead of the expected household resolver. RFC 8484 describes how applications can carry DNS over HTTPS.3 If the resolver path differs, fix the coverage question rather than adding broader allows to a policy the device is not consulting.
Review the exception when the assignment ends, the publisher changes infrastructure, or the app begins failing again. Remove unused domains one at a time and retest. Narrow allowlisting is maintenance, not a one-time promise that a domain will always serve the same purpose.
Educational-game exception questions
Should parents allow the entire games category for one school title?
No. First allow the title through its platform or device control. If DNS caused the failure, allow only verified domains needed by that game on the affected child resource. A category-wide exception can enable unrelated games and is much harder to explain, test, and review.
Why does an educational game need domains that do not match its name?
Games commonly depend on separate identity, content-delivery, media, update, telemetry, and classroom services. Some are shared with other products. Confirm each dependency during a controlled test and avoid treating every simultaneous background lookup as part of the game.
Can DNS filtering allow lessons but block chat inside the same game?
Not reliably. DNS can act on distinct hostnames when the service separates them, but it cannot inspect chats, voice audio, page content, or actions inside an allowed domain. Use the game’s child-account, communication, and classroom controls for feature-level decisions.
Make one reviewed change in the family Space
In Veilty, keep the educational-game exception on the affected resource inside its family Space.4 Reusable baseline and enforced policies belong to Spaces: the resource can override baseline policy when justified, but never enforced Space policy. Invite another caregiver to the account first, then assign the minimum Space role; an account invitation alone gives no Space access. Role-permitted retained activity history is Space-scoped and end-to-end encrypted, while live DNS requests still must be processed to apply the rule. Test the one resource before widening anything.