Log DNS activity instead of blocking when the domain’s purpose, dependency, or risk is uncertain and an immediate refusal could disrupt legitimate work. Define one question, one resource group, and a short observation window first. Review only the evidence needed, then block, allow, narrow, or close the investigation rather than retaining indefinite history.
Let uncertainty choose observation first
Blocking is appropriate when the risk and intended population are understood. Logging is better when the key fact is missing. A newly observed hostname may be a tracker, a software-update dependency, a content-delivery host, or an embedded service used by several applications. Refusing it immediately can create an outage without answering what it did. A short observation can connect the request to a reproducible task and reveal whether a narrow decision is possible.
Use the cost of error to set the starting point. A confirmed malicious domain tied to an active incident normally should be blocked rather than watched. CISA describes protective DNS as preventing connections to known or suspected malicious infrastructure.2 By contrast, an unfamiliar hostname that appears during payroll submission or a family health appointment may justify observation because an incorrect block has a serious consequence. Logging is not hesitation; it is a controlled way to gather the missing evidence.
| Situation | Better starting point | Reason |
|---|---|---|
| Confirmed malicious infrastructure | Block | Delay preserves known exposure |
| Unknown application dependency | Log narrowly | Evidence can prevent an outage |
| Known required service falsely matched | Allow narrowly | The dependency and owner are verified |
| Broad category under evaluation | Pilot and observe | Impact varies by resource and workflow |
Define a small evidence window before collecting
- Write the single question the observation must answer, such as which hostname a specific sign-in flow requires.
- Choose one affected resource or purpose-based group rather than every device in the account.
- Set a start, an end, and an operational trigger that reproduces the normal workflow.
- Collect the minimum fields needed to identify the domain, time, resource, action, and matching rule.
- Name the Space or Tenant role allowed to review retained detail and the reason for access.
- Decide in advance whether the possible exits are block, allow, narrower observation, or no policy change.
Do not begin with “collect everything for a month.” Start with the shortest period that contains the real task, including a normal update, scheduled job, or workday cycle when relevant. Inspect aggregate allow and block outcomes first. Open resource-level detail only if the aggregate cannot answer the named question. Stop when the result is sufficient, even if the original window has time remaining. Evidence collection has a completion condition, not merely a retention setting.
Turn evidence into a reversible decision
Reproduce the workflow while the window is open and mark the relevant time. Confirm that the resource used the intended resolver; a browser, VPN, mobile network, or operating-system encrypted DNS choice may have taken another path. Identify the exact hostname and verify its operator or service relationship through a primary source where possible. Then ask whether the request was necessary to complete the task, merely adjacent background traffic, or still unexplained.
Make the next change reversible. Apply a proposed block to one representative resource, verify a harmless blocked result, and complete important workflows. Apply a proposed allowance only to the resource that owns the dependency, then remove it once to confirm the failure returns. If evidence stays ambiguous, do not convert uncertainty into an account-wide rule. Close the window, document what remains unknown, and choose a more suitable browser, endpoint, identity, application, firewall, or network control if the decision requires context DNS cannot carry.
Protect people while interpreting DNS records
DNS activity is both sensitive and incomplete. RFC 9076 explains that linked DNS transactions can reveal patterns and that browsers and applications generate requests for embedded resources, prefetching, and background behavior.4 A record can show that a resource requested a domain and which policy outcome followed. It cannot prove who held a shared device, why the lookup occurred, whether a connection completed, or which page or action followed.
DNS filtering cannot see URL paths, page contents, typed searches, files, in-app chats, voice audio, or full browser history. Do not use an observation window to assess character, productivity, relationships, or unrelated behavior. NIST CSF 2.0’s Govern function emphasizes defined risk tolerances, roles, responsibilities, and policies.3 Translate that into a named operational purpose, limited reviewer role, and documented decision. Delete or age out detail when the purpose ends rather than keeping it because storage is available.
Logging-or-blocking questions
How long should a DNS observation window last?
Long enough to reproduce the named workflow across its normal cycle, but no longer. Choose an end condition before collecting and extend it only with a documented reason.
Does repeated DNS activity prove a person visited a site?
No. Applications, embedded resources, prefetching, retries, and shared devices can create repeated lookups. Treat the pattern as diagnostic evidence, not proof of a person’s intent or page view.
When should observation become a block?
Block when the domain and risk are sufficiently verified, the policy purpose is clear, the affected scope is known, and a representative test shows the refusal will not break required work.
Carry the decision into a Space or Tenant
Veilty can keep an evidence-gathering decision close to the household Space resource or team Tenant resource that owns the question. Reusable baseline and enforced policies can be assigned across Spaces or Tenants. A resource inside one may override its baseline for a justified local need, but enforced policy remains authoritative and cannot be weakened. Start with one resource and one review question; do not change shared policy until the evidence supports a durable common result.1
Account invitations do not expose a Space or Tenant. After acceptance, an assigned role governs access to that boundary, its controls, and its retained activity. Saved history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only to permitted roles. The resolver still processes live DNS requests to apply policy. Keep detailed review purpose-bound, document the resulting allow or block decision, and close the observation window.