What hosting evidence connects, and what it does not
Registration records stop at the delegation. They say which nameservers a domain pointed at; they say nothing about where the site actually ran, who paid for the server, or who logged into it. Hosting and infrastructure analysis picks the trail up there and follows it down through IP address registrations, routing data and provider-held records.
The value of that work in a dispute is specific. It establishes which company was in a position to serve the content at a given time, and therefore whose records would identify the operator. It can show that a name moved onto infrastructure controlled by a party at the moment control changed hands. It can also show that two properties a party has described as unrelated ran on the same provisioned server — or, just as often, demonstrate that an apparent connection is nothing more than a shared host.
What it does not do on its own is name a person. Every identity conclusion in this discipline is a conclusion about a record held by a company, obtained through counsel.
From a domain to a network
The chain is short and each link is a separate record. A domain's A and AAAA records point at IP addresses. Each address falls inside a network block, and that block is registered with a Regional Internet Registry — the body that allocates address space in a region, with ARIN covering North America. The registry publishes the organization the block is registered to, the range, its registration and update dates, and abuse and technical contacts.
Below that sits reassignment reporting, which is where a block handed to an actual customer becomes visible. ARIN requires reporting of IPv4 reassignments and reallocations of a /29 or more, and IPv6 of a /47 or more, within seven days of the subdelegation (ARIN reassignment reporting). Smaller IPv4 blocks may be reported voluntarily or on request.
Two records complete the picture at this layer: reverse DNS, which shows what name an address maps back to, and the mail exchanger records that show where a domain's mail was handled — often a different provider entirely, and often a more informative one.
Routing history: who announced the address
Current registration of a block is a snapshot. Which network actually announced a prefix during the period in dispute is a historical question, and public route-collector archives answer it.
The University of Oregon RouteViews project archives routing table snapshots and update streams going back to the late 1990s, with table snapshots collected at two-hour intervals and update files rotated every fifteen minutes. The RIPE NCC's Routing Information Service collects the same class of data through remote route collectors positioned largely at Internet exchange points, and publishes both raw archives and a routing-history query interface.
The output is an ASN — an Autonomous System Number, the identifier of a network that announces routes — paired with dates. That establishes which network carried the address during the relevant window, which is often different from whatever a lookup returns today. When an address has changed hands, the routing archive is what separates the customer who held it then from the customer who holds it now.
The CDN in front of everything
A large share of modern sites sit behind a content delivery network: a layer of edge servers standing in front of the real machine, which is called the origin server. When a record is proxied through such a network, a DNS query returns the network's own addresses rather than the origin's; the provider's documentation says so explicitly, and distinguishes proxied records from DNS-only records that return the actual origin address.
The consequence is that a resolution showing a CDN address establishes the CDN relationship and nothing at all about the origin. Reporting a CDN edge address as "the server hosting the site" is a straightforward error, and it is one an opposing expert will enjoy pointing out.
Two things can be done about it. The CDN itself holds the origin address and the origin request logs, which makes it a custodian worth naming in a preservation request. And historical resolution data will sometimes capture the period before the domain was placed behind the network, when the origin was still visible — which is one of the more practical reasons to pull DNS history rather than relying on a current lookup.
What infrastructure records cannot establish
Shared hosting is why this evidence gets overstated more than any other kind. Thousands of unrelated sites can occupy a single address, so the fact that two domains resolved to the same IP is, standing alone, close to worthless. It becomes meaningful only when the base rate is established — how many other domains sat on that address at that time — and when the ordinary explanations are excluded. Co-location is a hypothesis to be tested, not a finding to be announced.
A registry record is also not a location. ARIN states plainly that it cannot guarantee that the address associated with an Internet resource record is the actual physical location of the network, and commercial IP geolocation inherits that limitation entirely (ARIN guidance). Nor does a registry know the end user; its records help identify which service provider may be connected to a user, not the user.
Public visibility has a floor. IPv4 blocks smaller than a /29 need not be reported, so a small customer can be entirely invisible in public records. Addresses are recycled, and an address that served a site in one year may belong to an unrelated customer two years later — provider allocation records, not today's lookup, resolve that. Routing archives record what their collectors' peers saw. And the provider logs that would actually identify an operator are the records deleted soonest.
Where identity actually comes from
The records that turn "this address served the site" into "this customer ran it" are held by the hosting company, VPS provider, reseller or CDN: the account record, the billing and payment history, the server provisioning record, and the access and authentication logs. None of that is retrievable by lookup.
ARIN's own published guidance points the same direction, noting that more specific downstream customer information may be obtained from the customer's service provider, and listing financial transaction records, billing contacts and some customer reassignment information as material it holds but does not publish. That guidance also states what effective legal process should specify: the addresses or network numbers in question, and the specific date range. A request without a date range asks for a snapshot that may not answer the question at all.
Timing dominates. Access logs are the shortest-lived record in the chain and the one most likely to identify an operator. The expert's contribution is to specify precisely which records, at which providers, for which date ranges should be preserved; whether and when to serve a preservation demand or subpoena is counsel's decision.
Correlation as convergent indicators, not identification
Shared addresses, shared nameservers, shared mail servers and shared TLS certificates are the standard link indicators in this work. Each of them is a hypothesis. None of them is an identification.
The way to present them honestly is with their base rates and their alternative explanations attached. A shared nameserver at a provider with millions of customers means almost nothing; a shared nameserver at a self-hosted machine announcing from a small network means considerably more. Convergence is what carries weight — several independent indicators aligning across the same window, each individually weak — and the report should say that explicitly rather than implying that any single overlap identifies anyone.
I would rather write that a set of indicators is consistent with common operation and identify the records that would confirm or refute it than assert a connection the public data cannot carry. The second version reads more strongly and survives much less.
Authenticating infrastructure records (US federal rules)
This describes United States federal rules only; other jurisdictions and US state courts apply their own, and application is a matter for counsel.
Rule 901(a) requires evidence sufficient to support a finding that an item is what its proponent claims (FRE 901). Correlation-type infrastructure evidence maps naturally onto 901(b)(4), distinctive characteristics taken together with all the circumstances, while 901(b)(9) covers the collection systems — route collectors, registry query services — as processes producing accurate results, and 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 authenticated by a process of digital identification, both on a qualified person's certification and with Rule 902(11) notice. Provider-produced logs are the category most often considered under the business-records conditions of Rule 803(6) — including condition (E), which preserves the opponent's ability to show that the source or circumstances indicate a lack of trustworthiness. That last point is worth anticipating when the producing provider is one whose record-keeping is itself in question.
What this looks like in an expert report
The core exhibit pairs every address assertion with a date range and with the registry record as it stood during that range, not merely as it stands now. Alongside it sit the routing history showing which network announced the prefix in the window, the reverse DNS and mail records, and the co-hosting and shared-certificate sets with their base rates stated.
Captures are made on the same day where possible, timestamped in UTC and hashed. Where a CDN sits in front, the report says so and states exactly what the evidence can and cannot reach behind it. And where identity is the ultimate question, the report names the custodian, the record type and the date range that would answer it — which is the part a retaining attorney can actually act on.