Re: [tor-relays] Hello CypherpunkLabs Tor relays

[William Kane <ttallink@xxxxxxxxxxxxxx>]

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@xxxxxxxxxx>:
> 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
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays