A game may keep working because it already has an address or open connection, uses additional domains, selects another DNS resolver, connects by IP, or supports offline play. A DNS block affects matching lookups on the governed DNS path; it does not close existing sessions or disable an app. Test one fresh journey before expanding the rule.
A domain block is not an app switch
DNS usually helps an app translate a domain name into an address. Once the app has an answer, it may reuse that address from a cache or continue an established connection without asking the resolver again. DNS records include a time to live that permits caching, and modern resolver behavior may sometimes serve stale data for resiliency.1 Changing a policy therefore does not reach backward and terminate traffic already in progress.
A game is also a bundle of journeys rather than one connection. The launch screen, account sign-in, entitlement check, downloads, multiplayer, chat, voice, media, telemetry, and advertising can use separate infrastructure. Blocking one hostname may remove a store panel while leaving local play or an existing multiplayer session intact. That partial result is evidence about architecture, not proof that DNS filtering is broken.
Sort the survival paths
| Observed result | Possible cause | Useful next check |
|---|---|---|
| Current match continues | Open connection or cached address | Close the app and test a genuinely fresh session |
| Some features fail, others work | Multiple domains or offline components | Name the exact journey that should stop |
| Wi-Fi block works, mobile data does not | Different network and DNS path | Compare the same fresh journey on each path |
| No matching DNS request appears | Cache, alternate resolver, direct address, or offline play | Do not infer app inactivity from DNS alone |
| Other apps break too | Shared identity or delivery domain | Remove the broad rule and use app controls |
An application can use DNS over HTTPS rather than the resolver selected for the local network. RFC 8484 defines DNS queries carried through HTTPS and explicitly supports clients communicating with a chosen DoH server.2 Mobile data also has its own resolver path. Either difference can put the lookup outside the family DNS policy being tested. Diagnose the path; do not respond by blocking generic HTTPS infrastructure.
Test a fresh game journey
- Define one result, such as preventing a new multiplayer sign-in on the child’s phone; “block the game” is too vague for diagnosis.
- Confirm the DNS rule belongs to the child device or resource being tested and that the device is using the expected governed path.
- End the game session and close the app so an existing connection is not mistaken for a fresh lookup.
- Repeat the named journey once while observing only the short time window needed to identify matching domain decisions.
- Compare Wi-Fi and mobile data if the behavior differs, without teaching the child an alternate path around the rule.
- Test an unrelated app and a required sign-in so shared infrastructure damage is visible.
- If DNS cannot isolate the game safely, remove the experimental rule and use the platform’s app block or limit.
Keep the test reproducible. Record the device, network, time, intended action, result, and policy change. Do not flush every cache, restart the household router, add many wildcards, and switch networks at once; simultaneous changes erase the clue that would distinguish caching from scope, resolver choice, or a missing domain.
Read DNS activity with restraint
A DNS record can show that a governed device requested a domain and which rule answered. It cannot prove who held the phone, which screen appeared, whether a match was background traffic, or what happened inside an allowed connection. It cannot reveal page content, search terms, in-app chat, voice audio, or complete browser history. RFC 9076 treats DNS activity as privacy-sensitive because queries can expose patterns about users.3 Start from the observed game behavior and inspect only enough history to test a hypothesis.
Absence is equally limited. No visible query may mean an address was cached, the app did not need the network yet, another resolver answered, or the session reused an existing connection. DNS activity is strong evidence for a matching lookup, but weak evidence for total app use.
Choose the fix that matches the failure
When an old session survives, test after normal cache and session turnover rather than widening the block. When a second resolver path appears, fix governance of the child device rather than collecting unrelated domains. When shared services cause collateral damage, abandon the DNS rule. Google Family Link can block supported child apps or set app limits on Android and ChromeOS,4 while Apple Screen Time can manage app use and content restrictions for a child.5 Those controls are a better fit when the desired outcome is “this app is unavailable.”
The honest outcome is clear troubleshooting expectations: a DNS rule is successful when a matching fresh lookup receives the intended answer on the governed path. It is not a promise that every feature, cached session, offline mode, or alternate connection will disappear.
Mobile-game block questions
How long can DNS caching delay a new block?
It depends on the record’s TTL, caches in the resolver and device, and whether the app already holds an address or connection. Do not promise an exact delay. Start a fresh app journey and wait for ordinary cache expiry before concluding that the policy did not match.
Does a missing DNS record mean the child did not use the game?
No. The game may have reused a cached answer, kept a connection open, used another resolver path, connected directly, or played offline. DNS activity describes requests observed on that DNS path; it is not a complete record of app use.
Should parents keep adding domains until the game stops?
No. Broad trial-and-error blocking can break shared sign-in, updates, media, or unrelated apps. If the family’s goal is to disable one app, use the device or game-platform control that identifies it directly and keep DNS for destinations that can be isolated safely.
Keep troubleshooting scoped to one Space
In Veilty, keep the experiment inside the relevant family Space and begin with one device-specific Space resource.6 Baseline and enforced policies are reusable for Spaces: a user Space resource may override the baseline but cannot weaken an enforced policy. Invite a caregiver to the account first, then assign a Space role if they should manage the rule or open its retained history; an invitation alone grants no Space access. Veilty processes live DNS requests to enforce policy, while retained activity history is end-to-end encrypted and limited to members whose Space roles permit access.