- tor-relays - lists.torproject.org

AROI Using proof:dns-rsa Not Getting Verified
by algo7 23 Nov '25

23 Nov '25

Hi there, I am trying to setup AROI for my exit relays following the guide here: https://nusenu.github.io/OrNetStats/aroi-setup I am using the DNS TXT records option. I already waited for more than 1 day; however, it seems like it's not getting verified for some reason. Here is the link on OrNetStats to my relay family. https://nusenu.github.io/OrNetStats/w/family/fb5e3cc1855a01ef74fc0843f63e3d… Relay Fingerprints: 2B51193205D091CC80B904D65721FF8DCBE51C96 61137FAC08E0AE62165D18FE8855CCCA26B6D631 Any help will be greatly appreciated. Thanks.

6 5

Running a relay and bridge on the same /24
by forest-relay-contact＠cryptolab.net 23 Nov '25

23 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I have several relays that each have two IPv4 addresses. One of them is used for an exit and the other is used to do recursive DNS lookups with Unbound, since some nameservers block Tor. The second IPv4 is not used for any other services. Often, both IPs are on the same /24, and sometimes they are even on the same /31 (for example, 203.0.113.38 and 203.0.113.39). Would there be any issues with running a bridge on the second IP? It has never been on the consensus or even connected to the Tor network. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkfVoUACgkQBh18rEKN 1gszdRAAyHUWkCH8Z54OMzyAmL/vU2jGNBSoSB/6EiaPaRoVhEj7AvboUeHYVzPk FA/9QKfYgkkHMJD6XHybbPxwAp9fQRJMmA3BOMYv5UES/KoMf3okbbh48xNnzT64 nQdw82FnFzuegfqCLymoBZULNBJdSr8vYAOi8JRCyt7igVvg/+tYCRCG1u1Sh5+P HogmmIhq4wQE329W9H/UmzBVLID1Zca+qAdvyVIdB95j/MxCz12TpIIcF0D6GsIj 41bjGJnQxbia2jyko/TMmgjNHwkE2oZhNpPclKSpVGwPbsplc62HRiX58Eucsr1B JKg3OSAKGzpz2pXYeTSClmNKmzL2vozSifd0vpRRAi3IXKQk/bKhG7St1bJH4LcT tH3w7pRZlbz2HnjLD2SKB/zau0axqaOOvPO9aCXi2Y2fSrvxjgLggtyIBy5szWZK 6s2HDCRMl6QS+FxMSB3ynincSoLildVEODzAOtzVoRWqlFAANr91/BfzSiWugaAj UPQX7CKJrsa3VOPjI3wi1qx36wQXXgWZ27o2/QSvqu0MiEF2ivuDwjRsNCyeDvu8 5J0SEQQ0aI1RdA4lUybcSUC3jUqlp3789ILEH90sOyXzAzgVT1HQ0ATHNit5oUkU K8FIYPWmFgNvpBybv4dErAnVMj/5p6yNP/KLr5PKr5wvJx9qp0k= =m7B2 -----END PGP SIGNATURE-----

2 1

tor log - Recommended versions are: 0.4.9.3-alpha (only)
by Felix 21 Nov '25

21 Nov '25

Hi, could someone please confirm: Nov 21 19:56:02.000 [warn] Please upgrade! This version of Tor (0.4.8.21) is obsolete, according to the directory authorities. Recommended versions are: 0.4.9.3-alpha Cheers, Felix

3 2

Short Knowlegde Sharing for DNS-Security
by providedlan＠arcor.de 21 Nov '25

21 Nov '25

1 0

New Relay Running Tor 0.4.9.3-alpha
by Tor Relay 21 Nov '25

21 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 To: tor(a)server-data.servebeer.com Subject: New Relay Running Tor 0.4.9.3-alpha – Fingerprint 29C57CA8D7E54CA674EA4CB88229F44815C2C207 (Unique in Italy) Hello Tor Project team, I am running a new relay on Tor 0.4.9.3-alpha. The relay is currently unique in Italy and fully operational. Fingerprint-Family: 29C57CA8D7E54CA674EA4CB88229F44815C2C207 Location: Bari, Italy IP: 109.116.219.235 Best regards, Tor Relay Operator -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5VwZ/q+VistGhWLUZTaefuiKQfUFAmkfqJcACgkQZTaefuiK QfUP6w/+LG7m/lcixbi1eZearrC2EaUnsuTWMsGDXX4nb7mM/ruehm6I82315oc5 iJsy2dhBoETDB8GJ25dnlg2TditypJIkzDTX8A5grtw9Hy2/pI+tFMl8bBm9HNC4 czwiidG4e20YpS8bvoZPH+cCv7sJeveNVq1mWm7XlZ3V6CA87ZZHIYdTG1kGpBDX D8JrVf60S72eD4StvDnckx4DZ2I50D/AVjwB1Qs47n/nxhxxsRJW3ZWVGxvLbQjx JTLQRgXKG5BvdP8tQpuv8mRF+rxe9Zbq7SF+67fPslbpuuBIGzxe5FPwdNns/J4r Ob2QFdT521KRaleUdD+SS173xFblMYCBvi1vC7NZiHlCvD0KogEuEDTTTLYWn89M +mhThkeNWZT8HHIfwfmArkdgeGpxKhQyGmuIbUQBbcIATEyIhmGDS30yweEUNSG2 z+0zpFn04qI+Nj7YkBFDhM76d9rNjqlPloHgZCptIzmyulixO7Z2Oo5ipzRQlz8f sYdA5TEkp68JvnPSW1/xnnEnrd4A8A8rAEe/qr5conBaegxIbRGfN83szD5G1aUN CfN/HvWQXGE8HTB5YMInwWnMRC1YRMZQ52YQV+Kb7wH9qI3FYvswYmfXPwks/kpO qH/dTAjLe0QPLYrw6TmgBHqbWCJMhvqOQuk0vviF2+RiQxY9ckc= =KWyG -----END PGP SIGNATURE-----

1 0

Accelerated depreciation of older versions?
by Nick Weaver 20 Nov '25

20 Nov '25

Was there an explicit decision made or an announcement about more rapid deprecating older server versions with the "Not recommended" flag? My test relay (tor.icsi-berkeley.org <http://tor.icsi-berkeley.org/>, I use it as my own guard on some tests) was running 0.4.8.18, and I noticed today that it had gained the "Not Recommended" flag which meant my client(s) would not connect to it as the choice of guard. I updated to 0.4.8.20 (as 0.4.8.21, although technically available, wasn't announced or linked to at the time on the Tor website). It lost the "not recommended" flag but regained it again as the current consensus now only has 0.4.8.21 and 0.4.9.3-alpha as acceptable versions. (so, well, update again)? Was this a deliberate decision or in response to a problem patched in 0.4.8.21 (and not announced as high enough severity to require immediate updating?) Is this going to be a policy going forward that relays should be updated within <12 hours of patch announcement? (also, tor26 basically likes everything BUT 0.4.8.21 because that hasn't gotten added to it, I think the Tor network might be disrupted if there is no agreement at all between the 3 authorities selecting recommended version, I think there could be a situation where there is no consensus on "recommended versions" if this isn't fixed) As of time of writing, from https://consensus-health.torproject.org/ moria1 client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha moria1 server-versions 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha tor26 client-versions 0.4.8.4, 0.4.8.5, 0.4.8.6, 0.4.8.7, 0.4.8.8, 0.4.8.9, 0.4.8.10, 0.4.8.11, 0.4.8.12, 0.4.8.13, 0.4.8.14, 0.4.8.15, 0.4.8.16, 0.4.8.17, 0.4.8.18, 0.4.8.19, 0.4.9.1-alpha, 0.4.9.2-alpha, 0.4.9.3-alpha, (Strikethrough: 0.4.8.20, 0.4.8.21 ) tor26 server-versions 0.4.8.4, 0.4.8.5, 0.4.8.6, 0.4.8.7, 0.4.8.8, 0.4.8.9, 0.4.8.10, 0.4.8.11, 0.4.8.12, 0.4.8.13, 0.4.8.14, 0.4.8.15, 0.4.8.16, 0.4.8.17, 0.4.8.18, 0.4.8.19, 0.4.9.1-alpha, 0.4.9.2-alpha, 0.4.9.3-alpha, (Strikethrough: 0.4.8.21 ) gabelmoo client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha gabelmoo server-versions 0.4.8.21, 0.4.9.3-alpha consensus client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha server-versions 0.4.8.21, 0.4.9.3-alpha -Nick

8 12

deprecating >0.4.8.21 tor
by George 19 Nov '25

19 Nov '25

Not to disrupt the other relevant thread, but it's worth noting that 41.1% of relays are already running 0.4.8.21... https://nycbug1.nycbug.org/onion-stats/relays-vers-count.txt ... covering 42% of the network bandwidth https://nycbug1.nycbug.org/onion-stats/relays-bw-by-vers.txt Huge thanks for the responsiveness of the relay operators! g PS, and the OpenBSD port was just updated and the FreeBSD port is still on 0.4.8.20. -- A3F5 9814 DDDC 2FAA E485 C354 7226 51EA 22B6 D315

1 0

Switch from relay to guard
by Too 17 Nov '25

17 Nov '25

Hi, I've been running a tor guard / middle relay from my home for some while. We have rotating IP addresses but since a lot of official websites (like governmental or banking ones) seem to block us with all of our IPs, we probably looped often enough for the information to spread. Also, we don't have that much bandwidth left for tor (in theory 4MiB/s). To avoid the blocking in the future, I want to switch to a bridge. I have a few questions regarding that: - Does it even make sense to switch to a bridge after already exposing the IP(s) for the guard / middle relay for some while? - Does it make sense to run a bridge if my IP rotates every night? - Should I shut the relay off and wait some while before starting the bridge, to get the IP(s) off blocklists first? - What kind of bridge makes the most sense in this situation? In case no bridge makes sense, I'm thinking about utilizing the server capacities for a guard / middle relay that pipes the traffic through a VPN instead; I found conflicting information on whether that's a good idea though. Thanks & kind regards Top (they/them)

2 1

High Memory Usage observed on Windows Relay
by providedlan＠arcor.de 16 Nov '25

16 Nov '25

1 0

Exit relays and DNS privacy
by foreststack＠dmc.chat 04 Nov '25

04 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I run several exit relays. I'm trying to keep them in diverse locations (South Africa, Moldova, USA, and Canada so far, with none in any AS that hosts more than 1% of network bandwidth). I'm using Unbound as a local recursive DNS resolver so I don't have to trust 3rd parties with the DNS queries. But I can't run Unbound on the same IP that exit traffic goes through because some nameservers blacklist Tor, so I use a second IP. With the price of IPv4s these days, this can inflate the cost of a budget VPS by a significant percentage of its original cost. Right now, Unbound is set up with prefetching and key prefetching enabled, DNSSEC validation enabled, QNAME minimization, a large cache and negative cache, and a local copy of the root zone (RFC 8806). Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT? The way I see it, that has a few pros: * By saving on IPv4 costs, I can run more relays. * An attacker who can monitor the outgoing DNS traffic doesn't know which relay it is coming from, as all relay DNS queries are mixed. * By sharing a single cache, there will be more cache hits and less need to talk to nameservers and expose queries to them. In other words, a nameserver would only know "someone on one of forest's relays looked up this site" rather than "someone on this particular relay looked up this site". But I can see there being a few cons as well: * By sharing a single cache, "timeless timing attacks" may become worse because a single lookup will prime the cache of all of my relays. * Due to their diverse geographical nature, some exits will have sub- optimal routes to the "master" resolver, which increases latency and allows more entities to know when and how many lookups my servers are making (although not what is being looked up, because of DoT). So what should I do? Run a local recursive resolver on each exit? Set up my own upstream resolver and point all my exits to it? Try to use the ISP's resolver and hope that they configure it well? Use some privacy- friendly upstream resolver like dot.sb? Use a DNS resolver hosted by a major exit operator, as suggested by Nothing To Hide in his blog post https://nothingtohide.nl/blog/improving-dns-privacy-on-tor-exit-relays/? I would like advice on the best solution here. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj3/7UACgkQBh18rEKN 1gtA5RAAj7k0/SbG/ki9uQCAG4MjxQAZU8nfjuIaVet7PRCpiLoH8obBSM6m7Gve Qb+AV+uOl3IwjUwu914opEZmSolZXRF2CJ4mX+dfZlbigRHqf0jCiBwOVChCMeDR lGGrFICZvH+t2Sy3totmlcWD57aHXkDux/0eNHj0c5VmfOQKiehSqF0IlK6xI3KC ozNzBaYjjdYdtsQetpeQ0ZEgtv/xU4a+DqiLh5MApCiyt0lP88nTUTuQ8tu1qL3j ijLoac2/ZXG2nlMrKkIB7qNDG1r5CsIb6BdJM/hyfNr1d23VqJfrlILYJFXi3ZAd GurC4tGb/3m2BqWEgzNu/zT/xZ99Ky5zSK+oJDKCeQ8OLaP1IvgviMB0yXLLozB9 NlJweJMn3c1mJ9TxvG1zWbrABee847bizb0ncwkv3ikrownWaSRW5n4v1SXHv/lO yLYjrNI7KJfqvgECgtYni5n4DBzW98pNkFrD3sBxtz0BUtngC6lXjN1ru9l4m5sW EiMS7ifAOnCTN8g8ipocBihYoNvsESmbjzUka63nrnqnvmG3tZB5oIR+WpvXnU3o hxxmlXfjAgmBNf4kuzlAfBRenFf0HkfE9y//YOmCJOgiZzuV6Tv040kkdUKtXbbS F4ZShpS04UvpniCKSBa3mn8Ft33GR01mRvgzRZ2dXv3heqqWlmo= =wsTY -----END PGP SIGNATURE-----

4 5