What DNS evidence answers
Registration records say who a name was assigned to. DNS records say what the name actually did — which servers it pointed at, which machines received its mail, and when any of that changed. In matters involving traffic diversion, impersonation, an interrupted business or a transfer that happened quietly, the resolution history is frequently more probative than the registration record, because it describes operation rather than paperwork.
The evidence splits across two layers, and they have different custodians. The delegation — which nameservers the top-level domain registry publishes for the name — is registry-held. Everything below it is authored at whatever DNS operator those nameservers belong to: A and AAAA records (IPv4 and IPv6 addresses), MX (mail servers), CNAME (aliases) and TXT (free text, commonly used for verification tokens). A subpoena aimed at the wrong layer comes back empty, and that mistake costs weeks.
Passive DNS is observation, not lookup
Passive DNS is a historical database of DNS answers that sensors happened to observe, rather than a live query run now. Sensors sit above recursive resolvers — the servers a device asks, which cache answers — and capture the "cache fill" responses that authoritative nameservers return to those resolvers. The design deliberately excludes client-identifying information: passive DNS has no access to the querying user's source address or port (Passive DNS Common Output Format, which is an IETF Internet-Draft rather than a published RFC, and should be cited as such).
That format defines the fields an export will contain: rrname, the queried name; rrtype, the record type; rdata, the answer returned; and time_first and time_last, the first and last times that answer was observed, with optional observation counts and sensor identifiers.
These databases are built from sensors that network operators volunteer to deploy and contribute. Coverage is therefore a function of who chose to contribute, and when — not of what existed.
Reading time_first and time_last correctly
This is where most passive DNS analysis goes wrong, and it is the easiest thing for opposing counsel to take apart. time_first is not the date a record was created and time_last is not the date it was removed. They bound an observation window. Caching compounds the imprecision: the TTL (time to live, the interval a resolver may keep an answer before re-fetching it) governs how long a stale value can circulate after a change was made.
The defensible formulation is a bracket. The name was last observed resolving to one value on a given date and first observed resolving to another on a later date; the change occurred between them. Never a point-in-time assertion dressed up as a fact. Where two providers disagree because they operate different sensors, report both rather than selecting the more convenient one, and say why they differ.
Zone files and the delegation layer
Zone files supply the complementary registry-sourced view. A zone file is a registry's list of the names currently delegated in a top-level domain. gTLD registry operators must provide ICANN bulk access to their zone files at least daily, and approved users of the Centralized Zone Data Service can download zone data once per 24-hour period, with access granted for at least three months per approved request (ICANN zone file access).
Dated zone extracts establish when a name was delegated and which nameservers the registry published for it. That is a registry fact rather than a sensor observation, which makes it a useful anchor for a timeline built mostly from observation data. Two caveats. Zone files carry no registrant information at all, and a registered name that was never delegated does not appear in the zone — so absence from a zone file means undelegated, not unregistered. ICANN also notes that the Registry Agreement sets no period within which operators must process zone file access requests, so this is not a resource to plan around at short notice.
What DNS history cannot establish
Passive DNS proves that a resolution was seen. It cannot prove that a resolution never happened. Sensor coverage is partial and provider-dependent — the data exists because network operators volunteered to contribute their resolvers' traffic — so a domain that nobody looked up from a covered network is a domain the database never saw. M3AAWG's own technical summary acknowledges that while global sensor deployment captures most actively used domains, some obscure or little-used domains may escape detection. An empty result is a statement about the sensor network, not about the domain. Absence of an observation is not evidence of absence.
Three further limits belong in any report resting on this evidence. Timing is bounded rather than exact, for the caching reasons above. Client attribution is impossible by design: passive DNS cannot show who visited a site, only what a name resolved to. And infrastructure artifacts impersonate relationships — wildcard records, content delivery network edge addresses and anycast answers (one address served from many locations) can make two domains look connected when they merely share a provider.
Split-horizon and internal DNS are invisible to public sensors entirely, as is any answer served only inside a private network. Retention depth also varies by provider and by product tier, so "how far back does this go" has a different answer for every source queried.
Where the authoritative change record lives
Passive DNS points at the question; it rarely answers the last one. If it matters who made a change, the record that says so is held elsewhere: the registry's transaction log for a change of nameserver delegation, and the DNS hosting provider's zone edit history and account logs for anything below the delegation. Those show the account behind each edit, and often the address it connected from.
Both are obtained through legal process rather than lookup, and both age. Provider audit logs are retained under each provider's own policy, which is commonly short and is not standardized across the industry. The sequence that works is to establish the bracket from public observation data, identify precisely which custodian holds the record that would close it, and get a preservation request in front of that custodian early. Counsel decides what is served and when. The expert's contribution is specifying exactly which records to preserve, for which dates, and why they are the ones that matter.
Capture the present before it becomes the past
The cheapest evidence in this discipline is the evidence nobody bothered to collect. Current resolution is observable right now, at no cost, and it stops being observable the moment somebody edits a record. Before a matter is filed I capture live resolution for every name at issue: the query, the resolver that answered, the complete response and a UTC timestamp. Answers vary by resolver and by geography, so a capture that does not name the resolver used cannot be reproduced by anyone — including by the person who made it.
Preserve raw exports in JSON or CSV rather than screenshots, hash them, and record the provider and the exact query string alongside each. A passive DNS export is a third party's record of its own observations. A screenshot of one is a picture of a web page.
Authenticating DNS records (US federal rules)
What follows describes United States federal rules only; other jurisdictions and US state courts differ, and application is for counsel.
Federal Rule of Evidence 901(a) requires evidence sufficient to support a finding that an item is what its proponent claims (FRE 901). For passive DNS the illustration that fits is 901(b)(9) — evidence describing a process or system and showing that it produces an accurate result — because the honest description of this evidence is a description of a collection pipeline: where sensors sit, what they capture, how observations are aggregated and timestamped. Rule 901(b)(1) covers the analyst's own dated captures.
Rules 902(13) and 902(14) address certified records generated by an electronic process and certified data copied from a file and authenticated by digital identification, each requiring a qualified person's certification and Rule 902(11) notice. Provider-produced logs are ordinarily considered under the business-records conditions of Rule 803(6), including the opponent's ability to show a lack of trustworthiness.
What this looks like in an expert report
The core exhibit is a resolution timeline in which every entry is a bracket with a named source: value observed, first and last observation times, provider, and the export file's hash. Zone-file extracts anchor the delegation layer with registry-sourced dates. The analyst's own live captures anchor the present.
The accompanying narrative does two things. It states what changed and within what window. Then it states which questions the record cannot reach — who made the change, whether an unobserved period was quiet or merely unsampled — and identifies the custodian whose records would answer them. That second part is what makes the first part usable.