← DNS Investigations: Resolution, Telemetry, and Threat Decisions
1. Understand What DNS Evidence Represents
Trace the Resolution Chain Read Records, TTLs, and Negative Answers
2. Collect and Evaluate Suspicious DNS Activity
Know Your Resolver Telemetry and Blind Spots Assess Domains Without Turning Heuristics into Verdicts
3. Test Threat Hypotheses and Respond
Test Tunneling and Beaconing Hypotheses Pivot, Scope, Block, and Report
1. Understand What DNS Evidence Represents

Trace the Resolution Chain

Follow a query from an application through local and recursive caches to authoritative data, and identify what each observer can actually record.

In this lesson, you will learn to:

  • Describe the roles involved in a typical enterprise DNS lookup.
  • Identify which portion of a resolution path is visible from a given log or packet capture.

Trace the Resolution Chain

Explains the DNS namespace, recursive and iterative work, referrals, authoritative answers, and why the same lookup can produce different observations.

Follow the question, not just the final address

An application usually asks a local stub resolver for a name and record type. The stub may answer from a local cache or send the question to a configured recursive resolver. If the recursive resolver lacks a usable cached answer, it follows referrals through the DNS hierarchy until it reaches authoritative data or a terminal error. The resolver returns an answer and caches eligible data according to TTL and policy. The application may then make another connection using the result.

This sequence matters because “the device queried an authoritative server” is often false in an enterprise. The client usually communicates only with the recursive service. The recursive service performs the upstream work, and a cache hit can answer without any new authoritative traffic. CNAME records can introduce additional names, and applications can request A and AAAA records in parallel. Record the query name, type, response code, returned data, resolver, client identity, and time. A resolved address is a mapping observed under those conditions, not proof that a connection occurred.

A DNS answer travels through distinct resolution rolesApplication, stub, recursive cache, referrals, and authoritative data contribute different steps and evidence.FIELD GUIDEA DNS answer travels through distinct resolution rolesApplicationand stubRecursiveresolverRoot anddelegationAuthoritativeserverAnswer andcacheCHECKPOINTS1Application andstub2Recursiveresolver3Root anddelegationRESOLUTION CHAIN
A DNS answer travels through distinct resolution roles — Application, stub, recursive cache, referrals, and authoritative data contribute different steps and evidence.

Place every observation at its vantage point

A packet capture on the client sees the client-resolver exchange but may miss later cache activity. A recursive-resolver log can see many clients but may represent them through a forwarder or NAT. An authoritative server sees requests from recursive resolvers, not necessarily the originating endpoint. Endpoint telemetry can connect a DNS query to a process, while a network sensor may connect it only to an IP address. Each vantage point answers a different question.

When reconstructing a lookup, state the vantage point explicitly: “managed resolver R recorded client address C requesting QNAME X, type A, at time T.” If client addresses are dynamic, join DHCP, VPN, wireless, or cloud allocation history for the same time. If a forwarder is involved, identify whether the logged source is the endpoint or the forwarding resolver. Do not infer a user from a device without session evidence. Resolution, connection, application request, and user action are separate events that need separate telemetry.

DNS visibility changes at every collection boundaryEndpoint, resolver, network sensor, and authoritative server observe different clients, processes, queries, and downstream actions.FIELD GUIDEDNS visibility changes at every collection boundaryDECISION CUEEndpoint:process andqueryConnection requiresother telemetryTRUST BOUNDARYEndpoint: process andquery • Resolver:client and answerAuthoritative: resolversource • Connectionrequires other telemetryCOVERAGE BOUNDARY
DNS visibility changes at every collection boundary — Endpoint, resolver, network sensor, and authoritative server observe different clients, processes, queries, and downstream actions.

Resources

Next: Read Records, TTLs, and Negative Answers →