Free public DNS filtering is enough when everyone in scope can use the same provider-defined domain policy, occasional false positives are tolerable, and you do not need named profiles, local exceptions, accountable changes, or retained evidence. Choose managed policy when different people or devices need distinct rules, verified outcomes, or an owned review process.
The useful outcome is an upgrade decision based on work, not a feature-count contest. Write down the policy result you need, test the free option against it, and pay for management only when an uncovered requirement has a named owner and measurable cost.
Define enough as an outcome
Begin with one sentence: “Reduce contact with known malicious domains on every device using this guest network,” or “Apply a stricter domain category to a child resource without changing the adult profile.” The first may fit a fixed public filtering resolver. The second requires identity or scope, distinct policy, and an exception path. Vague goals such as “make DNS safer” cannot expose the management gap.
Compare actual services rather than assuming every free or managed product behaves alike. Check the provider’s stated categories, privacy policy, encrypted transports, availability commitment, correction channel, and supported ways to identify a network or resource. RFC 9076 notes that recursive-resolver choice has direct privacy consequences and that resolver operators can observe sensitive query transactions.2 Free does not mean careless, and paid does not prove fit.
| Requirement | Public filtering can be enough when | Managed policy earns its place when |
|---|---|---|
| Policy scope | One fixed policy fits the whole scope | People, devices, or locations need distinct policy |
| Exceptions | Provider correction is acceptable | Local, narrow exceptions need owners and review |
| Evidence | A safe test proves the shared outcome | Teams need winning-rule and resource-level verification |
| Operations | Best-effort service meets the impact | Support, roles, continuity, or change history matter |
| Privacy | Published handling terms meet the purpose | Access and retention must match named roles and windows |
Recognize the public-resolver fit
A public filtering resolver is a strong low-operations choice for a uniform boundary: a guest network, a simple household, a temporary lab, or a device set that needs the same provider-maintained malicious-domain protection. It can remove the work of running a recursive resolver or curating intelligence. If its documented policy and privacy terms meet the job, simplicity is a benefit rather than a missing feature.
Prove path coverage before judging the filter. Browsers, operating systems, VPNs, and applications can select encrypted resolvers independently. DNS over HTTPS and DNS over TLS protect transport to the selected resolver; they do not ensure that the selected resolver applies your intended policy.12 Test a supported, provider-owned blocked domain and an ordinary allowed domain from each representative network context.
Price the management gap
Managed policy becomes useful when the policy has differences that must survive change. Examples include child and adult profiles, finance and general-team resources, enforced protection that local admins cannot weaken, exact exceptions for required services, or a rule that must follow an identified device across networks. The purchase is not “more DNS.” It is scoped policy, accountable operation, and evidence about which rule produced an outcome.
Assign a cost to each missing capability. Count time spent diagnosing false positives, repeated manual changes, work blocked by an unowned exception, devices that leave the protected network, and audits that cannot establish the effective policy. Ignore dashboard features without an owner or decision attached. A managed console that nobody reviews is overhead, not control.
Keep visibility proportional. Start with coverage, resolver health, aggregate allow or block outcomes, and safe tests. Open detailed activity only for a named problem, affected resource, and short window. DNS filtering can act on domain lookups and policy outcomes; it cannot read page contents, search terms, in-app chats, voice audio, full URLs, or full browser history. Queries may also come from prefetching and background software, not a deliberate visit.2
Run a two-week decision pilot
- Name one domain-level outcome, representative resources, networks, and the person who owns the decision.
- Record nonnegotiable requirements for policy differences, privacy, exceptions, evidence, availability, and support.
- Run the public resolver first when it plausibly meets those requirements; test one allowed and one provider-owned blocked domain.
- Repeat after a network change and after a fresh lookup so caches or open connections do not disguise the resolver path.
- Log gaps as concrete events: wrong scope, unresolved false positive, missing policy continuity, or evidence unavailable to an authorized owner.
- Compare managed policy only against those gaps, then choose the least complex option that consistently owns the outcome.
Use harmless domains and ordinary workflows. Do not deliberately visit malicious sites to test a security category. Preserve just enough evidence to explain the decision: expected policy, observed resolver, returned outcome, time, and whether normal work succeeded. Remove temporary detail when the pilot closes.
Reject misleading upgrade signals
- Do not upgrade merely because a managed list has more domains; relevance and correction quality matter more than raw count.
- Do not stay free merely because the resolver blocks a test domain; path coverage and exception ownership may still fail.
- Do not infer human intent from a blocked-query total or preserve broad activity history “just in case.”
- Do not expect DNS policy to replace content inspection, app approval, endpoint management, a VPN, or firewall flow control.
- Do not mirror the same rule across tools; name one authoritative owner for each policy outcome.
Public-or-managed questions
Does paying for DNS filtering make the blocking more accurate?
Not automatically. Accuracy depends on policy sources, classifications, correction practice, and the use case. Managed service earns its cost through control and accountability you use. Pilot representative domains and ordinary work rather than treating price as proof.
Is a free public resolver suitable for a small household?
It can be when one shared policy fits and person-specific exceptions or history are unnecessary. It is a poor fit when children and adults need different boundaries, a false positive affects school or work, or policy must follow an identified resource away from home.
Can either option show exactly what a person viewed?
No. A resolver may see domain lookups and outcomes, not page contents, full URLs, searches, messages, voice audio, or complete browser history. Background apps and embedded resources also generate queries, so DNS events are not a record of intent.
Map one Veilty policy decision
In Veilty, map the uncovered requirement to one resource, rule or assigned filter set, and reusable baseline or enforced policy inside the household Space or team Tenant that owns it. A resource may override baseline policy when permitted but cannot weaken enforced policy. Retained DNS activity belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted roles, while the resolver necessarily processes live requests. Pilot one representative resource, verify the winning rule and outcome, and upgrade only if that managed difference solves a documented gap.