Parents should not collect detailed DNS logs by default. First name the decision the activity must support, the device or family context involved, who may review it, and when collection ends. Prefer direct tests and aggregate policy outcomes. If detailed history cannot change a specific decision, collecting it creates privacy cost without a useful family benefit.
The practical outcome is purpose-first visibility: a short decision record that prevents “just in case” collection from becoming routine surveillance. It also gives caregivers a shared standard for when detail is justified and when it must be reduced.
Write the question before the record
A purpose should describe a decision, not a feeling. “I am worried about the internet” cannot tell anyone what to collect. “We need to learn whether the new school portal is matching the adult-content rule on the school laptop” identifies a resource, rule, observation, and possible correction. It also makes irrelevant household activity easy to exclude.
Ask what will change after the review. If every possible result leads to the same action, the logs are not necessary. If a direct test can answer the question, use it. If an allowed, blocked, and redirected count is enough, keep the domain list closed. Detailed collection earns its place only when it can support a narrower, evidence-based action.
Turn a purpose into five constraints
| Constraint | Question to answer | Example |
|---|---|---|
| Decision | What will this evidence change? | Keep, narrow, or correct one school rule |
| Scope | Which resource and context matter? | School laptop during one homework session |
| Detail | What is the least revealing useful signal? | Rule outcomes before hostnames |
| Access | Who must review it? | One caregiver responsible for the correction |
| Exit | When does collection or access stop? | After the fix is verified or in 48 hours |
Write these constraints before opening detailed history. Do not quietly expand from one child resource to the entire household or from two days to indefinite retention. If the question changes, stop and make a new decision rather than stretching the original purpose until it means everything.
Purpose limitation is also consistent with primary privacy guidance. The FTC’s COPPA plan tells covered services to collect only what is reasonably necessary and to define retention and deletion.2 The ICO Children’s code emphasizes transparency, high privacy by default, and age-appropriate explanations.3 Those duties do not automatically apply to household administration, but the principles offer parents a strong trust standard.
Know when detail will not help
DNS normally records domain lookups and policy outcomes, not page contents, search terms, in-app chats, voice audio, exact videos, or full browser history. A hostname also does not prove who initiated the request or why. Apps refresh in the background, browsers prefetch, pages load third-party dependencies, and shared devices have several users. RFC 9076 describes these primary and secondary requests and the inference risks in linked query histories.1
- Do not use DNS history to reconstruct a conversation inside an allowed app; it lacks that content.
- Do not infer that a child chose every hostname requested by a browser or smart device.
- Do not enable household-wide detail to diagnose one resource whose time and symptoms are known.
- Do not preserve raw activity after the useful outcome has become a policy note or tested exception.
Make the review visible to the family
Explain the purpose in language the affected child or teenager can understand: what the family is trying to fix, which device is in scope, what DNS can reveal, what it cannot reveal, who can see retained history, and when the window closes. Invite questions before collection where possible and again during the review. A policy is more trustworthy when a young person can describe it accurately.
Do not promise secrecy from every resolver or claim that encrypted transport hides queries from the resolver. The resolver must receive the hostname to apply a decision. Storage encryption protects a different stage. State both boundaries plainly so a privacy promise does not depend on technical ambiguity.
Close the loop instead of keeping evidence
- Reproduce the named problem and record the time.
- Review aggregate or rule outcomes before domain-level entries.
- Make one narrow, reversible correction when the evidence supports it.
- Test the expected allowed journey and one known policy outcome.
- Reduce detail, remove temporary access, and tell the family that the review is closed.
Keep the durable result, not the investigative exhaust. A short note such as “school identity domain allowed for this resource; reviewed next term” is usually more useful than months of unrelated lookups. If the test fails, move the issue to the layer that owns it instead of widening DNS collection.
Purpose-first logging questions
Is security a specific enough reason to keep family DNS logs?
Usually not by itself. Name the decision: confirm that one resource follows phishing protection, diagnose repeated malware-domain blocks, or investigate a false positive affecting schoolwork. Define the evidence and end condition for that decision. A broad label such as security can otherwise justify unlimited scope, access, and time.
Can parents rely only on aggregate DNS metrics?
Often, but not always. Counts and policy outcomes can confirm that filtering is active and show whether a rule is unusually noisy. A specific hostname may be needed to resolve a false positive or suspicious domain. Escalate temporarily for that resource and time window, then return to less detailed visibility.
Does family consent make unlimited DNS collection acceptable?
No. Agreement is important, especially for trust, but it does not remove the need for a narrow purpose, proportionate detail, limited access, and deletion. Children may also have little practical ability to refuse a household safety rule. Treat conversation as continuing participation, not a one-time permission slip for permanent monitoring.
Translate the purpose into a family Space
If Veilty fits the family, write the purpose first, then review the smallest relevant resource in its family Space.4 Start with aggregate outcomes and use protected retained history only for the named window. Invite a caregiver to the account before assigning the minimum Space role; the invitation itself gives no Space access. Retained history is Space-scoped, end-to-end encrypted with user-held keys, and role-limited. Live DNS requests still must be processed by the resolver to apply policy.