Finding an onion address, and who learns that you asked

An ordinary domain has to be looked up by a resolver that sees the name you asked for. An address ending in .onion is located a completely different way.

The address is derived, not registered

Nobody issues an onion address. There is no registrar, no application, no renewal and no central list. The long string is a printable form of a public key belonging to the service, together with a checksum and a version marker. Whoever generates the key material has the address, and nobody else can produce the same one.

Two consequences follow from that, and they pull in opposite directions. The first is that the string is long and awkward, because it is carrying key material rather than a word somebody chose. The second is that reaching the address and reaching the holder of the key are the same event, with no third party in between asserting that they match. That property is discussed further in exits and onion addresses.

How the lookup happens

A service that wants to be reachable publishes a small signed document describing how to contact it. That document is placed at a handful of relays acting as directory positions. Which relays those are is not fixed forever: they are determined by a rotating schedule derived from the address and the current time period, so the set moves on a regular cycle.

A client that already holds the address can compute the same set of positions for the current period and ask one of them for the document. The request travels over a Tor circuit like everything else, so the directory position is answering a circuit rather than an address.

The identifier used in that request is not the readable address. It is derived from a blinded form of the key, which changes each period. A directory position therefore holds and serves something it cannot turn back into the address a person would type, and it cannot compile the documents it happens to be storing into a readable list of services.

What a directory position learns

Learns

That some circuit asked for a particular derived identifier at a particular time.

Learns

That it is currently one of the positions responsible for that identifier this period.

Does not learn

Who asked. The request arrives through a circuit, so the address behind it is not present.

Does not learn

The readable onion address, because the identifier it was given is a blinded derivative.

Does not learn

Anything about what happens afterwards. It is not in the connection that follows.

That last line matters. Answering a lookup is a separate act from carrying the conversation. A directory position hands over a document and is finished. It is not the meeting relay, it is not a middle in the resulting circuit, and it has no view of anything you then do.

Contrast with an ordinary domain lookup

Ask for an ordinary website and something, somewhere, sees the name in readable form. On a normal connection that is your ISP resolver or whichever resolver the device is configured to use, and the record is a plain list of names asked for, by which subscriber, at what time. Encrypted DNS moves that record to a different company rather than deleting it.

Fetch an ordinary site over Tor and the resolution is done at the exit, so the exit operator sees the name. Fetch an address ending in .onion and neither of those things happens. No resolver on the ordinary internet is asked anything, your ISP sees only that Tor traffic exists on the line, and the readable string never leaves your client.

Ordinary domain, no Tor

A resolver sees the exact name and knows which subscriber asked.

Ordinary domain, over Tor

The exit sees the name. Your address is not attached to it.

Onion address

A directory position sees a derived identifier. Not the name, not the asker.

What the network cannot tell you about an address

The lookup mechanism answers one question: is there a current document published for this identifier. It does not tell you that the service behind it is the one you meant to reach, that it is run by the same people as last month, or that it deserves anything from you. Those are questions about the world, and the network has no opinion on them.

This is why the practical risk around addresses sits outside this section entirely. A string that arrived from the wrong place will be located just as efficiently as the right one. The relevant cards are copying an address to the clipboard, where a substitution would happen, and asking someone for help, where a string is handed over by a person.

This site follows the same rule about itself. The addresses at the top of every page are reproduced as supplied, with no test, no status and no claim that any of them work.

What changes the answer

5 things change how much this action gives away. None of them takes it to zero, and none of them is a promise.

1. The lookup keeps your ISP out of the name entirelyNo ordinary resolver is consulted, so the readable string never appears in a subscriber level query record. What your line still shows is that Tor is in use, which is opening Tor at home.
2. A rotating identifier limits what a directory position can accumulateBecause the value derived from the key changes each period, a directory position holds a different identifier for the same service over time and cannot build a stable readable list from what passes through it.
3. Where the string came from is the real questionThe mechanism cannot distinguish a correct address from a plausible wrong one, because both are just keys. Copying an address to the clipboard is where that goes wrong in practice.
4. A saved bookmark moves the problem to your diskKeeping the string locally avoids retyping it and creates a record on the machine at the same time. See what lands on the disk for what that means.
5. None of this says anything about availabilityA published document is not a promise that a service responds, and this site does not check. Nothing here should be read as a status claim about the addresses at the top of the page.

What this card is not

This is a description of how a lookup is structured, not instructions for interacting with the network directly, and not a verification method. It cannot tell you an address is correct.