A current DNS lookup tells you what a resolver can see now. A DNS history dataset can add a timeline, but that timeline is never universal. It reflects the names, record types, collection methods, and dates that a particular system observed. This distinction decides whether an investigation produces a defensible conclusion or a confident story built on missing data.
DomScan's DNS History tool is an internal observation log. Successful DNS lookups can add records to the dataset, and later lookups can show that an observed value is still present or has disappeared. DomScan does not import an external passive DNS archive and does not continuously crawl every domain. A domain with no history may simply never have received a qualifying lookup. A quiet period may mean no observation occurred, not that the DNS stayed unchanged.
How DomScan DNS History Is Populated
The history service receives records from successful DomScan DNS lookups. A lookup for one record type can observe that type, while a multi-record lookup can observe several types in the same request. DomScan normalizes the domain name, stores each distinct record value, and tracks the dates on which that value was first and most recently seen. Repeated observations on the same day are deduplicated to avoid treating request volume as additional historical evidence.
Coverage therefore varies by domain and record type. One domain might have several observed A and MX values but no NS history. Another might have only a single observation. The dataset can include A, AAAA, NS, MX, TXT, CNAME, CAA, SOA, SRV, HTTPS, SVCB, PTR, and other record types supported by the lookup route, but it only contains values that a qualifying request actually returned. Empty responses are not stored as record values.
- It is not a continuous packet capture or recursive resolver log.
- It is not a complete archive of every DNS answer ever published for the domain.
- It does not establish the exact minute when a change became authoritative worldwide.
- It does not prove who requested the change or why it happened.
- It can still provide useful, dated evidence that DomScan observed one value and later observed another.
What the Dates and Change Labels Mean
The first-seen date is the first date on which DomScan stored a particular record value for the domain and type. The last-seen date is the latest date on which that stored value was observed, or the date associated with its transition out of the current set. These dates bound an observation window. They do not identify the record's original creation date or guarantee that it remained continuously published between two observations.
An added label means a value entered DomScan's observed set. A removed label means a later observation no longer included a value that had been current in that set. DNS caching, resolver behavior, temporary failures, split-horizon DNS, geographic answers, weighted routing, and short-lived infrastructure can all affect what one lookup returns. Treat a surprising transition as a reason to verify, especially when the record is part of a CDN, traffic manager, or failover system.
TTL deserves similar caution. A recursive answer often reports remaining cache lifetime rather than a durable configuration value. DomScan records TTL context, but TTL drift by itself is weak evidence of a configuration change. The record value and the sequence of independent observations usually matter more than small differences in TTL.
How to Read Common Record Changes
A and AAAA records connect a name to IPv4 and IPv6 addresses. A new address may reflect a hosting migration, a load-balancing pool, a CDN edge, a failover event, or a compromised configuration. Before attributing the address to an operator, check whether it belongs to shared infrastructure and whether the same answer is still returned by a fresh lookup. An address owned by a cloud or CDN provider identifies the network, not necessarily the customer using it.
NS records identify the authoritative name servers delegated for a name. A move between clearly different DNS providers can be an important control-plane event, but it still does not prove a transfer of domain ownership. Registrants change providers during migrations, incident recovery, cost reviews, or consolidation projects. Shared provider nameservers also support many unrelated customers, so a common NS suffix is poor attribution evidence on its own.
MX records describe where mail for a domain should be routed. A new MX set can mark a mail migration or the activation of email capability on a previously web-only domain. For a lookalike domain, that change may justify a phishing review, but the DNS record alone does not show that mail was sent. Check SPF, DKIM selectors, DMARC policy, message evidence, and the surrounding timeline before describing intent.
TXT records carry many unrelated values, including email authentication policy, service verification tokens, and site ownership proofs. A removed verification token may simply mean onboarding completed or a provider was retired. CNAME changes can redirect an alias to a different service, but shared SaaS targets are common. The safest interpretation starts with the record's technical function and then asks what independent evidence supports the business or security explanation.
A Defensible Investigation Workflow
- Start with a fresh DNS lookup. Record the exact hostname, record type, answer, time, and resolver context so you know what is observable now.
- Open DNS History and note its first observation date, last observation date, tracked record types, and any gaps. Do not assume an unobserved interval was stable.
- Identify the smallest meaningful transition. For example, focus on an MX set appearing after a dormant period rather than labeling the whole domain malicious.
- Verify the transition independently. Query authoritative or additional resolvers, inspect the current registration record, and check the certificate served by the relevant host when those sources apply.
- Map the technical change to known events. A migration ticket, acquisition, provider outage, product launch, or incident report may explain the same timeline without implying abuse.
- State the conclusion with its limit. Write that a value was first observed by DomScan on a date, then separate that fact from any hypothesis about ownership, control, or intent.
This workflow is deliberately conservative. Investigation quality improves when observations and inferences remain separate. A useful report might say, 'DomScan first observed the new MX provider on 8 July, and the current DNS answer still contains it.' A weaker report would say, 'The attacker activated email on 8 July,' unless message evidence, access logs, or another source supports that attribution.
Common Failure Modes
The first failure is treating absence as evidence. No history does not mean no change. A missing record does not necessarily mean the record never existed. The second is collapsing shared infrastructure into ownership. Cloud platforms, CDNs, managed DNS providers, and mail services place unrelated customers on common systems. The third is comparing unlike names. History for example.com says nothing automatic about login.example.com, because each hostname can publish a different record set.
Another failure is reading one record type in isolation. An A-record change may look significant until the NS records show an expected provider migration. An MX change may look benign until a newly registered lookalike also publishes permissive SPF and begins sending messages. Correlation can strengthen a hypothesis, but it still needs careful language. Several clues observed together are not the same as proof of identity or intent.
Finally, avoid inventing precision. DNS answers can vary by resolver location and time, and DomScan stores dates rather than an authoritative global change timestamp. If the dataset supports only a date-level observation window, report that window. Do not manufacture an exact cutover time from a sparse history.
Preserve the evidence you actually used. Record the requested hostname and type, the current answer, the history response, the time of each lookup, and the source of any supporting registration or certificate data. A future reviewer should be able to distinguish a stored DomScan observation from a fresh query and from an analyst's conclusion. That distinction is especially important when a report may support an incident response, abuse report, or legal review.
Where DomScan Fits
Use DNS History when you need to inspect records that DomScan previously observed. Use the DNS Lookup tool or DNS Lookup API to verify the current answer and, when the lookup succeeds, contribute another observation. The history response identifies its data source as internal and tells you when no data is available. That disclosure is part of the result, not a footnote to ignore.
Other DomScan tools can supply separate current-state checks. The SSL checker inspects the certificate served by a host, while WHOIS and RDAP tools inspect registration data where available. Those tools do not transform the DNS observation log into a complete historical archive. Their value is in testing a hypothesis against another source, with each source's own coverage and limits kept visible.
Independent references: RFC 1035 defines the core DNS message and record model. RFC 8499 provides current DNS terminology, and RFC 3596 defines AAAA records. These standards explain the protocol. They do not turn any one observation dataset into a global record of DNS history.