Protective DNS should answer security questions, not become a feed for judging employees. Begin with a written purpose, prefer aggregate outcomes, and restrict detailed retained activity by role and time. Tell the team what is collected and what DNS cannot reveal. When an investigation ends, record the result and return visibility to the minimum needed for routine operation.
Draw a purpose boundary before logging
A founder may need to know whether managed laptops use the intended resolver, whether a threat category blocked a known-dangerous domain, or why an essential service stopped resolving. Those are bounded operational questions. “See what everyone is doing” is not. It has no finish line, invites interpretation beyond the evidence, and turns a useful control into an open-ended monitoring program.
Write the purpose in one sentence before choosing retention: “Confirm that work devices use protective DNS and investigate high-confidence security blocks or reported false positives.” Then list exclusions. Do not use DNS events for productivity scoring, attendance, curiosity about individuals, or assumptions about intent. NIST describes privacy risk management as a way to help organizations manage risks arising from systems that process data; that discipline applies even when collection begins for security.3
| Question | Start with | Escalate only when |
|---|---|---|
| Is coverage working? | Endpoint coverage and test results | A named device fails its safe test |
| Did policy act? | Aggregate block and redirect counts | A high-confidence event needs follow-up |
| Is work broken? | User report and rule identity | The affected domain must be diagnosed |
| Is there an incident? | Alert, device, and time window | The response owner documents a reason |
Separate security signals from personal judgment
DNS filtering evaluates domain lookups. It cannot read page contents, search terms, in-app chats, voice audio, or full browser history. It also cannot reliably identify the human behind every request. Browsers prefetch names, applications retry in the background, shared devices serve several people, and a page can contact many supporting domains without a deliberate click. RFC 9076 warns that DNS data can reveal sensitive associations, which is a reason to minimize it rather than overstate its meaning.4
Treat a block as a technical signal. A repeated command-and-control classification may justify endpoint investigation. A blocked vendor dependency may justify a false-positive review. Neither event proves misconduct. Combine DNS evidence with endpoint, identity, email, and human context, and give the affected person a clear way to explain or report what happened. CISA positions protective DNS as one layer that prevents connections to known or suspected malicious destinations, not as employee-behavior analysis.2
Write a five-part DNS privacy charter
- Name the security purpose and the devices or networks in scope. Keep personal devices outside unless participation is genuinely necessary, transparent, and agreed.
- Describe the evidence honestly: domain lookup, device or resource identity where configured, time, policy, and outcome. List the content DNS never sees.
- Choose aggregate metrics for routine checks. Define the exact triggers that permit a role-authorized reviewer to open detailed retained activity.
- Set retention and review dates. A short incident window should not silently become permanent history “just in case.”
- Publish an exception, correction, and complaint path. People should know who can fix a false positive and who can challenge inappropriate use.
Share the charter before rollout and whenever scope changes. Use plain examples: a malware-domain block may be reviewed; ordinary allowed requests are not a productivity report; personal browsing on an unmanaged personal connection is outside the program. A short, specific notice builds more trust than a long policy that reserves every possible right. Ask a local privacy or employment adviser about jurisdiction-specific duties rather than presenting a technical setting as legal consent.
Give the charter an operational owner as well as an executive sponsor. The owner should review access after role changes, answer employee questions, and report misuse without having to defend the monitoring program. Include contractors and temporary workers in the notice when their work resources are covered. When a provider, resolver path, retained field, or retention period changes, treat that as a scope change and communicate it before relying on the new evidence.
Respond with the least visibility needed
- For routine health, review resolver coverage, safe-test success, aggregate protection outcomes, unresolved false positives, and exceptions due for review.
- For a broken application, start with the employee report, affected device, time, and blocking rule; inspect only the shortest relevant activity window.
- For a credible threat, assign an incident owner, preserve only relevant evidence, and move to endpoint or identity tools when the question exceeds DNS.
- At closure, record the decision, remove temporary access or exports, narrow any exception, and let unnecessary detail expire.
Audit the process itself. Each quarter, ask whether every retained field still serves the stated purpose, whether access still matches current roles, and whether incidents were resolved with less detail than expected. Report system lessons such as a stale resolver deployment or an overly broad category. Do not publish employee rankings based on query or block counts; job roles, automatic software, and retry behavior make those numbers misleading.
Trust-centered DNS questions
Can a DNS log show what an employee read on a website?
No. DNS can record a requested domain and policy outcome, but it cannot show page contents, search terms, messages, voice audio, or full browser history. A domain request also does not prove why a person or background application requested it.
Should a small team retain every allowed DNS request?
Usually not. Start with coverage and aggregate allow, block, and redirect outcomes. Enable or inspect detailed retained activity only for a named operational or security question, with limited access and a defined end date.
Who should be able to review detailed team activity?
Only people whose Tenant role and current responsibility require it. The team should document the purpose, avoid casual access, record the conclusion, and close the detailed review when the question is answered.
Apply the boundary in Veilty
In Veilty, place work resources in the appropriate Tenant. Baseline and enforced policies are reusable across Tenants. Within this Tenant, a resource may override baseline policy, while enforced policy takes precedence and cannot be weakened. Begin with aggregate outcomes. If retained activity is enabled, use the shortest period that answers the named question; saved Tenant activity is end-to-end encrypted, and access follows Tenant roles, while the resolver still processes live requests. Invitations are account-scoped, so assign a Tenant role separately when someone needs this Tenant’s controls or retained history. Test one endpoint, publish the review purpose, and verify an expected block plus ordinary work before expanding.1