A family baseline blocklist should cover high-confidence risks that every household device should avoid, such as known malware, phishing, and scam infrastructure. Add only categories the whole household accepts. Keep child-specific, work-specific, or entertainment restrictions on narrower resources, and reserve enforced Space policy for rules that no resource may override.
Define the shared minimum before choosing a catalog
A baseline is the household’s default, not the strictest rule anyone might ever need. Write a short outcome first: “Reduce connections to known malicious infrastructure on every family device without breaking ordinary school, work, communication, and media tasks.” That sentence creates two tests. The catalog must contribute meaningful shared protection, and its mistakes must be acceptable on every resource that inherits it.
Begin with high-confidence protective categories such as known malware command-and-control, phishing, and scam infrastructure from sources with documented provenance and correction practices. CISA describes protective DNS as preventing connections to known or suspected malicious infrastructure based on DNS-query information.2 That is a defensible shared outcome. Advertising, telemetry, social, gaming, streaming, and newly registered-domain categories require separate judgments because they mix preference, privacy, productivity, and risk.
| Category | Starting scope | Reason to reconsider |
|---|---|---|
| Known malicious infrastructure | Shared baseline or enforced policy after review | Source quality or false positives are unacceptable |
| Adult-content domains | Shared baseline only with a clear household agreement | Adults, guests, or work devices need different access |
| Advertising and trackers | Baseline or selected resources according to household preference | Required media, shopping, or sign-in workflows break |
| Social, games, and streaming | Relevant child or device resources | The restriction is not shared by the whole household |
| Newly registered or broad uncategorized domains | Narrow pilot rather than default | Legitimate new services are repeatedly blocked |
Separate common safety from household preferences
Families often agree on the outcome but not the scope. Blocking a confirmed phishing domain is different from limiting social media on a homework device. The first is a shared protective decision. The second is a resource-specific access decision. Keeping them separate makes exceptions understandable: a school dependency can be allowed on the child resource without removing malware protection, while a parent’s work device does not inherit a child’s entertainment limit.
Use enforced Space policy sparingly for requirements no resource may weaken. A carefully reviewed malicious-domain source may belong there when the household wants it non-overridable. Put flexible defaults in baseline policy so a legitimate device-specific need can override them. Do not place a broad lifestyle category in enforced policy merely because it is convenient; doing so converts every false positive into an escalation and removes the option for a narrow local correction.
Score catalog fit instead of counting domains
- Define the single household outcome the catalog should support.
- Read its inclusion criteria, upstream sources, maintainer identity, update practice, license, and correction route.
- Check whether its categories match the stated outcome or bundle unrelated preferences.
- Compare overlap with catalogs already selected and identify genuinely unique value.
- Estimate the cost of a mistake on school, work, health, banking, communication, and shared media tasks.
- Name an owner, exception process, rollback, and recurring review trigger before broad use.
Published scope matters more than raw size. RFC 6471 is written for email DNS-based lists, but its governance principle transfers: operators should describe listing scope and aggressiveness so users can judge risk and benefit, and listing and removal criteria should be related.4 A family should reject a catalog whose provenance is unclear, whose purpose cannot be stated, or whose correction path is absent, even if its domain count is large.
Pilot against real household tasks
Test the candidate catalog on one or two representative resources before making it the shared default. Cover school portals, video calls, software updates, streaming, banking, shopping, health services, sign-in providers, and smart-device functions actually used in the home. Confirm both expected blocks and successful required workflows. A DNS lookup test is necessary but not sufficient because the application can fail later at routing, TLS, authentication, or service policy.
Review a short evidence window for false positives and unexpected categories, then compare the catalog’s unique protective decisions with its disruption. Do not interpret a high block count as equal to human attempts. RFC 9076 explains that DNS requests can be secondary or resolver-generated, and applications routinely make background lookups.3 Measure completed household outcomes and justified exceptions, not an impressive total.
DNS filtering acts on hostname lookups and resulting policy decisions. It cannot inspect URL paths, page contents, typed searches, files, messages, voice audio, video content, or full browser history. Therefore a catalog cannot enforce screen time, distinguish pages on one domain, or explain every action inside an app. Use browser, account, application, and device controls for those jobs rather than making the DNS baseline progressively broader.
Write down the accepted baseline so later changes are deliberate. Record the shared purpose, catalog sources, categories included, resources covered, owner, rollback, and review date. When a new household need appears, decide whether it changes the shared minimum or belongs to one resource. This prevents a temporary child, guest, or work-device rule from quietly becoming permanent policy for everyone.
Questions about a family baseline catalog
Should a family baseline block social media and games?
Only if every resource in the family Space should share that rule. Otherwise, put the restriction on the relevant child or device resource instead of treating a household preference as universal security.
Should adult-content domains be part of the family baseline?
They can be when the household has an explicit shared boundary. If adults, guests, or work devices need different access, use narrower resource policy and explain the rule rather than silently applying it to everyone.
Can a baseline DNS catalog replace parental-control apps?
No. DNS can make domain-level decisions, but it cannot manage screen time, app permissions, messages, page content, search terms, or activity inside a service. Use the control that matches each job.
Shape the family Space baseline in Veilty
In Veilty, assign reusable baseline and enforced policies to a family Space. Put shared, flexible defaults in baseline policy; a resource in that Space may override the baseline for a justified local need. Put only non-negotiable requirements in enforced Space policy, which resources cannot weaken. Add child, work, guest, or device-specific catalogs at resource scope when their purpose is not shared by everyone.1
Invitations are account-scoped and grant no Space access on their own. After acceptance, assigned Space roles govern who can manage protection or open retained activity. Saved history belongs to its Space and is end-to-end encrypted with user-held keys; only members permitted by role can read it, while the resolver must process live DNS requests. Start by writing one sentence for the household baseline, then retain only the catalogs that serve it.