A new DNS policy should usually begin with log-only observation when its dependencies or likely impact are uncertain. Define the proposed rule, affected Space or Tenant resources, success criteria, privacy limits, owner, and end time first. Review matched domains, prepare narrow baseline exceptions, then enforce in stages while mandatory enforced policy remains authoritative.
Observation is a test, not a destination
Log-only mode evaluates what a proposed rule would match without applying its new block, allow, or redirect outcome. It is valuable when a category is broad, a business application has poorly documented dependencies, devices have different roles, or a team cannot predict the blast radius. It is unnecessary for every small change. A verified malicious domain may already be covered by mandatory enforced policy, while a single well-understood baseline correction may need only a focused test.
Observation becomes harmful when it has no question or stopping condition. Collecting DNS activity indefinitely “just in case” increases privacy exposure and produces a large stream that reviewers cannot interpret. Before enabling visibility, state the decision it will support: for example, “Would blocking this newly risky category interrupt payroll, identity, or customer-support workflows for these finance resources?” The answer should lead to enforcement, a narrower rule, or abandonment of the proposal.
DNS activity is limited evidence. It can show domain lookups and policy outcomes, but it cannot reveal URL paths, page contents, search terms, files, in-app chats, voice audio, or full browser history. A lookup also does not prove a connection completed or identify which person intended it. RFC 9499 describes DNS as a query-response protocol.5 Keep conclusions inside that boundary.
Write the enforcement hypothesis first
| Field | Concrete entry | Weak entry |
|---|---|---|
| Proposed action | Block one named category | Improve security |
| Boundary | Selected resources in one Space or Tenant | Everyone |
| Protected workflows | Payroll, sign-in, support, schoolwork | Normal use |
| Evidence | Matches plus completed task tests | No complaints |
| Privacy limit | Named roles, fields, retention, purpose | Admins can see logs |
| End | Date and decision owner | Until confident |
Choose resources because they represent real policy differences, not because they are convenient volunteers. Include an ordinary device, a resource with critical dependencies, and a resource expected to match the rule. Keep household and team contexts separate. A family Space may need a homework cycle and shared television state; a team Tenant may need identity, communication, finance, deployment, and remote-work paths. Do not mix their evidence into one account-wide conclusion.
Define both sides of success. The proposed category or domain should match as expected, and ordinary required work should remain unaffected after enforcement. Include rollback criteria such as loss of sign-in, payment, update, or emergency communication. Name the role that can pause rollout, the role that approves an exception, and the policy owner who decides whether a mandatory enforced rule should change.
Collect the smallest useful window
- Confirm each test resource uses the intended resolver and policy path; account for VPNs, browser secure DNS, mobile data, and captive portals.
- Enable observation only for the proposed rule and selected Space or Tenant resources where the platform permits.
- Limit retained fields, roles, and duration to what the stated decision requires.
- Run every named workflow and record its start time, result, and expected external provider.
- Review matched domains in context, verify ownership, and separate required dependencies from unexplained background activity.
- End collection on schedule, document the decision, and delete or age out evidence that no longer serves the purpose.
A longer window is not automatically better. It may add weekends, travel, updates, or batch jobs that matter, but it also adds unrelated activity. Extend only to capture a named missing condition. NIST’s Privacy Framework treats governance, data processing, and risk management as connected work; a purpose-bound collection window applies that principle directly.4 Tell affected people what is being evaluated and who can review retained evidence where appropriate.
Turn matches into reviewed decisions
Sort observations into four decisions: expected block, required dependency, uncertain background lookup, and wrong policy scope. An expected block supports enforcement but still needs a harmless verification plan. A required dependency needs an exact allowance at the narrowest resource boundary. An uncertain lookup needs ownership research or another focused reproduction, not a guess. A wrong scope means the rule belongs on fewer resources or in a different Space or Tenant.
Frequency is context, not verdict. A telemetry hostname can appear thousands of times without being business-critical; an annual tax or certificate-renewal service can appear once and be essential. Connect each exception to a completed task and accountable owner. If no one can explain a match, do not automatically allow it, but do not treat the hostname as malicious either. Enforce first on a pilot resource and watch the real workflow.
Prepare exceptions before enforcement, but activate only those supported by evidence. Each should state domain, resource, purpose, owner, review condition, and rollback. Put shared normal behavior in reusable baseline policy assigned to the relevant Spaces or Tenants. Reserve reusable enforced policy for mandatory rules that no attached resource may weaken. Log-only testing should clarify that distinction, not create a shadow policy beside it.
Enforce with a two-sided check
Move from observation to enforcement on one representative resource first. Confirm an expected blocked result using a safe test, then complete every protected workflow. A policy that blocks nothing may be on the wrong resolver path; a policy that blocks the target but breaks authentication is not ready to widen. Compare the pilot with an unchanged resource so network or provider failures are not mistaken for policy effects.
Widen by coherent resource group rather than by account. Pause when a rollback criterion appears, capture the exact time and name, restore the last known-good narrow state, and investigate. After a stable review window, close the log-only test and schedule a policy review. Protective DNS aims to prevent connections to known or suspected malicious infrastructure based on DNS queries; staged enforcement should preserve that outcome without turning every uncertain dependency into a permanent allowance.3
Log-only rollout questions
How long should a DNS policy stay in log-only mode?
Long enough to observe the workflows and device states named in the test, including a normal work cycle, but no longer than needed. Set an end time before collection begins; extend it only for a specific missing scenario.
Does a log-only match prove that enforcement would block a person?
No. A match shows that a domain lookup met the proposed rule. It may come from a background service, cached workflow, or shared device, and it does not identify a person’s intent. Reproduce the real task before deciding.
Can log-only testing weaken enforced Space or Tenant policy?
No. Use observation to evaluate a proposed baseline or additional rule. Existing enforced policy assigned to a Space or Tenant remains authoritative and cannot be weakened by a resource, test profile, or local exception.
Move one Veilty boundary from evidence to policy
In Veilty, pilot the proposed rule on selected resources inside one household Space or team Tenant. Keep reusable baseline and enforced policies assigned to Spaces or Tenants: a resource may override its baseline for a justified dependency, but it cannot weaken enforced policy. Invitations are account-scoped and grant no Space or Tenant access by themselves; after acceptance, assigned roles govern 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. Define one test charter before enabling a review window.12