DNS Investigations: Resolution Paths, Time, and Evidence
Use DNS questions, answers, resolution paths, timing, and multiple vantage points as bounded investigation evidence.
Start with the exact DNS question
Record the queried name, record type, client, resolver, response code, answer set, TTL, and observation time. A domain resolving to an address is a relationship at a moment, not proof of ownership or maliciousness.
Keep the exact fully qualified name and distinguish A, AAAA, CNAME, MX, TXT, NS, PTR, and other record questions. Record whether the evidence is a client query, recursive-resolver log, authoritative response, cache observation, or security-product enrichment. “No result” must include the response code and record type: NXDOMAIN, no data for one type, timeout, policy block, and collection failure are different facts.
Map the resolution path
Stub resolvers, recursive services, forwarding layers, filtering products, authoritative servers, and encrypted DNS can produce different observations. Place each event at its vantage point before joining evidence.
A client may ask a local stub that forwards to a corporate resolver, which consults cache or another forwarder before reaching authoritative infrastructure. Split-horizon zones, VPNs, mobile networks, browser-managed encrypted DNS, hosts files, and application caches can alter the path. Draw which component observed the name, which upstream it used, and whether the answer was synthesized or blocked. Resolver logs do not necessarily prove the client connected to the returned address.
Treat time as evidence
Answers rotate, caches persist, domains age, and negative results expire. Preserve event time, collection time, and relevant TTL. A current lookup cannot reconstruct a past answer without historical evidence.
Store timestamps in their original zone and normalize a working timeline to UTC. Relate each answer only to its supported interval; do not attach today’s hosting or registration data to last month’s event without historical evidence. TTL guides caching but does not guarantee every resolver evicts or refreshes at the same moment. Passive DNS adds historical observations from particular sensors, not a complete global history, so record provider, retrieval time, and coverage limitations.
Compare behavior and alternatives
Compare frequency, timing, client population, subdomain structure, record changes, and endpoint effects with legitimate services. Fast flux, tunneling, tracking, service discovery, and misconfiguration can share individual features.
High-entropy subdomains may carry tunneled data, but they also appear in content delivery, email security, telemetry, and cache busting. Many addresses may indicate flux, load balancing, or a global cloud service. Compare query length, labels, record types, cadence, response behavior, client roles, process attribution, certificates, connections, and transferred data. Test legitimate application and administrative explanations before assigning intent.
Pivot and control narrowly
Expand through time-aligned client, domain, address, certificate, registration, and process evidence. Passive DNS and WHOIS can support pivots but have coverage limits. Choose the narrowest control that addresses observed risk.
Pivot one relationship at a time and record why it is relevant. Shared hosting, public resolvers, registrars, name servers, and certificates can connect thousands of unrelated tenants. If blocking is justified, consider exact names before parent domains or addresses, assess shared-service impact, define an owner and expiry, and plan rollback. Verify whether activity continues through alternate resolvers, direct IP use, cached answers, or a new name; DNS control cannot remediate an already compromised endpoint. For example, a sinkholed domain may stop command traffic while leaving persistence and stolen credentials untouched, so endpoint and identity owners still need explicit follow-up actions.
