With my approach, you wouldn't need a Tor client to browse the forums and it would be dedicated to Kiwifarms, with no criminal, drug dealing or pedo backstory. I'm sorry if my idea sounds stupid or overly idealistic, hoping that the community has enough nerds willing to help. I just thought I'd throw in my two cents.
No need to apologise — it's a good-faith idea, and some version of it gets proposed in every thread like this one. It's worth writing out properly why a volunteer-run frontend doesn't work, because the reasons aren't obvious and they're precisely why the current setup looks the way it does.
You actually spotted the fatal problem yourself in your edit, so I'll start there.
1. It invites the attacker inside the perimeter
The threat model here isn't random internet noise. It's a small number of dedicated people who actively want to harm this site and the people who read it. An open volunteer programme is an open invitation to those exact people to sign up.
A frontend node has to do one of two things:
- Terminate TLS — which means handing the certificate's private key to strangers. Anyone holding it can transparently decrypt and rewrite traffic: harvest logins, steal session cookies, read DMs, impersonate staff, inject anything they like into pages. A single hostile volunteer compromises every user routed to them.
- Pass TLS through (SNI-based TCP proxying) — safer, no key exposure, but the node still sees the source IP of every connection, can log it, can selectively drop or delay traffic, and can correlate who is reading what and when.
There is no way to vet volunteers at scale, and DNS hands each visitor a node at random, so users can't choose a trustworthy one. You'd be asking people to route their traffic through a stranger who may well be the person attacking them.
2. Residential connections mostly can't accept inbound 443 anyway
Setting the trust problem aside entirely, the plumbing doesn't cooperate:
- A large share of home IPv4 sits behind CGNAT — the subscriber has no public IPv4 of their own and cannot port forward at all, regardless of what they do to their router.
- Most consumer ISP terms of service prohibit running public servers, and plenty block inbound 80/443 outright.
- Residential IPs are dynamic. They change on lease renewal, reboots and outages, so records go stale constantly.
- It assumes every volunteer can correctly configure port forwarding and then keep a box patched and online 24/7. Most can't, and a neglected node is a liability rather than an asset.
- Plenty of corporate, school and mobile networks blocklist residential ranges outright, so a chunk of users simply could not reach whichever node they were handed.
3. The bandwidth maths runs the wrong way
DDoS mitigation works when you have
more capacity than the attacker. Residential lines have dramatically less.
Home connections are asymmetric — a typical upload is a few tens of megabits against a gigabit download. This is an image and video heavy forum; a handful of users pulling attachments would saturate a domestic uplink on its own, before a single packet of attack traffic arrives.
More importantly, pointing DNS at someone's house means
pointing the attack at their house. When their node gets hit it doesn't degrade gracefully — it takes out that person's home internet, their family's connection, and quite possibly their ISP account once the abuse complaints land. Volunteers would also burn through monthly data caps in short order. You would be asking civilians to absorb attack traffic on domestic lines, and the people throwing that traffic would enjoy it enormously.
4. It's a privacy disaster in both directions
- Volunteers' home IP addresses would be published in DNS, permanently associating their household with this site. That's a doxing, harassment and swatting vector, plus abuse complaints and potential legal exposure depending on where they live.
- Users would be handing their real IP addresses to unvetted strangers. For a site whose readers often have genuine reasons not to want that logged, this is materially worse than the commercial provider everyone was glad to see the back of.
5. DNS rotation doesn't hide the pool
Rotating a subset of records conceals nothing. An attacker simply queries repeatedly from many resolvers and enumerates the entire pool within hours — it is public data by design. Meanwhile resolvers and browsers cache aggressively and routinely ignore short TTLs, so you cannot actually pull a node out of rotation quickly; users keep landing on dead or actively attacked nodes for as long as the cache holds. It also makes the DNS provider a single point of failure for takedown pressure, which is the same dependency that caused the last problem — as you rightly noted yourself.
6. On Tor specifically
The onion service is the one option that exposes nobody's address — not the servers', not the users', not a volunteer's. That is a real technical property rather than a compromise. The "backstory" objection is about perception rather than function, and it's worth noting that relaying traffic for one specific named site from your home connection carries
far more personal legal and social risk than running a Tor relay does.
Finally, the professional version of your idea already exists. The site sits behind a network of dedicated reverse-proxy nodes, run by people who understand and have knowingly accepted the risk, on connections built for it, without handing private keys or user traffic to strangers. Same concept — implemented the only way that is actually safe.
Genuinely, thanks for thinking about the problem rather than just complaining about it. The instinct is sound; it's the volunteer part specifically that turns it from a mitigation into a new attack surface.
