Review risky DNS activity as an investigation into a system, not a contest between people. Define one security, coverage, or reliability question; begin with aggregate policy outcomes; and reveal detailed history only when the answer requires it. A lookup is technical evidence that needs context, never proof of carelessness, intent, or compromise by the person using the endpoint.
Start with an incident question, not a ranking
A dashboard that ranks people by blocked requests looks decisive, but it usually measures the wrong thing. One design application may retry a blocked analytics domain hundreds of times. A browser tab can request advertising, tracking, and content-delivery domains without a deliberate click. A security agent may query known-bad domains as part of its own work. Raw volume does not establish intent, carelessness, or compromise.
NCSC describes protective DNS as a service that uses threat intelligence to prevent access to malicious domains and provides organizations with information about blocked attempts.3 That information is valuable when it leads to containment or policy correction. It becomes counterproductive when it is repurposed as a productivity score or a public measure of individual judgment.
| Avoid | Ask instead | Minimum useful evidence |
|---|---|---|
| Who is the riskiest person? | Did a known threat reach a work endpoint? | Blocked outcome, endpoint, time, rule |
| Who wastes time online? | Is a policy disrupting an approved workflow? | Affected service, narrow time window, policy action |
| Who keeps breaking rules? | Is one device bypassing the intended resolver? | Coverage test from that endpoint and network |
Write down the question, reviewer, Tenant, affected endpoints, evidence needed, and closing condition before opening detailed history. If the purpose changes, close the first review and authorize a new one rather than letting a narrow investigation become general observation. A visible, repeatable boundary makes security review easier to defend and easier for the team to trust.
Read a DNS event without inventing a story
A DNS event can show that an endpoint asked a resolver for a domain and that a policy allowed, blocked, or redirected the lookup. It cannot show the page contents, search terms, in-app chat, voice audio, full browser history, or why the request happened. It also cannot prove that a later connection succeeded. Encrypted DNS, VPNs, browser-specific resolvers, cached answers, or direct IP connections can move activity outside the expected path.
Managed DNS services commonly separate device identity, query activity, filtering rules, and troubleshooting. That structure supports a sound review habit: identify the endpoint and policy path before interpreting a category label. Confirm the resolver actually handled the request from that endpoint, then use the smallest relevant activity window. A label is classification evidence, not a complete incident report.
- Confirm the endpoint used the intended resolver at the reported time.
- Check whether the request was allowed, blocked, or redirected and which rule decided it.
- Look for a small time pattern, not a person-wide browsing narrative.
- Ask whether an application or page dependency could explain background requests.
- Use endpoint security or incident evidence to determine what happened after DNS.
- Speak privately with the person when their context can resolve uncertainty.
Use a purpose-bound review ladder
- Review aggregate allowed, blocked, and redirected outcomes. Look for changes that affect protection or work.
- If a change matters, select one named security, coverage, or compatibility question.
- Choose the shortest relevant Tenant history window and the smallest set of endpoints.
- Have an authorized role inspect only the fields needed to answer the question.
- Corroborate the signal with resolver coverage, endpoint alerts, service status, or the user’s account.
- Record the decision: false positive, expected application behavior, coverage fault, or incident follow-up.
- Close detailed review, remove exported notes that are no longer required, and schedule the policy fix.
CISA positions protective DNS as one layer that blocks malicious destinations and supports incident response.2 Keep endpoint protection, multifactor authentication, updates, backups, email controls, and staff reporting alongside it. If a lookup suggests malware, inspect the device through the incident process. Do not ask DNS data to prove device health.
Turn findings into safer defaults
The best review reduces the need for another one. Repair the resolver path on an uncovered laptop. Narrow an exception to the required domain instead of allowing a whole category. Correct a misleading classification. Remove obsolete software that retries a suspicious destination. Add a safe verification step for invoice or credential requests. Share the system improvement without identifying a person unnecessarily.
Set a monthly check for coverage, false positives, exception ownership, and unusually broad rules. Retire stale exceptions and document why the remaining ones exist. Share system-level lessons without turning them into personal performance commentary. A healthy program measures whether controls work and whether people report concerns early. It does not reward a perfectly quiet log, which can also mean missing coverage.
Respectful DNS review questions
Does a blocked domain prove that an employee clicked something risky?
No. Applications make background requests, pages load third-party domains, and a protective resolver may block before any connection succeeds. A DNS event records a lookup and policy outcome, not a person’s motive or the full sequence of actions.
Who should be allowed to see detailed DNS activity?
Only people with a defined operational or security need. Use roles to limit access, begin with aggregate measures, and open the shortest detailed window needed to answer a documented question.
Should teams publish block counts by person?
Usually not. Counts are strongly affected by device software, background retries, workload, and policy scope. Public rankings encourage false conclusions and can discourage early reporting of mistakes.
Make visibility purpose-bound in Veilty
In Veilty, begin with aggregate outcomes for a Tenant. For a named question, use Tenant roles to limit who may open the relevant retained history and close the review when answered. Retained activity and summaries are end-to-end encrypted; the resolver still processes live DNS requests to answer them. Apply reusable baseline or enforced Tenant policies where appropriate, keep exceptions narrow, and review the system change rather than publishing a blame list.1