Buyers should compare DNS logging controls by purpose: what is processed live, which fields can be retained, whether logging can be reduced or disabled, who can read details, how long data remains, and how deletion works. Prefer aggregate proof for routine operation and short, scoped detail for a named security or support question.
The practical outcome is a logging comparison that distinguishes useful operational evidence from unnecessary surveillance. A product should help an authorized person verify policy and correct mistakes without requiring every administrator to keep a permanent domain-by-device diary. Compare the actual plan and account type you would buy, because a privacy control that exists only in a different tier does not solve your job.
Write the logging job before the feature list
Start with two or three questions the retained data must answer. Examples include whether a representative device reached the governed resolver, which rule blocked a required sign-in domain, or whether a malicious-domain category produced aggregate blocks during a pilot. Name the person allowed to ask each question and the maximum useful time window. If nobody owns a decision that depends on a field, do not reward the product for retaining it.
Keep live processing distinct from retention. A resolver must process enough of a live DNS request to return an answer and apply policy. Encrypted DNS protects transport to that resolver; it does not make the resolver blind. RFC 9076 explains that resolver choice, query data, and correlation can create privacy risks, especially when transactions are retained or combined with other data.1 The buying question is what happens at every stage, not whether the word “encrypted” appears.
Compare six logging boundaries
| Boundary | Buyer question | Useful evidence |
|---|---|---|
| Collection | Which request, device, network, rule, and outcome fields exist? | A field inventory with defaults |
| Granularity | Can routine health use totals without individual domains? | Aggregate and detail views shown separately |
| Access | Who can open, export, support, or recover retained detail? | Role matrix and support-access procedure |
| Protection | How are transport, stored data, and keys protected? | A data flow naming encryption and key holders |
| Time | Can retention differ by purpose and end automatically? | Minimum, maximum, and deletion behavior |
| Account exit | What remains after export, deletion, or cancellation? | Documented deletion and backup lifecycle |
Ask whether policy administration and activity reading can be separated. A person who changes categories does not necessarily need to read detailed requests, and a support technician should not gain silent, open-ended access. For families, separate account membership from permission to open a household boundary. For teams, check whether one Tenant can be kept distinct from another. Test these controls with two ordinary roles instead of accepting a diagram.
Separate useful evidence from invasive detail
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URL paths, typed searches, in-app chats, voice audio, or full browser history. A domain request may come from a background update, embedded image, prefetch, retry, or another person using a shared device. Detailed activity can diagnose a rule, but it cannot reliably reconstruct human intent. Use browser, app, identity, or device controls when the decision depends on content DNS never receives.
That limitation changes the scorecard. A product that displays more detail is not necessarily more accurate. Prefer an effective-policy result that names the governed resource, matched rule, action, and time over an attractive “browsing history” label. Require filtering and export options that let a reviewer isolate one incident without opening unrelated household or employee activity. The smallest sufficient view is usually the more usable view.
Run a purpose-limited logging trial
- Choose one representative resource, one safe allowed domain, and one provider-owned harmless blocked test.
- Write the exact question that aggregate results should answer and the failure that would justify detail.
- Confirm the resource uses the intended resolver, then run the tests in a recorded short window.
- Have a least-privileged operator find the policy outcome without granting unrelated administrative access.
- Open detail only for that resource and interval, identify the winning rule, then close the diagnostic view.
- Test retention reduction, deletion, export boundaries, role removal, and the documented support-access path.
- Repeat with ordinary application traffic and verify that required work remains functional.
- Score how little data was needed to reach a correct decision, not how many events the dashboard displayed.
Reject privacy shortcuts in the demo
- Do not treat transport encryption as proof that stored history is unreadable to the provider or every administrator.
- Do not accept “anonymous” without asking which identifiers, network addresses, account links, and support records remain correlatable.
- Do not reward indefinite retention when the named troubleshooting job needs hours or days.
- Do not infer visits or intent from domain events; evaluate only the policy outcome DNS can support.
- Do not accept a deletion button without checking exports, backups, support copies, and account closure.
DNS logging buyer questions
Does a longer DNS log history provide better security?
Not automatically. Longer history can help an investigation that genuinely needs older evidence, but it also increases the amount of sensitive activity retained. Define the question, fields, readers, and required interval first. Routine policy health should usually rely on aggregates and short diagnostic windows rather than indefinite detail.
Does encrypted DNS mean the provider cannot see live requests?
No. DoH, DoT, and similar transports protect a request while it travels to the selected resolver. That resolver still processes the live lookup to answer it and apply policy. Buyers must evaluate transport, live processing, retained storage, keys, authorized access, sharing, and deletion as separate boundaries.
Can DNS logs show the exact page a person visited?
No. DNS activity can show a domain lookup and policy outcome, but not page contents, full URL paths, typed search terms, in-app chats, voice audio, or full browser history. Background apps, embedded resources, prefetching, and caches also make a lookup unreliable evidence of a person's intent.
Evaluate one Veilty visibility setting
With Veilty, map the test resource and shared rules to the appropriate Space or Tenant. Baseline and enforced policies can be reused across those boundaries; a resource may adapt its baseline where permitted but cannot weaken enforced policy. Keep a diagnostic exception on the narrow resource that owns the need rather than broadening shared protection.
Veilty must process live DNS requests to apply allow, block, or redirect outcomes. Retained activity and summaries belong to their Space or Tenant, are end-to-end encrypted with user-held keys, and open only through permitted scoped roles. Begin with aggregate outcomes, use a short detail window for the named test, remove unnecessary access, and compare that evidence with the control-layer guide when the question is not domain-sized.