Incident response needs enough DNS data to identify the affected resource and time window, reconstruct the resolver decision, and correlate a domain with endpoint or identity evidence. It rarely needs indefinite, account-wide query history. Start with aggregate outcomes, open scoped detail for a named question, preserve only necessary evidence, and close access when the decision is complete.
That produces minimal incident context: evidence that helps make a response decision without turning every person and device into a permanent browsing record. NIST frames incident response as part of ongoing cybersecurity risk management, with preparation, detection, response, and recovery connected to organizational decisions.1 DNS evidence should serve that process, not become a collection goal of its own.
Start with the response question
A useful request is specific: did resource A ask the protected resolver about domain B during the alert window, and what policy result was returned? Another might ask whether multiple managed resources resolved infrastructure named in a confirmed campaign. These questions define scope, fields, audience, and time. “Keep everything in case something happens” defines none of them and creates privacy, access, and review costs.
Assign an incident owner before opening detailed activity. Record the alert that justifies access, the affected Space or Tenant, the shortest useful interval, authorized reviewers, and the decision the evidence will support. If aggregate blocked-domain counts or an endpoint alert already answer the question, stop there. More data is not automatically better evidence.
Build a minimum DNS record
| Context | Why it can matter | Boundary |
|---|---|---|
| Resource or scoped identifier | Connect the event to an affected asset | Do not infer a human without evidence |
| Timestamp and bounded window | Order events around an alert | Account for clock and timezone differences |
| Queried domain and record type | Identify the DNS question | It is not a full URL or page view |
| Resolver and policy outcome | Show allow, block, redirect, or failure | A failure is not always a policy block |
| Authorized correlation reference | Link to endpoint or identity evidence | Avoid duplicating unrelated sensitive data |
Preserve provenance. Note which resolver produced the result, how the resource was identified, whether timestamps are normalized, and whether the record is an aggregate or individual event. Keep the original protected evidence when required and document any derived timeline. A copied domain in an analyst note without source or time is weaker than a small, well-described record.
Avoid overreading a lookup
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. A query does not prove that a person clicked, that a connection succeeded, that content rendered, or that malware executed. Browser prefetching, embedded resources, updates, and background processes can all generate lookups.
RFC 9076 explains that DNS data can be sensitive and recommends minimizing collection, retention, and sharing.2 Apply that principle operationally: start with counts and policy outcomes, reveal event detail only to permitted responders for a named purpose, and avoid exporting broad histories into less protected collaboration tools. Corroborate conclusions with the layer able to observe them.
Move through a bounded investigation
- Write one decision question and identify the affected resource, owner, and response window.
- Review aggregate resolver and policy outcomes before requesting individual activity.
- Open the narrowest permitted detail that can confirm the domain, time, resolver, and decision.
- Correlate with authorized endpoint, email, identity, or network evidence instead of inferring behavior from DNS.
- Preserve only the evidence needed for containment, recovery, legal, or learning requirements, with provenance.
- Remove temporary exports, close elevated access, document the conclusion, and schedule the relevant control review.
A blocked lookup can support containment by showing that the protected resolver denied a recognized destination. An allowed lookup can help explain a gap, but only when paired with the policy and intelligence state at that time. A missing event may indicate another resolver, cached answer, existing connection, or simply no lookup. Record uncertainty instead of converting absence into proof.
Close the window deliberately
Closure is part of response. Confirm that the evidence answered the named question, record the conclusion and remaining uncertainty, return temporary permissions to normal, and delete working copies according to policy. If a subset must be retained, separate it from general activity, protect its integrity, restrict access, and attach a review or disposal date.
- Do not expand from one resource to an entire account without a documented reason.
- Do not call a DNS query a visit, download, or compromise.
- Do not leave detailed views or exports open after the response question closes.
- Do not discard provenance when moving evidence into a timeline.
- Do not substitute longer retention for practiced response ownership.
Incident-context questions
How long should DNS activity be kept for incident response?
There is no universal duration. Choose a bounded period from the response purpose, legal obligations, threat model, storage design, and access risk. Preserve a relevant evidentiary subset when required rather than keeping every query indefinitely.
Does a DNS query prove that a user visited a site?
No. A browser may prefetch a domain, a page may load it as a dependency, or an application may contact it in the background. A query also does not prove a later connection succeeded or content was viewed.
What should an incident responder check first in DNS data?
Begin with the affected resource, a narrow time range, the resolver and policy outcome, and the domain relevant to the alert. Then correlate with authorized endpoint, email, network, or identity evidence before drawing conclusions.
Review a scoped Veilty event
In Veilty, begin with one resource in its household Space or team Tenant and the shortest incident interval that can answer the question. Retained DNS activity is scoped to that boundary, end-to-end encrypted with user-held keys, and available only through permitted roles; the resolver still necessarily processes live requests to answer and apply policy. Prefer aggregate outcomes before opening event detail.
Confirm the assigned profile and policy result, correlate only through authorized response workflows, and avoid describing a lookup as a page visit or human intent. Preserve the smallest required evidentiary subset, close temporary access, and review the relevant rule or resolver path after containment. This keeps incident context useful without making endless activity retention the operating default.