Understanding Dread Forum Uptime and Onion Address Rotation

A .onion address is not a registered name like example.com. It is the public half of a key pair, derived directly from the service’s long-term identity key. If the operator loses that key, restores from an old backup, or decides to rebuild the hidden service from scratch, the old address simply ceases to map to anything and cannot be re-created later. This is why continuity depends on the key, not on the name.

Think of the address as the service’s fingerprint. Before the migration to longer onion names, a v2 address might be abandoned when its key format became obsolete, forcing every active service to generate a new identity and therefore a new address. The result looked like the forum “moved”, but the underlying reason was cryptographic: the old name could no longer prove the same identity under the new rules.

A journalist saving a Dread URL locally often assumes that the address will behave like a bookmark. In practice, it behaves more like a temporary access ticket. The ticket remains valid only while the operator keeps the same key, while the hidden service descriptor is being published, and while the introduction points remain reachable. When any of those change, the old ticket is dead even though the forum itself has not gone anywhere.

Why the change is unavoidable

• The address is not a domain name
• Hidden services are self-authenticating
• Operational recovery may require rotation

A parent who uses Dread occasionally might wonder why the same address did not stay online like a regular news site. The answer is that a normal site can keep its domain while moving between servers, but an onion service cannot separate the “brand” from the “key”. As soon as the key is gone, the brand is gone too, and the only honest way back is a different address that has to be verified all over again.

This arrangement is protective by design. If an attacker seizes a server but does not obtain the identity key, they cannot keep serving the same onion address. The disappearance of the old address is not always a sign of failure; it can also mean that continuity has been deliberately broken to prevent someone else from impersonating the identity.

Identity key

the private key whose public form produces the onion address; losing it means losing the name

Rotate

to generate a new identity key, which necessarily produces a different onion address

Descriptor

a signed record that tells clients where to find introduction points for a hidden service

A mirror is a second, third, or tenth door into the same room. Each address points to the same forum data, but the path, exit capacity, latency, and administrative surface differ. When one link becomes unreachable, the model continues through the others; there is no master switch that failure can turn off.

The survival shape

Most users first meet Dread through one onion address saved weeks or months earlier. That single entry looks stable until it silently stops loading. Mirrors exist because this moment is expected, not because an emergency is happening. The forum is not “down” when one saved link dies; the visible surface has shifted.

• Saved address stops loading This is the normal trigger event, not a security alarm.
• User opens a different mirror from a verified source The second address may be slower or show a captcha, but the identity of the forum remains.
• Session continues on the mirror Posts, messages, and reputation remain tied to the same underlying service, not to one URL.

What actually differs between mirrors

• Different circuit latency and timeouts
• Different captcha or anti-abuse behavior on first load
• Different risk of being listed in public link collections and therefore cloned
• Different availability depending on your exit region or Tor version

A link that works for one person may fail for another at the same time. That is not proof that the forum moved; it is proof that the address is a route, not a building.

The mirror model shifts your responsibility from finding one permanent URL to curating several verifiable doors. Each extra mirror reduces the chance that a single network event separates you from the forum, while also increasing the surface for phishing if you collect links carelessly. Verification, not the number of links, is the actual safety mechanism.

A journalist following a civil rights story may have no way to distinguish the real Dread from a state-built clone merely by looking at the page. Both can copy the logo, the dark background, and even the thread titles. The anchor that remains is not visual identity but cryptographic identity.

Signatures work because they bind a statement to a key that is hard to impersonate. When the forum operator signs a list of mirrors, the signature can be verified with a public key that stays stable even while onion addresses rotate. A familiar .onion URL proves only that you reached something at that address; a verified signed message proves that a particular keyholder vouched for that address.

What a signed message actually gives you

The typical path looks like this, from the side of someone who has just found an unfamiliar mirror link.

1. Finding a claimA user sees a mirror link on a paste site, in a messenger group, or from another forum member.
2. Checking the statement The link comes alone, or sometimes with a signature block: the address, a message, and a signature.
3. Reaching the key The user obtains the operator's public key from a source they already trust, often saved weeks earlier when they first entered the forum.
4. Verifying locally They verify the signature against the key. If it matches, the mirror is now linked to that key.
5. Acting on itThey use the mirror, but only after verification; the URL alone never gets upgraded to "trusted" status.

The signature does not make a mirror immune to downtime or seizure. It answers a narrower question: Did the operator of Dread authorize this address at some point? If the answer is yes, the risk shifts away from "I am typing my password into a clone" and toward "this mirror may no longer be the operator's current choice."

A common misunderstanding is that “checking Dread” must begin with a date-stamped announcement or a trusted person telling you which address is alive right now. That assumption reverses the order. In practice, availability is a property you verify locally, not a claim you import. A student with ten minutes between classes can run the same check as a journalist on a deadline: open the folder where your verified mirrors are stored, pick the most recently confirmed one, and treat the result as a measurement of that mirror at that moment — not as a verdict about the forum as a whole.

The under-ten-minute routine

1. Open your local note with previously verified onion addresses and signed messages Avoid starting from a search engine or a social media post, because neither preserves the continuity you need.
2. Step Pick one mirror, preferably the one you last used successfully, and load it in a Tor Browser tab.
3. Step Compare the visible subdomain or directory path against your own note before interacting with the login field.
4. StepIf it loads, use the signed-message check described earlier to confirm that the page still matches the identity you already accepted.
5. StepIf it fails, wait briefly and try a second verified mirror from your list — not a new address found ad hoc.
6. Step Record the result locally: mirror, time, success or failure

The point of a fixed routine is that it removes the need to interpret rumors. You are not asking “does anyone know if Dread is down?”; you are answering “can I reach the mirror I already trust?” That answer is worth more than a timestamp, because it includes your own connection path, your own Tor exit, and your own saved context.

Availability check

a local test of one known mirror at one moment, not a statement about all of Dread

Signed message

a cryptographic statement by the forum operator that can be verified without trusting the page that displays it

When a known onion stops resolving, treat the failure as an unconfirmed event, not a sign that the forum is gone. The address may be rotated, a mirror may be under load, or a network path may be temporarily blocked. Do not immediately search for replacements through search engines, random directories, or social media shares; that is where cloned login pages concentrate.

First actions, in order

1. Stop entering credentials Close the tab and do not retype a password or PIN on any page shown at the old address.
2. Note the exact failure Record whether the browser showed a timeout, an onion descriptor error, a certificate mismatch, or a rendered page that looks slightly different.
3. Switch to a previously saved mirror Use only mirrors you recorded during earlier routine checks, not a new address discovered right now.
4. Check for a signed update Look for a PGP-signed message from a moderator or the service identity in channels you already trust independently of the onion address.
5. Wait and retry once several hours, then retry the same known address once before concluding it is no longer valid.

The reason for this order is simple: cloned login pages rely on urgency. A user who panics, clicks the first suggested link, and enters credentials gives away a password that may already protect other accounts. The safest first move is therefore non-action: close the browser tab and move to a second, previously verified channel.

How to recognize a cloned page during the confusion

• A cloned page may reuse the old design but changes the URL or the TLS indicator
• The login form may ask for a PIN that the original never requested
• Text may include minor wording errors, such as “signin” instead of “sign in”
• Links on the page may point to hidden services that differ by one or two characters
• A cloned page often appears instantly while the known mirror remains slow or offline

Signed messages are the core recovery tool. A moderator signature does not depend on any single onion address; the same key can sign a note saying “primary address rotated to X” or “temporary disruption, do not trust pages at old-address.onion.” Without such a signature, an address found in a forum post or chat is just another claim.

Recovery after a confirmed rotation

• Address stops responding The browser cannot reach the onion service or shows a clear descriptor failure.
• Check saved mirror list Open a mirror that was saved from the earlier routine, not from a new search.
• Verify the signed notice Read the message and confirm the signature against a key you already held locally.
• Record the new address Add the new onion to your own offline list together with the date and the source signature.
• Test without logging inLoad the new address and inspect the page visually before typing any credentials.