What infrastructure evidence is for
Infrastructure research asks a narrow question: what technical estate sits behind an operation, and how is it arranged? The answer places systems in jurisdictions, shows whether apparently separate sites share a setup, and establishes when things were built and changed.
It answers questions about systems rather than people. That distinction runs through everything below, and most overreach in this area comes from ignoring it.
The record types and what each one shows
Domain registration records show creation, renewal and transfer dates, the registrar used, and any nameserver history. Holder details are usually redacted, so the value lies in timing and administrative choices. A site presenting a decade of history on a domain registered four months ago is a documented contradiction, and that contradiction is often the finding.
DNS records show where a name currently points and, through historical datasets, where it pointed before. Movement between providers, sudden changes around a dispute, and clusters of names resolving to one host are all observable and datable.
Certificate transparency logs record issued TLS certificates publicly. Because certificates often list multiple names, the logs regularly expose related subdomains and sibling sites that were never linked publicly.
Routing and network ownership records show which network holds an address range and which organisation announces it. This places infrastructure in a jurisdiction and identifies the provider a lawful request would eventually be directed to.
Content and platform fingerprints — analytics identifiers, template artefacts, error page behaviour, shared assets — indicate whether distinct sites were built and operated from a shared setup.
Reading shared hosting correctly
The most frequent error in this work is treating co-location as connection. Vast numbers of unrelated sites share an address on commodity hosting, and two sites resolving to the same IP is, on its own, close to meaningless.
A shared-infrastructure finding needs more: a dedicated host with few tenants, matching certificate names, identical analytics identifiers, shared unusual template artefacts, or synchronous changes across sites over time. Several weak signals aligning across independent record types is what supports a link; one weak signal repeated loudly does not.
Provider practice matters too. Some hosts rotate addresses aggressively, some proxy everything behind a content network, and some publish nothing useful. Where the provider's behaviour explains an observation, the file says so instead of reading it as intent.
Timing as the strongest infrastructure signal
Infrastructure evidence is most persuasive when it is temporal. Registration dates, certificate issuance times, DNS changes and archive snapshots produce a build history that can be compared against the account a party has given.
A platform that claims years of operation, a domain first registered recently, a certificate issued days before the first contact, and archived copies showing a template site until last quarter form a coherent, dated picture. Each element is individually weak; assembled into a timeline they are considerably stronger, and every entry cites the record it came from.
What infrastructure evidence cannot establish
It cannot identify an individual. Servers are rented, panels are shared, credentials are delegated and addresses are reassigned. Infrastructure shows an estate, not an operator.
It cannot establish a person's physical location. Geolocation of an address describes where a network provider allocates that range, which is frequently not where anyone is sitting, and is trivially altered by ordinary tooling.
It cannot prove ownership from similarity. Two sites built by the same freelancer from the same template share fingerprints without sharing a controller.
And it cannot substitute for records held by providers themselves. Those are reachable only through lawful process by parties entitled to seek them. What infrastructure research does is establish, on the record, exactly which provider and which jurisdiction that process would need to address.