Use DNS metrics for routine health, trends, and policy outcomes; use DNS logs when a named incident or support question requires request-level evidence. Start with aggregates, define the question and time window, then open only the details needed to answer it. This produces useful visibility without making sensitive domain activity the everyday view.
The choice is not “more data or less data” in the abstract. It is a resolution decision. A count of blocked requests may be enough to spot a policy change. A single failed payroll sign-in may require the exact hostname, affected resource, matching rule, and time. Good operations move deliberately between those levels instead of leaving everyone in raw activity.
Let the question set the resolution
| Question | Start with | Escalate when |
|---|---|---|
| Did blocking rise after a policy change? | Outcome totals and trend by policy | A narrow sample is needed to find the affected rule |
| Is the resolver healthy? | Success, failure, and latency measures | One endpoint or request path behaves differently |
| Why did one application fail? | Time-bounded outcome for the affected resource | The exact domain and rule are needed to reproduce it |
| Is a threat pattern recurring? | Counts by category and bounded scope | Incident handling requires request-level evidence |
Write the question before opening a dashboard. Name the affected Space or Tenant, resource, approximate time, and decision to be made. “See what happened” is too broad. “Determine whether the finance device was blocked by the new threat policy between 09:00 and 09:10” supplies a boundary and a stopping condition.
What aggregates answer well
Metrics compress events into measures such as request volume, allowed and blocked outcomes, error rates, latency, category totals, or the share of resources receiving a policy. They are well suited to baselines and comparisons: before versus after a rule change, one protected boundary versus another, or this week versus a normal range. They also reduce the temptation to treat individual domains as a routine management feed.
Aggregation is not automatically anonymous. A metric narrowed to one person, one device, and one minute can be nearly as revealing as a row. Rare categories or tiny groups can also expose behavior by inference. Keep dimensions broad enough for the operational purpose, suppress unnecessary breakdowns, restrict viewers, and avoid exporting a private activity trail under a friendlier label.
The moment request detail earns its place
Detailed activity becomes useful when the decision depends on a particular domain lookup, policy match, resource, or timestamp. Examples include reproducing a false positive, confirming which rule caused a block, separating an application dependency from its main domain, or collecting bounded evidence during a security incident. Open the smallest relevant slice rather than beginning with an account-wide search.
RFC 9076 warns that DNS traffic can reveal sensitive information and that requests may be generated by applications, background activity, or prefetching rather than an intentional user action.1 That makes a detailed row evidence about a lookup, not a verdict about a person. Correlate it with the reported symptom, device state, application logs, and policy change record before acting.
A two-stage visibility workflow
- Name the decision, affected Space or Tenant, resource, approximate time, and owner of the review.
- Check aggregate health and policy outcomes first. Compare the smallest useful scope with its normal baseline.
- If aggregates answer the question, document the result and stop. Do not open detailed activity for confirmation theater.
- If detail is necessary, limit the fields, viewers, resource scope, and time window before opening it.
- Reproduce the real workflow, confirm the matching policy outcome, and test an unaffected resource or known block.
- Record the conclusion, close the detailed view, remove diagnostic exports, and review whether the metric view can answer the same question next time.
Choose the least broad policy action as carefully as the least broad evidence. If one resource needs a justified allowance, do not relax an entire Space or Tenant. If observation alone answers the question, do not redirect or block. Give temporary exceptions an owner and review condition, then verify both the intended recovery and the protection that should remain.
Read the result without overclaiming
A successful DNS answer does not prove that a connection completed, a login worked, or content loaded. A blocked answer does not prove that a person intentionally requested the domain. Caches can mean an application succeeds without a new visible lookup, while encrypted DNS or another resolver path can mean expected activity never reaches the chosen service. Test from the affected endpoint and follow the application outcome.
DNS filtering acts on domain lookups and policy outcomes. It cannot inspect URL paths, page contents, search terms, form data, in-app chats, voice audio, or full browser history. When a decision depends on identity, process behavior, files, or content inside a service, use the appropriate endpoint, identity, application, browser, or security evidence instead of stretching DNS activity beyond its meaning.
Logs and metrics questions
Can metrics replace DNS logs completely?
No. Metrics can show rates, totals, trends, and policy outcomes, but they usually cannot identify the exact request behind one failure. They are the better default view, not a universal substitute. Escalate to detailed activity only when the question genuinely depends on a domain, resource, rule, or timestamp.
How long should detailed DNS activity stay open?
Only for the shortest window that can answer the named question. Start near the reported event, expand carefully if evidence requires it, and close the review when the result is documented. Retention and access should follow the same purpose rather than remaining broad for possible future curiosity.
Do DNS logs prove what a person did online?
No. A DNS record shows that a lookup occurred in a particular technical context. Browsers, apps, background services, prefetching, shared resolvers, and caches complicate attribution. The record does not prove intent, a completed connection, a page visit, or what someone read, searched, sent, watched, or said.
Keep the escalation bounded in Veilty
In Veilty, start with aggregate outcomes for the relevant family or personal Space, or the relevant team Tenant. If a named question requires detail, open only the retained history for that boundary and the shortest useful period. Invitations are account-scoped and grant no Space or Tenant access by themselves; access begins only after an appropriate role is assigned. Reusable baseline and enforced policies are scoped to Spaces or Tenants: resources may override baseline policy for a justified difference, but never enforced policy. Retained history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is available only through permitted roles; the resolver still processes live DNS requests to answer them. Review one current dashboard question, decide whether a metric answers it, and document the condition that would justify opening detail.23