Most families should begin with a light family Space baseline, one child profile for child-specific boundaries, one parent profile with ordinary household access, and a separate guest context. Add shared-screen or school-device profiles only when their jobs differ. Keep non-overridable protection in enforced Space policy, scope exceptions narrowly, and avoid treating profiles as identities.
Start with household jobs, not ages
A useful family profile predicts a different domain decision. A homework tablet may need safer search and a narrow distraction boundary. A parent laptop may need unrestricted research while retaining malware and phishing protection. A television is shared, and a school-managed laptop may already follow another organization’s controls. Design around those device jobs before attaching a profile to a person or age.
Begin with the family Space. Put modest shared defaults in baseline policy, such as well-supported protection against malicious or phishing domains. Reserve enforced Space policy for rules no attached resource may override. Then list only the decisions that differ by resource. This avoids making the strictest child preference the hidden default for parent work, shared screens, visitors, and school equipment.
| Context | Purpose | Typical difference |
|---|---|---|
| Child | Child-used phones, tablets, or computers | Child-specific domain or search boundaries |
| Parent | Ordinary adult work and personal devices | Shared safety without child preferences |
| Guest | Temporary visitor network access | Modest security and separate network treatment |
| Shared screen | Television, console, or communal tablet | One deliberately chosen household rule |
| School device | Equipment governed by a school | Avoid conflict with school-managed controls |
Give the child profile a narrow purpose
Describe the child profile by its outcome: reduce access to known harmful domains, apply supported safer-search behavior, or keep one distraction away from a homework device. Avoid promises to “make the internet safe.” DNS sees domain lookups, not the meaning of every page, message, video, game, or conversation. A narrow purpose makes it possible to explain the rule to the child and recognize when another control is needed.
Keep age, maturity, and device use in the family conversation rather than burying them in a giant category list. A teenager’s research laptop, a younger child’s tablet, and a family game console may require different choices. Add another child profile only when the domain outcomes genuinely differ. Otherwise one profile with clear membership is easier to review and less likely to break school or health resources.
Test a complete task from a representative device: sign in to school, open assigned material, play required media, and submit work. Then test one safe domain expected to receive a policy outcome. If a required service fails, identify its exact hostname and matched rule. Add the smallest justified baseline override to the affected resource; enforced Space policy remains non-overridable.
Keep parent access ordinary and explainable
The parent profile should not be an all-powerful bypass. It should represent ordinary adult devices that receive family Space protection without child-specific preferences. Keep required work, banking, health, identity, and communication paths available. If one parent device has an unusual dependency, attach that exception to the resource rather than widening every parent device.
A separate parent profile also provides a useful control test. When a child device is blocked but a parent device works, the difference helps locate the owning rule. When both fail, investigate shared Space policy, the upstream resolver, or the service itself. Profiles clarify technical scope; they do not prove which person used a shared endpoint.
Treat guests as a network context
Guest access is temporary network use, not a child policy. Apply modest threat protection and keep visitor traffic separate from trusted household systems through the router, firewall, or network controls that own isolation. DNS policy cannot stop local device discovery, enforce Wi-Fi client isolation, or authorize access to printers and storage. Do not import family content preferences merely because guests use the same internet connection.
Avoid identifying visitors through detailed DNS history. Shared addresses, background traffic, application updates, and embedded domains make attribution unreliable. RFC 9076 describes DNS data as sensitive and notes that queries can arise without deliberate navigation.1 Verify the guest policy with a harmless expected outcome and a normal browsing task, retain only what has a clear operational purpose, and remove temporary exceptions when the visit ends.
Add special profiles only when needed
Shared televisions, consoles, and communal tablets deserve a separate profile only when one household rule is appropriate for every user. DNS cannot switch policy when another person picks up the remote. Choose a common boundary everyone understands, then rely on service accounts, device parental controls, and app settings for user-specific ratings, purchases, watch history, or time limits.
Treat school-managed devices cautiously. Their administrator may already configure DNS, VPN, certificates, browsers, or filtering. Do not attempt to defeat or replace those controls. A light family Space baseline can protect the surrounding home context when it does not interfere, but school support should own managed-device conflicts. Keep the school resource distinct so its exceptions do not leak into personal devices.
- Write one sentence describing each device context and desired outcome.
- Keep shared protection in the family Space baseline and mandatory rules in enforced Space policy.
- Create child, parent, and guest profiles only where their domain decisions differ.
- Add shared-screen or school-device profiles after a real difference appears.
- Test one endpoint in each context and a complete required workflow.
- Remove stale membership and temporary exceptions during a regular family review.
DNS filtering can allow, block, or otherwise answer a domain lookup. It cannot see page contents, URL paths, search terms, downloads, in-app chats, voice audio, full browser history, or which family member is holding a device. Use search-provider controls for search results, device controls for schedules and apps, account controls for purchases and profiles, and network controls for isolation. Profiles make DNS policy clearer; they do not expand what DNS can observe.
- Creating one profile per person even when devices are shared.
- Using the child profile as the household baseline.
- Putting preference-based restrictions in enforced Space policy.
- Treating guest DNS policy as network isolation.
- Changing school-managed controls without the school administrator.
Family profile questions
Does every family member need a separate DNS profile?
No. Create profiles for distinct device jobs and policy outcomes, not automatically for every person. Shared devices and changing users make one-profile-per-person misleading.
Can a child profile override the family Space baseline?
A child resource may override family Space baseline policy for a justified, narrow need. It cannot override enforced Space policy. Put only truly non-negotiable protection in the enforced Space layer.
Should guests receive the child profile?
Usually not. Guests are a temporary network context, not children. Give guest devices a modest security boundary and isolation appropriate to the network without importing household content preferences.
Share a family Space with care
If Veilty fits the household, keep devices and reusable baseline and enforced policies in a family Space, then attach narrow filters or rules where child, parent, guest, shared-screen, or school resources differ.2 Invite another caregiver to the Veilty account first, then assign only the family Space role needed; the invitation itself grants no Space access. Retained family history is Space-scoped, end-to-end encrypted with user-held keys, and available only where the assigned role permits it. Review the shortest useful window for a named troubleshooting question rather than monitoring ordinary family life.