A DNS activity review should begin with one decision: did a work device request a domain relevant to a known incident, did policy stop it, and is another response justified? It should not begin with curiosity about what everyone has been doing. Domain evidence is useful when its purpose, scope, access, and stopping point are agreed before anyone opens retained detail.
Decide what the review must prove
Resolver activity can support troubleshooting, security operations, and service health, but a founder rarely needs every available field. Write down why detail is needed, which Tenant and endpoint are relevant, who may review it, what action the evidence could justify, and when access ends. If those questions have no answer, aggregate outcomes are the more proportionate starting point.
Good questions are bounded: “Why did the design laptop lose access to the file-transfer service between 10:00 and 10:20?” or “Did any work endpoint request the domain named in this threat notice?” “What is everyone doing?” is not a security question. It invites broad interpretation, has no completion condition, and turns operational evidence into a productivity proxy.
| Start here | Use it to answer | Escalate only when |
|---|---|---|
| Resolver health and aggregate counts | Are endpoints connected and are policy outcomes normal? | A meaningful change needs explanation |
| Blocked-domain summary | Which rule or category caused the change? | A named incident or work failure remains |
| Short detailed window | Which endpoint, domain, time, and action are relevant? | Other evidence supports containment |
| Endpoint and identity evidence | Was there execution, sign-in, or data access? | The incident process requires it |
NCSC’s protective DNS guidance says blocked-request logs can support incident investigation and identify affected machines, and recommends considering how easily they integrate with existing security systems.2 That is a case for purposeful correlation, not continuous observation. Logs are most valuable when they connect a policy outcome to a ticket, endpoint alert, or known threat indicator.
Read domains as signals, not stories
A DNS record usually identifies a hostname, time, resolver response, endpoint or network context, and policy action. It does not normally reveal the full HTTPS path, words typed into a search box, content viewed after connection, messages inside an app, or whether a human initiated the request. Browsers prefetch, operating systems check connectivity, and apps contact analytics, update, and advertising domains in the background.
This distinction matters for trust. Tell the team what can be retained, why it may be reviewed, which Tenant roles can open it, and how long it remains useful. State that DNS evidence is not a proxy for hours worked or personal judgment. Where personal devices are permitted, define the work boundary instead of claiming visibility over the whole device.
A domain request is a clue about a device’s network behavior, not a verdict about a person.
Use a four-gate review
- Purpose gate: name the security or support decision and the person accountable for closing it.
- Scope gate: check connection health and aggregate outcomes first, then limit detail to one Tenant, endpoint, policy action, and time window.
- Evidence gate: confirm hostname, rule, category, response, timestamp, and timezone; consider browser preload, updates, and other background requests.
- Action gate: corroborate only as needed, take the smallest justified action, record the conclusion, and let detailed evidence expire under the stated retention rule.
Do not test with a live malicious domain. Use a provider’s documented safe test address or a domain you control. If a legitimate service is blocked, verify ownership and dependencies before allowing only the required hostname. A broad category exception may quietly remove protection from every team member and survive long after the incident is forgotten.
Close the case with corroboration
Suppose a protected laptop requests a newly classified phishing domain and the resolver blocks it. Confirm that the endpoint used the intended resolver and that the recorded action was a block. Then ask whether a reported message contained the link, whether the browser or endpoint recorded a later connection, and whether identity systems show a suspicious sign-in. Without corroboration, record a prevented request rather than declaring a compromise.
If the domain resolved because the endpoint bypassed policy, fix the DNS path before adding stricter categories. Secure DNS settings, VPNs, private relays, mobile hotspots, and manual resolvers can change where requests go. Coverage must be tested from the office, home, and travel networks used by the team. Missing visibility is first a deployment question, not proof of evasion.
- Do not infer intent from one request; seek corroborating evidence.
- Do not retain every allowed request when blocked outcomes answer the question.
- Do not give every account member access to every Tenant’s activity.
- Do not call DNS logs browser history or promise that encryption hides live hostnames from the resolver.
- Do not leave an exception without an owner, reason, and review date.
Questions founders ask about DNS logs
Do DNS logs show an employee’s browser history?
No. They can show domain lookups and policy outcomes, but normally not full URLs, page contents, typed search terms, in-app chats, voice audio, or which person deliberately requested every domain.
How long should a small team retain detailed DNS activity?
Choose the shortest period that supports a named troubleshooting, security, or compliance need. Aggregates can support routine health checks; detailed activity should not remain available merely because storage is inexpensive.
Does a blocked domain prove that a device is compromised?
No. A background process, prefetch, advertisement, stale tab, or user click can generate a lookup. Correlate the event with endpoint alerts, authentication records, timing, and a conversation before reaching a conclusion.
Keep Veilty access proportional
In Veilty, invitations add people to the account; they do not grant Tenant access. After acceptance, assign roles only for the Tenants where each person needs policy or retained-history access. Retained Tenant activity is protected with end-to-end encryption and user-held keys, while the resolver still processes every live DNS request needed to allow, block, or redirect it.1
Create a short review exercise for one pilot endpoint: trigger a documented safe block, confirm the aggregate outcome, open only the relevant event, and close the review. If the process cannot state who may look, why, and what happens next, refine the process before collecting more detail.