Services & fees · Domain record
Domain record
In a domain dispute the three contested questions are always the same: who held it on the day in question, where did it point, and what did it serve. This records all three, every day, from the sources that answer them, the registry, the authoritative name servers, and the domain itself.
If this is the first product page you have opened: this archive has recorded, every day since 22 July 2026, what around 128,000 EU domains serve to machines, sealing each day so nobody can alter it afterwards. A standing observation records what a domain served. This product adds the two things a domain dispute turns on besides that: who was registered as its holder, and where its name servers sent every visitor, on each day.
Starting date. Registry and name-server answers do not arrive over the same path as a web page. The date on which daily retrieval starts for your domain is confirmed to you in writing before anything is charged.
Where this is used
Case 1A domain dispute, where the history is the case
Proceedings over a domain are decided on its history, not its present state: who was registered as holder when the mark was already known, what the domain pointed at in the months before the complaint, whether it carried a parking page full of advertising links, an offer of sale, or an imitation of somebody else’s site. By the time the complaint is filed, all of that has usually been changed.
Where the domain was under this record, each of those days exists as it was: the registry’s own answer naming the registrar and the status codes, the authoritative name-server answers, and the page that was served. Each of those days was recorded by a third party that had no part in the matter, and sealed the night it was seen.
Domain and trademark disputes · brand protection · specialist counsel
Case 2Look-alike domains, watched before anything happens
A brand owner knows the neighbourhood of its own name: the typo variants, the same name under other endings, the hyphenated forms. Most of them sit idle for years. The one that matters is the one that changes hands quietly and starts pointing somewhere new a fortnight before anyone notices.
Watching them costs the same as watching anything else here, and it produces the thing that cannot be produced later: a record of the quiet period, from before the day the other side had any reason to tidy up. Where nothing ever happens, nothing was lost but the fee.
Brand protection · preventive recording · trademark departments
Case 3The state of a domain on the day before an incident
After a security incident, the argument between an insured company and its insurer, or between a company and its supplier, is about the state of things on the day before: which name servers were authoritative, what the mail records declared, which certificate authorities were permitted to issue, whether the zone was signed. Afterwards everything has been changed, for good reasons, and nobody kept the previous state.
These answers are part of the daily record here, because they are part of what a domain publicly says. They are recorded without any assessment of whether they were adequate, this archive states what was, and the question of what ought to have been is for others.
Cyber insurance · supplier liability · company counsel
What you can use it for
For every day from the admission onwards:
- Who was registered as the holder, and through which registrar?
- Which name servers were authoritative, and on which day did they change?
- Where did the domain point, and what did the mail and policy records declare?
- What did the domain actually serve to a visitor on that day?
- Was it under any registry status such as a hold or a pending transfer?
- You name the domainYours or another’s. We do not ask what the matter is.
- Both witnesses ask the sources directlyThe registry over RDAP, the authoritative name servers, and the domain itself.
- The day is sealedEvery observation of the day is reduced to one fingerprint.
- The root is anchored outside this archiveHanded out of the house the same day, so it cannot be corrected later.
The name-server answers are taken from the authoritative servers, not from a resolver’s cache, so what is recorded is what the domain itself published that day and not what some intermediate had kept.
Typical use: the record itself is rarely filed. What goes into the file is the twelve-month record drawn from it, because a domain dispute is argued on the sequence of holders, name servers and content rather than on a single day.
What is recorded, field by field
From the registry, over RDAP (the published successor to the old directory service): the answer as delivered, naming the registrar, the registration and expiry dates, the status codes a registry sets on a domain, and the name servers it lists.
From the authoritative name servers, asked directly: the records that say where the domain points and what it declares, its name servers, its addresses, its mail routing, its policy records including the ones governing mail authentication and which authorities may issue certificates for it, and whether the zone is signed. Stored as the answer that was given, with the server that gave it.
From the domain itself, as in every standing observation: the front page and the four machine-readable files at its root (robots.txt, ai.txt, /.well-known/tdmrep.json, llms.txt), in full, with headers, certificate chain and time of retrieval.
All of it goes into the same daily seal as every other observation, and the registration and name-server answers carry their own provenance, recorded separately from web retrievals because they arrive by a different route and a later reader must be able to tell which was which.
Full field-by-field schema, with a worked example: what we store.
What is not recorded
Only what the registry publishes. Where a holder is a private individual, registries redact the personal fields and have done so for years. What is redacted at the source is redacted in the record; nothing is looked up elsewhere to fill the gap, and no attempt is made to identify anyone behind a redaction. Where a holder asks to be excluded under the privacy notice, that takes precedence over any booking.
No assessment of any of it. Whether the mail records were adequate, whether a certificate policy was prudent, whether a transfer looked irregular: none of that appears. This archive states what was published, and the question of what it means belongs to the people arguing the case.
Bytes, not pixels, and nothing behind a login.
And no notification: if the holder or the name servers change, you will not hear from us, because a witness that alerts one side is no longer a witness to both. The change is in the record, and the record is where you look for it.
What sealed means here
This block is the same on every page of this site, and it is repeated on purpose: it is the part you need in order to judge everything else.
- One fingerprint for the whole day. Every observation made that day, yours among hundreds of thousands, is reduced to a single hash through a Merkle tree. One changed byte anywhere in that day, and the fingerprint no longer matches. There is no version that could be quietly corrected.
- Published where anyone can see it. The fingerprint goes into the public log the same night, under a fixed, citable URL, together with the instructions for recomputing it.
- Handed out of the house three times on the same day. An RFC 3161 time-stamp service, a decentralised OpenTimestamps anchor in the Bitcoin blockchain, and a qualified eIDAS time-stamp from GLOBALTRUST (e-commerce monitoring GmbH, Austria), a qualified trust service provider listed on the EU Trusted List. The third of these is paid for and supervised, and it is worth saying so plainly: only the qualified time-stamp carries the presumption laid down in Article 41(2) eIDAS. A free anchor establishes that the data existed and has not changed, but it carries no presumption laid down by law.
- Twice over, by two witnesses that cannot write to each other. Two machines at two providers in two countries, with separate keys. Each seals its own day and takes its own anchors.
In plain words, two sentences. We cannot change a byte afterwards, because the day's fingerprint would no longer match. And we cannot backdate one, because that fingerprint has been in other people's hands since the night it was made. No one has to believe us: every step can be repeated with standard tools.
Further: how it works · what we store · glossary.
Does this stand up in court?
We cannot promise that, and nobody can promise it honestly: what a court accepts is for the court to decide. What we can tell you is what the document is made of, and each of the four facts below can be checked before you buy anything.
- It comes from a third party, not from you. Not your screenshot, not your server log. The bytes were fetched and stored by a third party that did not know your matter existed, on a day chosen by the calendar and not by the case. That is the difference between a record and an account of events.
- A presumption laid down by law. Every sealed day since 31 July 2026 carries a qualified electronic time-stamp from a qualified trust service provider on the EU Trusted List. Under Article 41(2) of Regulation (EU) No 910/2014 (eIDAS), such a time-stamp enjoys a presumption of the accuracy of the date and time it indicates and of the integrity of the data it is linked to. Article 41(1) says something much narrower, namely that a time-stamp may not be denied legal effect merely because it is electronic. The two paragraphs are routinely confused; the one that matters here is the second.
- Two independent witnesses. Two machines, two providers, two countries, separate keys. Each one seals its own day and anchors it externally on its own. Neither can write to the other, so neither can be corrected to match the other after the fact.
- Verifiable without us. An appointed expert repeats every step with standard tools: recompute the hash of the file, rebuild the path from that hash to the day's root, check the root against the public log and against the external anchors. We do not have to be believed, and that is the point of the whole construction.
What follows from this in your particular matter is for your lawyer to say. We do not advise, do not rate and do not take a side, and the other side can order the same document on the same published terms. That is not a weakness of the document. It is the reason it is worth anything.
How to order
- By e-mail to contact@machinewitness.eu, or through the form on this site. Name the domain, and your billing address with a VAT number if you have one. We do not ask what the matter is.
- We confirm in writing what we received and name the fee for your request. Nothing is charged before you have that in writing.
- You receive a payment link.
- Nothing is delivered at this stage, because what you are buying is the record itself. Extracts drawn from it later arrive within five working days; where a court deadline is running, say so when you order and we handle it within 48–72 hours instead, ahead of the normal queue.
- We name the date from which the daily record can start, in writing, before anything is charged; from that date the domain is entered in the public record and asked daily.
We answer in German, English or Spanish.
Fee
150 € per year per domain, charged yearly in advance, as set out in the fee table. A set of domains larger than twenty is not only an order but a decision about what this archive observes, taken openly and on the record. Nothing is charged before the starting date is agreed in writing, and if the year is not renewed the days already recorded stay sealed and available as extracts.
Form of the result
The admission itself: a dated entry in the public record, on both witnesses, checkable at any time through the coverage check. There is no document at this stage, because the document is the twelve-month record drawn later from the days that were recorded.
The method sheet is included. Every extract comes with the general method sheet at no extra charge, including the one covering a single day. It describes how this archive observes, seals and anchors, and it carries a version and a date. It is not written for your matter, and it does not have to be: it is the same for everyone, which is precisely what makes it checkable.
The technical procedure statement is a different document, written for this particular observation, signed and addressed to a court or an appointed expert. You do not need it in order to file the extract. It becomes relevant when the other side disputes the method rather than the content. See the fee table.
What becomes public, and what does not
Visible to anyone
- that the domain or URL is observed, and from which date
- the dated entry in the public record of admissions
- the daily roots and anchors, as for every other observation
Never published
- who applied, in no document
- why: we do not ask what the matter is
- what the files said: content is issued only as an extract, at the published fee, to anyone
The other side can see that the URL is observed, and since when. That is the price of a witness that belongs to no party, and it belongs here, before the purchase, not in the small print. Where a look-alike domain is observed as a precaution, an opponent may infer that someone is preparing. Whoever does not want that buys a capture of a single day instead of a standing observation.
Neutrality. This archive records; it does not rate, rank or advise. Three conditions hold for everything on this page: it is visible to everyone in the same way; the fee is published and depends neither on who asks nor on how a matter ends; and whoever pays receives nothing a third party would not also receive, which means no notification, no mention as the applicant, no priority, and no content without an extract that anyone else could order too.
Further reading: how it works · evidence extract · terms, section 5.