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 nusenu-lists@riseup.net:
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.