Redirect and Traffic Diversion Forensics

By Bill Hartzer, domain name expert witness·August 10, 2026

Where a diversion is configured, and what each layer leaves behind

A diversion looks like one thing to a visitor and is four different things technically, each of which leaves a different record. Establishing which layer was used is the first step, because it determines which custodian holds the proof and how long they hold it.

DNS. The address record or the CNAME — a DNS record making one name an alias for another — points at different infrastructure. Proved by dated DNS observations and by passive DNS, a historical database of observed DNS answers built from sensors rather than queried live.
HTTP. The server answers with a 3xx status code and a Location header. Proved by captured response headers.
Page code. A meta refresh tag or a script navigates the browser after the page loads. Proved by captured page source together with a network trace.
Registrar or registry forwarding. A forwarding service offered by the registrar. Proved only by that provider's configuration records.

The distinction is not academic. A DNS-layer diversion is visible to passive DNS providers and may be reconstructable months later. A forwarding rule in a registrar control panel leaves nothing behind at all except in the registrar's own systems, and whether those systems keep configuration history is a question to put to the custodian rather than to assume.

The status code is a fact, and it belongs in the exhibit

HTTP's redirection semantics are defined in RFC 9110, published June 2022. A redirect is a response telling the browser to go somewhere else, and the destination is carried in the Location field, whose value is a single URI reference. The specific code is a property of the configuration and is worth recording exactly.

301 Moved Permanently states that the target resource has been assigned a new permanent address and future references ought to use it. 302 Found states that the resource resides temporarily under a different address. 303 See Other, 307 Temporary Redirect and 308 Permanent Redirect complete the set; 307 and 308 preserve the request method where 301 and 302 historically did not.

Why an attorney should care: permanence is stated in the configuration itself. A 301 is an assertion by whoever configured the server that the move is permanent. A 302 asserts the opposite. Whether the party who set it intended what the code says is a separate question, but the code is a contemporaneous machine-generated statement about intent, made before any dispute existed, and an exhibit that omits it has discarded that.

Capture the chain, not the landing page

The most common defect I see in redirect evidence is a screenshot of the destination. It shows where a visitor ended up. It does not show that the disputed domain sent them there, which is the entire proposition.

A diversion is usually a sequence: the bare domain to the www hostname, the www hostname to an affiliate tracker, the tracker to the destination. Each hop has its own status code, its own Location value and possibly its own host, and most tools follow redirects silently by default, collapsing the whole chain into a single line. So the capture is done twice: once with redirect-following disabled, to record each hop discretely with its own request and response transcript, and once with following enabled, to record the chain as a visitor experiences it.

Around that go the supporting captures. Response headers and body preserved in native form rather than as a rendering. The DNS resolver used and the IP that answered. The local timestamp with its time zone. A screen recording of the navigation — the collection guidance published by SWGDE gives preference to video capture of the screen, with stills used alongside, and a redirect is exactly the case that justifies it, because a still frame cannot show a sequence. A packet capture where one is taken. And a hash of every file, computed at collection.

One capture proves one moment, so build the range

A capture establishes that the redirect existed when the capture was made. Nothing more. Where the date range matters — and it usually does, because duration is what makes a diversion consequential — the range is built by stacking independent sources.

Successive captures on a schedule are the foundation, and they should start on day one of the engagement rather than after the analysis is planned. Archived copies of the source URL frequently preserve either the redirect itself or the diverted page as it appeared, with their own capture timestamps, which are recorded separately from the examiner's retrieval time. Passive DNS records cover the DNS layer for the period. Where they can be obtained, the provider's configuration change log or the destination site's analytics and referrer data close the range from the other end.

Volume is a separate question again. Where the number of diverted visitors is at issue, that comes from server access logs and analytics accounts at either end — provider-held or party-held records, each with its own retention window, and each requiring a channel to reach.

Responses vary by viewer, and that must be disclosed

Web responses are not uniform. Content is often dependent on external factors including visitor credentials, browser, location, date and time, and redirects are frequently conditioned on exactly those. A rule can send visitors from one country onward while leaving everyone else on the page. It can trigger on a mobile user agent only. It can fire only when the request carries a referrer from a search engine.

Cloaking — serving different content to different visitors, typically distinguishing search engine crawlers from people — is the version of this that matters most in domain matters, because it means an archive crawler may have seen a genuinely different response than a browser did on the same day. Neither observation is wrong; they are observations of different conditional branches.

The working method is to capture from more than one network location and more than one user agent, and to record every variation observed, including the attempts that did not reproduce the redirect at all. A non-reproduction is a finding and it goes in the exhibit. An expert who tested from one machine in one city and then described the behavior as universal has made a claim the configuration does not support, and it is a straightforward thing for the other side to disprove.

What redirect evidence cannot establish

It cannot establish who configured the redirect. Proving that a domain sent visitors somewhere is a documentary finding about a configuration; connecting that configuration to a person requires the provider's account and log records, which is separate work through a separate channel.

It cannot recover a redirect that was never captured. Redirects are configuration, not content: they can be removed in seconds and leave no residue on the domain itself. Configuration change history exists only with the provider, only if that provider keeps it, and only for as long as they do. Hosting log retention is set by the provider, is frequently measured in weeks, and is often shorter than the time it takes to identify the right custodian and serve process on them.

It cannot treat an archive gap as absence. Crawlers may have been unaware a page existed, robots.txt may have blocked collection, and site owners may request exclusion. A missing archived capture is not evidence that a redirect was not in place.

It cannot rely on passive DNS for thin coverage. Passive DNS is sensor-dependent, so a low-traffic domain may have few observations, or none, for the exact window in dispute.

And it cannot promise reproduction. Conditional and geo-targeted rules mean another examiner may legitimately fail to see what the first one saw.

The custodian records, and the windows they sit in

Three tiers of evidence sit behind a redirect, and they differ in who holds them and how quickly they go away.

Self-collected and public. Live HTTP captures, DNS lookups, page source, screen recordings. Held by the examiner from the moment of capture, which is why the examiner's own process is what authenticates them — and why they are the only tier entirely within anyone's control.

Third-party. Internet archives, which often preserve the source URL's behavior or the diverted page, and passive DNS providers, which hold historical resolution data. Independent of both parties, which is their evidentiary value; outside anyone's control, which is their limitation.

Custodian-held, requiring process. Hosting configuration and change logs, CDN and DNS provider rule history, web server access logs, and registrar forwarding configuration. Under ICANN's registrar data retention framework, log files, billing records and communication source and destination data sit under a 180-day retention floor. Hosting providers set their own, and shorter is common. Identifying which custodians matter, and what their windows are, belongs at the start of an engagement, because those windows and not the litigation calendar are the binding constraint.

How the exhibit set is assembled and authenticated

The deliverable is a chain table plus the underlying transcripts. The table gives one row per hop: hop number, requesting host, status code, Location value, resolving IP, and observation timestamp with time zone. Behind it sit the raw request and response transcripts for each observation, the captured HTML source, the screen recording, any packet capture, the resolver output, and a manifest listing every file with its hash.

Authentication in United States federal practice generally follows from that record rather than from anything special about redirects. Self-collected captures are authenticated through testimony describing the collection process and the tools used, supported by the contemporaneous log and the hashes that the SWGDE online-content guidance and NIST SP 800-86 describe. Where an automated process produced the capture, the certification routes for records generated by an electronic process and for data copied from a device or file are the ones ordinarily engaged. Provider-produced logs are custodian records and are handled as such. All of this is US-specific, and whether any rule applies in a given matter is for counsel, not for the expert.

What the expert supplies is the record that makes the question answerable: what was captured, when, how, with which tool, and what it hashed to.

Frequently Asked Questions

Does a screenshot of the destination page prove a redirect?

No, and this is the most common defect in redirect evidence. A screenshot of where a visitor landed does not show that the disputed domain sent them there, which is the proposition at issue. What proves it is the request and response transcript for each hop: the requesting host, the status code, the Location header naming the next address, the resolving IP, and the timestamp with time zone. A screen recording of the navigation supports it, because a redirect is a sequence and a still frame cannot show a sequence.

Why does the difference between a 301 and a 302 matter?

Because they say different things about the configuration. A 301 states that the resource has been assigned a new permanent address and that future references ought to use it; a 302 states that it resides temporarily elsewhere. That is a machine-readable statement made by whoever configured the server, contemporaneously, before any dispute existed. Whether the configuring party intended what the code asserts is a separate question. But an exhibit that records only that a redirect existed, without the code, has discarded evidence that was sitting in the response header.

Can a redirect that has already been removed be documented?

Sometimes, and never as reliably as capturing it while it was live. What remains after removal is indirect: archived copies of the source URL, which may preserve the redirect or the diverted page; passive DNS records if the diversion operated at the DNS layer; the provider's configuration change history if that provider keeps it; and analytics or referrer data at the destination end. Redirects leave no residue on the domain itself. A redirect that was never captured and that no third party happened to observe is generally unrecoverable.

What if the redirect only fires for some visitors?

That is common, and it is disclosed rather than smoothed over. Rules are routinely conditioned on country, device, user agent or the referring site, so one examiner's capture may not reproduce for another. The method is to capture from multiple network locations and multiple user agents and to record every variation, including attempts where the redirect did not occur. Non-reproduction is itself a documented finding. An expert who tested from a single machine and then described the behavior as universal has overstated what the configuration supports.

Does documenting a redirect show who set it up?

No. Establishing that a domain diverted visitors is a documentary finding about a configuration. Connecting that configuration to a person is separate work, and it depends on account and log records held by the hosting provider, DNS provider, CDN or registrar, reached through a recognized channel rather than through analysis. Those records also sit under retention windows that are frequently short. Keeping the two findings distinct in a report matters, because conflating them is the point at which a documentary exhibit turns into an inference presented as a fact.

How quickly does this evidence need to be collected?

Immediately, and then repeatedly. A redirect is configuration and can be removed in seconds by whoever controls the server or the DNS. Hosting access log retention is set by each provider and is often measured in weeks. The registrar retention floor for log files and communication source and destination data is 180 days. A single capture also only proves a single moment, so a date range requires a schedule of captures over time rather than one collection visit. Capture first, analyze afterwards.