We should at some point probably look into banning or de-prioritizing relays hosted under the 4 AS's listed above, given enough network capacity.
Or maybe only allow x% of guard / middle / exit fraction per AS and then de-prioritize. 2020-08-24 21:17 GMT, nusenu <[email protected]>: > Hello CypherpunkLabs, > > I noticed your set of new relays and wanted to say hi, > welcome you to the Tor relay community > and give you a few recommendations and pointers especially since you are > aiming to run 100 tor relays. > > > The Tor relay guide has a lot of useful information, so you probably want to > start there: > https://torproject.org/relay-guide > > Since all your current relays appear to be OVH based I'd like to point out > the following > quote from the guide: > >> Try to avoid the following hosters: >> >> OVH SAS (AS16276) >> Online S.a.s. (AS12876) >> Hetzner Online GmbH (AS24940) >> DigitalOcean, LLC (AS14061) > https://community.torproject.org/relay/technical-considerations/ > > The reasoning behind this, is that those hosters are already hosting many > tor relays, > and the network dislikes centralization. OVH is the biggest commercially > available tor hoster in terms of exit capacity > today already. > > > Depending on your per-relay size you might end up running a big fraction of > the network and > especially big exit operators are encourage to take care of their DNS > resolution. > Specific guidelines can be found here: > https://community.torproject.org/relay/setup/exit/ > > IPv6 connectivity is also encouraged (which currently none of your relays > appear to have). > > Especially for big operators it is recommended to managed their relays using > configuration > management (puppet, salt, ansible, ...) and update them regularly. > > An ansible role for Tor relay operator (I maintain) can be found at: > https://github.com/nusenu/ansible-relayor > > The ContactInfo Information Sharing Specification is a spec about a machine > readable ContactInfo string: > https://github.com/nusenu/ContactInfo-Information-Sharing-Specification > > Your site suggests that you (will) run bridges and exits. > Combining these two types of nodes under a single operator is generally a > bad idea since tor's MyFamily configuration is not supported for bridges, so > users might end up > using your bridges _and_ your tor exits - which puts them at risk should > someone compromise you, please > consider running non-bridges only. > > For strong protections for your long term relay keys > you can use tor's OfflineMasterKey feature, > especially relevant if your run a big fraction of the network: > https://2019.www.torproject.org/docs/tor-manual.html.en#OfflineMasterKey > > > kind regards, > nusenu > > PS: don't forget about your MyFamily setting if you do not choose a > solution > that manages that for you automatically. > > > -- > https://mastodon.social/@nusenu > > _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
