A block five minutes before homework is due creates pressure to make the fastest possible change. Turning filtering off may restore access, but it also removes unrelated protections and makes the original problem harder to diagnose.
The safer goal is a narrow exception: enough access for the school tool to work, without changing the rest of the household.
When to use this process
Use this workflow when:
- A school portal, learning app, classroom login, video lesson, or document service fails on one protected device.
- Recent activity shows that a DNS rule blocked a domain needed by the homework flow.
- The same site works on a parent device or another profile with different rules.
- You can identify a specific domain and explain why the child needs it.
Do not add an exception when the domain is still classified as malicious, the browser shows a certificate warning, or the link came from an unverified message. Confirm the address with the school or service provider first.
DNS changes are also the wrong fix when the problem is a forgotten password, expired school account, broken application, unavailable service, or device restriction unrelated to domain resolution.
A narrow exception workflow
1. Capture the failure before changing anything
Write down the affected device, its active profile, the approximate time, and what failed.
“Math portal login failed on the school laptop at 18:40” is much more useful than “homework is broken.” If possible, note whether the failure happened when opening the main site, signing in, loading a document, starting a video, or submitting work.
This gives you a small time window to inspect instead of reviewing unrelated household activity.
2. Confirm that DNS filtering caused the problem
Open recent activity for the affected device or profile and filter for blocked requests around the recorded time. Look for the requested domain, the action, and the rule or filter that matched.
A blocked domain at the right moment is useful evidence, but do not assume that every nearby request caused the failure. Apps often contact analytics, advertising, update, and tracking services that are not required for the main task.
If no request from the device appears, check whether it is still using the expected resolver. Mobile data, a VPN, private relay, manual DNS settings, or browser secure DNS can move lookups outside the household profile.
3. Reproduce one part of the flow
Retry the smallest action that failed while watching recent DNS activity.
Start with the main page, then test login, lesson content, downloads, video, and submission separately. This helps distinguish the school’s primary domain from supporting services.
A portal might use:
- One domain for the visible website.
- A separate identity provider for sign-in.
- A storage or document domain for files.
- A content-delivery domain for scripts, images, or video.
- A third-party classroom or assessment service.
Allowing only the visible school domain may therefore restore the homepage without fixing login or lesson content.
4. Verify each required domain
Before allowing a supporting domain, check that it belongs to the school, platform, or a dependency expected in the workflow. Use the school’s documentation or support contact when ownership is unclear.
DNS logs show domain-level activity. They do not normally show the exact page, document, search, message, or image involved. A nearby lookup is a clue, not proof of what the child did or which request is essential.
5. Add the smallest useful exception
Scope the exception as narrowly as the setup permits:
- Prefer the exact required hostname over an entire broad category.
- Apply it to the child or school profile instead of every household device.
- If only one managed device needs the site, use an endpoint-specific rule.
- Choose the required action—usually allow—without weakening unrelated malware, phishing, adult-content, or scam protection.
Do not override a high-confidence security block merely because the domain appeared during homework. Verify the address first, especially when the site imitates a familiar school or identity provider.
6. Test the complete task
After adding the first exception, clear or retry the failed action and test the full path:
- Open the portal.
- Sign in.
- Load the assigned material.
- Open any required document, media, or external tool.
- Submit or save a harmless test if the platform allows it.
If another required domain is blocked, repeat the same process. Add dependencies one at a time so the final rule set remains explainable.
Then confirm that the exception did not change behavior on a shared TV, guest device, parent laptop, or another child profile.
7. Record why the exception exists
Give the rule a short reason such as:
Required for school portal sign-in on the homework profile.
Record who approved it and add a review date. A date near the end of the term or school year is often more useful than a permanent exception.
If the school stops using the service, remove the rule. Old exceptions are easy to forget and can quietly make a profile broader than intended.
Use the least activity visibility needed
Troubleshooting does not require reading a child’s entire history. Start with the affected device, a short time range, and blocked actions. Stop when you have enough evidence to fix the problem.
Veilty protects stored DNS activity with user-held keys when visibility is enabled. Assign family Space roles only to parents or caregivers who have a practical reason to review that history. Short retention and focused searches preserve useful recent evidence without turning homework support into general monitoring.
Common mistakes
- Disabling the complete child profile to fix one site.
- Allowing an entire education, media, or content-delivery category.
- Assuming the first blocked domain is the actual dependency.
- Adding several exceptions at once and losing track of which one worked.
- Ignoring browser DNS, VPN, mobile-data, or private-relay settings.
- Treating a DNS log as proof of the exact page or content viewed.
- Keeping a temporary school exception forever.
- Overriding a malware or phishing warning without verifying the domain.
Questions parents often ask
Why does the homepage work while login or video still fails?
The visible site may rely on separate domains for authentication, storage, scripts, or media. Reproduce each stage and add only the required dependencies.
Should I allow the school’s entire domain?
Sometimes a school-controlled parent domain is appropriately narrow, but start with the exact hostname shown in the failed flow. Avoid broad wildcards when unrelated public or user-generated services share the domain.
Why does the site remain blocked after I add an exception?
Check rule precedence, DNS caching, the active device profile, and whether the browser or app uses a different resolver. Also confirm that a second dependency is not being blocked.
Can DNS activity show which homework page my child opened?
Usually not. DNS activity normally shows domains, timestamps, devices or profiles, and policy actions. It does not normally reveal the exact page, document, search, message, or video.
A practical Veilty workflow
Open the affected child or school profile, review blocked activity for the failure window, and create the narrowest verified exception. Test the complete homework flow on that device, add a reason and review date, and leave the wider household baseline unchanged.