← 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
2. Collect and Evaluate Suspicious DNS Activity

Assess Domains Without Turning Heuristics into Verdicts

Combine name, registration, hosting, certificate, record, use, and organizational context while resisting visual and reputation shortcuts.

In this lesson, you will learn to:

  • Evaluate a domain through independent contextual signals.
  • State why lexical, age, reputation, or hosting evidence is insufficient on its own.

Assess Domains Without Turning Heuristics into Verdicts

Provides a structured domain assessment covering lexical features, age, infrastructure, prevalence, application use, shared services, and time-bounded confidence.

Build a time-bounded domain profile

Start with the exact fully qualified domain name and query type as observed. Normalize case, preserve internationalized representations, and identify the registrable domain using an up-to-date public-suffix implementation. Then collect time-stamped evidence allowed by policy: first and last internal observation, affected clients, record and CNAME chain, nameservers, certificate records, hosting network, registration data where available, and reputation results. Note shared infrastructure and privacy-redacted registration rather than treating either as suspicious.

Lexical features such as many labels, high apparent randomness, brand words, digits, or uncommon suffixes can prioritize review. They do not establish maliciousness. Content-delivery systems, telemetry, tracking, anti-abuse, and cloud services often generate long or unique names. Newly registered or newly observed domains deserve context, but legitimate launches and ephemeral services are common. A reputation “unknown” result means the service lacks a verdict, not that the domain is clean. A malicious verdict requires the provider’s evidence, time, and scope to be weighed against direct observations.

A domain assessment combines independent evidenceName structure, internal use, records, hosting, certificates, registration, and process context surround the observed query.FIELD GUIDEA domain assessment combines independent evidenceDECISION CUEObservedqueryReputation with timeObserved queryInternalprevalenceRecords andhostingRegistration andcertificateProcess andconnectionReputation withtimeEVIDENCE NETWORK
A domain assessment combines independent evidence — Name structure, internal use, records, hosting, certificates, registration, and process context surround the observed query.

Compare the leading explanation with legitimate alternatives

Ask what generated the query. A browser process following a user-visible link, an endpoint security agent checking reputation, and an unsigned process resolving the same name create different hypotheses. Compare peer prevalence, device role, user activity, parent process, destination connection, TLS server name, HTTP host, downloaded content, and subsequent behavior. A DNS query made by a scanner can cause apparent enterprise prevalence even when no user accessed the domain.

Write a domain assessment as a bundle: observed behavior, infrastructure context, organizational expectation, corroborating telemetry, contrary evidence, and confidence. Test at least one legitimate explanation. If the domain belongs to a shared service, prefer a precise hostname, path, account, application, or behavior control over blocking a broad parent domain or address. Record the observation window because ownership, resolution, and content can change. Use “associated with this observed activity” instead of permanent labels when evidence is time-specific.

Suspicious signals balance against legitimate explanationsNewness, entropy, and reputation are weighed against shared services, application design, peer use, and direct behavior.FIELD GUIDESuspicious signals balance against legitimateexplanationsRisk signalsLegitimatealternativesDirectbehaviorand contextCHECKPOINTS1Risk signals2Direct behaviorand context3LegitimatealternativesSIGNAL BALANCE
Suspicious signals balance against legitimate explanations — Newness, entropy, and reputation are weighed against shared services, application design, peer use, and direct behavior.

Resources

  • IETF RFC 9499: DNS Terminology — Use the current terminology reference to keep names, zones, delegations, resolvers, authoritative data, and response concepts precise.
← Previous: Know Your Resolver Telemetry and Blind Spots Next: Test Tunneling and Beaconing Hypotheses →