Parents should never promise that DNS filtering sees everything, blocks every harmful experience, proves what a child did, cannot be bypassed, or replaces conversation and device safety. Promise only what the control can deliver: domain-level policy, bounded evidence, clear privacy limits, a fair exception path, and regular review as children, devices, and risks change.
The practical outcome is honest expectations. A child knows which boundary exists and how to ask for help. A caregiver knows when a DNS clue is too weak for a conclusion. Nobody has to pretend that one network control can settle every safety, privacy, or trust question.
Trade certainty for accuracy
Absolute promises are tempting because they make a difficult family problem sound solved. Yet a promise such as "nothing bad can get through" hides both technical limits and the judgment children still need. UNICEF recommends introducing privacy as a right and a safety practice, involving older children in privacy decisions, and respecting their growing independence.1 Honest language supports that independence instead of making safety depend on an invisible system.
Describe the control in verbs a family can verify: it may allow or block a domain lookup under a chosen policy. Then describe the limits just as plainly. DNS filtering cannot read page contents, typed search terms, in-app chats, voice audio, full URLs, or full browser history. A large service may host both welcome and unwelcome material behind the same domain, leaving DNS without enough detail to separate them.
Retire five DNS promises
| Do not promise | Why it fails | Promise instead |
|---|---|---|
| "We can see everything you do." | DNS omits page contents and intent, while background requests create noise. | "We will explain what is visible and treat it as limited evidence." |
| "Every harmful thing will be blocked." | Lists change, allowed platforms mix content, and other network paths exist. | "This reduces selected domain-level risks alongside other safeguards." |
| "A block proves you did something wrong." | Apps, ads, embedded resources, and shared devices can trigger lookups. | "We will ask what happened before reaching a conclusion." |
| "The rule cannot be bypassed." | A browser, VPN, relay, mobile connection, or changed resolver can use another path. | "We will test the paths we expect to cover and discuss gaps." |
| "We will never change the policy." | Needs, maturity, school services, and risks change. | "We will explain changes and review them together." |
Do not quietly replace one false promise with another. "The logs never make mistakes" is no better than "we see everything." RFC 9076 explains that browsers can issue secondary requests for embedded resources and prefetch names without a direct user action.2 It also notes that linked queries can reveal patterns. The same record can therefore be both sensitive and uncertain.
Write promises a child can test
- Name the purpose of the boundary, such as reducing known malicious domains or protecting sleep on a shared device.
- Say which people, resources, and network contexts the rule is intended to cover, including where it may not follow a device.
- Explain what evidence exists: an allowed or blocked lookup and possibly timing or a resource identity, not a replay of someone's screen.
- Promise a respectful response. A surprising lookup starts a question or technical check, not an accusation.
- Provide an exception path with a person who can decide, a reasonable response time, and an expiry for temporary changes.
- Choose a review date and let family members raise a problem sooner when a rule causes harm, embarrassment, or broken access.
Read the promises aloud and ask each person what they think the words mean. If "activity" sounds like screen recording, correct it. If "safe" sounds like a guarantee, replace it with the risk the rule actually reduces. A good promise survives translation into a child's own words.
Respond without turning clues into verdicts
When a rule fires, first decide whether anyone needs immediate support. For routine false blocks, ask what task failed and test that journey on the affected resource. For a possible security event, check the device with supported security tools. For a sensitive domain, remember that the lookup does not identify the page, person, or intent. Open only the shortest relevant detail and avoid searching unrelated history.
Keep safety and punishment separate. A child who reports a broken school site should not lose unrelated privacy. A family member who asks about a rule should not be treated as trying to evade it. The promise worth keeping is that questions and mistakes receive a proportionate response, while urgent concerns receive direct human help rather than a broader trawl through DNS activity.
Renew the agreement as independence grows
Review the agreement after a new device, a school change, a repeated false block, or a shift in caregiving responsibility. Ask whether the original problem still exists, whether less restrictive policy can now work, and whether detailed visibility can shrink. Older children should have more meaningful participation in privacy decisions, not simply a longer list of hidden controls.
- Remove a promise nobody can explain or verify.
- Retest one expected block and one ordinary allowed task.
- Close temporary exceptions that have reached their expiry.
- Reduce access to retained detail when responsibilities change.
- Record the next review date and who can request an earlier conversation.
Questions about honest DNS promises
Can parents promise that DNS filtering blocks every harmful site?
No. Coverage depends on the domains a service uses, the policy lists selected, and whether the device continues to use the intended resolver. Harmful material may also appear inside an allowed platform where DNS cannot distinguish one page, post, message, or video from another.
Can a DNS log prove that a child visited a website?
No. A lookup can come from a person, a background app, an embedded resource, prefetching, or another user of a shared device. It is a technical clue, not proof of who acted, what page appeared, or why the request occurred.
What is a fair promise parents can make?
Promise to explain the purpose and limits of each rule, use the least activity detail needed, provide a calm exception path, and revisit the agreement. Those commitments are observable and remain useful even when devices, applications, and family responsibilities change.
Keep the technical boundary visible
If Veilty fits the family agreement, represent household resources inside a family Space and start with the least visibility the purpose needs.3 Baseline and enforced policies are reusable for Spaces: a user Space resource may override baseline policy, but it cannot weaken enforced Space policy. Invitations add people to the account; after acceptance, a Space role grants access, so an invitation alone gives no Space access. Retained activity history is Space-scoped, end-to-end encrypted with user-held keys, and visible only to members whose Space roles permit it. The resolver still processes live DNS requests to apply policy.