← 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

Read Records, TTLs, and Negative Answers

Interpret common record sets and caching behavior so a current lookup is not mistaken for historical truth.

In this lesson, you will learn to:

  • Interpret common DNS record types in their owner-name context.
  • Explain how positive and negative caching constrain an investigation timeline.

Read Records, TTLs, and Negative Answers

Covers record ownership and type, aliases, mail and name-server records, TTL decay, cache effects, NXDOMAIN, NODATA, and transient resolution failures.

Read the exact question and record set

A DNS question identifies a name, type, and class. An A record maps an owner name to an IPv4 address; AAAA maps to IPv6. CNAME aliases one owner name to another canonical name and can trigger additional lookups. MX identifies mail exchangers for a domain. NS identifies authoritative name servers for a zone. TXT carries application-defined text, including several email and verification conventions. PTR is commonly used for reverse mapping. The meaning belongs to the record type and owner name, not to a word the analyst recognizes inside the data.

Capture the complete answer, authority, and relevant additional data when possible. A CNAME chain can explain why a familiar service and an unfamiliar delivery domain appear together. Multiple A or AAAA records can reflect load distribution or content delivery. Shared hosting means one address can serve many unrelated domains, so an address match is not automatically a shared operator. Conversely, one domain can change addresses quickly. Preserve query type and response because “no A record” does not mean “the name does not exist” or “no other record type exists.”

Record type determines what a DNS answer meansA, AAAA, CNAME, MX, NS, TXT, and PTR records attach different data and semantics to an owner name.FIELD GUIDERecord type determines what a DNS answer meansDECISION CUEOwner nameAnswer contextOwner nameFIELD 1Record typeFIELD 2TTLFIELD 3Record dataFIELD 4Answer contextFIELD 5RECORD ANATOMY
Record type determines what a DNS answer means — A, AAAA, CNAME, MX, NS, TXT, and PTR records attach different data and semantics to an owner name.

Treat time and negative results as first-class evidence

A TTL controls how long a resolver may reuse cached data; it is not the registration age of a domain or a guaranteed lifetime of infrastructure. The TTL observed in a response may already be counting down from cached data. A lookup performed during the investigation can therefore differ from the answer a client received at incident time. Prefer historical resolver logs or time-bounded passive data for historical claims, and record the lookup time and resolver used.

NXDOMAIN means the queried name does not exist under the responding DNS view. NODATA means the name exists but the requested type has no data. Both can be cached under defined rules. A timeout or SERVFAIL is different: it can reflect reachability, delegation, DNSSEC validation, or server failure. Modern guidance also addresses caching resolution failures. Search domains and application retries can generate many negative queries from a single mistyped or short name. When using NXDOMAIN volume as a signal, retain the exact response code, query type, client, suffix behavior, and baseline rather than counting every unsuccessful lookup alike.

Caches separate observation time from data originAuthoritative data enters a recursive cache, its TTL decays, clients reuse it, and later changes can produce a different answer.FIELD GUIDECaches separate observation time from data originDECISION CUEAuthoritativeanswerFresh lookup differsAuthoritativeanswerCached with TTLClient cache hitTTL expiresFresh lookupdiffersCACHE TIMELINE
Caches separate observation time from data origin — Authoritative data enters a recursive cache, its TTL decays, clients reuse it, and later changes can produce a different answer.

Resources

← Previous: Trace the Resolution Chain Next: Know Your Resolver Telemetry and Blind Spots →