No. Log-only DNS does not block a request, but it still processes and may retain privacy-relevant domain activity. Before observing, define a specific purpose, narrow resource scope, permitted roles, minimum evidence, retention period, review trigger, and deletion step. Stop collecting when the question is answered, and never treat a query as proof of human intent.
Observation is still a policy choice, even without blocking
Log-only is useful when enforcement would be premature. A team may need to identify a vendor dependency before tightening policy. A household may want to understand why one device repeatedly fails without blocking other devices. An operator may observe a new domain category long enough to measure false positives. In each case, observation can reduce guesswork, but it creates a separate decision about whose activity is in scope and what evidence is retained.
DNS queries can be privacy-relevant. RFC 9076 explains that transactions expose query contents and origin information to a resolver, that linked queries can reveal patterns, and that browsers or applications may generate lookups without explicit user action.4 A log-only result therefore should be described as a device or resource requesting a domain at a time, not as proof that a person intentionally visited, read, searched, or communicated.
DNS filtering and observation operate on domain lookups and policy outcomes. They cannot see URL paths, webpage contents, search terms, files, in-app chats, voice audio, or full browser history. They also cannot prove that a connection, login, purchase, upload, or other application task completed. Keep interpretation inside those limits and choose a different control when the question requires page-level or application-level evidence.
Write seven privacy decisions before the first retained event
| Decision | Useful definition | Weak substitute |
|---|---|---|
| Purpose | One operational or safety question | Just in case |
| Scope | Named Space or Tenant resources | The whole account |
| Fields | Minimum domain, time, outcome, and resource context | Everything available |
| Access | Roles responsible for diagnosis or review | All administrators |
| Retention | Period tied to the question | Forever |
| Review | Owner and end condition | Someone will check |
| Deletion | Named closeout action | Passive expiry assumption |
Purpose controls every other field. “Find which hostname the payroll client needs during Monday’s test” supports a short window on one team resource. “See what everyone does” is not a bounded operational question. Record the question in language the affected people can understand, name the reviewer, and state what result will close the observation.
Data processing includes collection, logging, retention, use, disclosure, and disposal. NIST’s Privacy Framework treats privacy risk across that complete lifecycle and among different organizational roles.3 A privacy rule must therefore govern not only whether activity is saved, but who can use it, what conclusions are appropriate, where the result is shared, and how both raw evidence and copied notes are removed.
Run a purpose-bound observation instead of an open-ended feed
- Write the question, affected task, resource scope, owner, and stop condition.
- Confirm the resource uses the intended resolver and note other DNS paths that could affect evidence.
- Check its Space or Tenant baseline and enforced policies before interpreting an outcome.
- Retain only the fields and time window needed to distinguish the suspected dependency.
- Limit access to roles that diagnose, approve, or review this specific question.
- Reproduce the task and compare its result with the observed domain outcome.
- Summarize the conclusion, close the observation, and execute the deletion step.
Do not start with every device because one workflow is unclear. Use the narrowest resource that can reproduce the issue, then expand only when evidence shows the dependency is shared. Do not use live malicious infrastructure for validation. If a harmless test domain is available from the relevant provider, use it alongside an ordinary allowed domain and the real workflow.
Separate the observed fact from the inference. “Resource A requested api.vendor.example at 09:10 and the policy returned allow” is an observation. “A person used the vendor application” is an inference that may be wrong because of caching, prefetching, background processes, shared devices, or automated retries. Use the application’s own authorized evidence when the business decision depends on an application action.
Close the observation window as deliberately as you opened it
At the stop condition, answer the original question in the smallest useful summary. If the evidence supports a rule change, document the affected hostname, resource, policy outcome, and test. If it does not, state that the observation was inconclusive rather than extending collection indefinitely. Delete raw evidence and duplicate notes according to the rule, then confirm that log-only behavior is no longer active for that purpose.
Renewal should be a new decision, not an automatic continuation. Reconfirm purpose, scope, permitted roles, fields, retention, and notice. If the same question recurs, fix the ownership or verification process rather than building a permanent observation feed around a temporary diagnostic need. Responsible visibility is enough evidence to make the decision, held by the fewest appropriate people, for the shortest useful time.
Questions about log-only DNS privacy
Is log-only DNS harmless because it does not block anything?
No. It may still collect domains, times, resource context, and policy outcomes that reveal patterns. The absence of enforcement does not remove the need for purpose, access, retention, and deletion rules.
How long should log-only DNS evidence be retained?
Keep it only long enough to answer the stated question and complete review. Set the end condition before collection, then delete or deliberately renew the observation with a new justification.
Does a DNS log show what a person did on a website?
No. It can show a domain lookup and related context, not URL paths, page contents, search terms, files, chats, voice audio, full browser history, or reliable proof of human intent.
Use private retained history with explicit Veilty roles
In Veilty, attach observation to the narrowest resource inside the relevant household Space or team Tenant. Reuse baseline and enforced policies across Spaces or Tenants: a resource may override its boundary’s baseline, but it cannot weaken enforced policy. Invitations are account-scoped and grant no Space or Tenant access; accepted members need assigned roles for controls and retained activity. Saved history 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 still processes live DNS requests. Begin with one diagnostic question and write its purpose, roles, retention, stop condition, and deletion step before retaining activity.12