October 2025 - tor-relays - lists.torproject.org

GeoIPFile option warning
by krishna e bera 27 Jun '26

27 Jun '26

I am seeing these warnings in Tor's notices.log: Mar 24 09:42:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Mar 24 09:42:21.000 [notice] Configured to measure entry node statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. However the option is set in torrc and i verified the files are at those locations and readable by all: GeoIPFile /usr/local/share/tor/geoip GeoIPv6File /usr/local/share/tor/geoip6 Any hints how i could check whether the warnings are spurious or dump what the running config actually is? I know it is reading the torrc because introducing an error in the file stops it from loading.

2 2

upcoming CIISS update
by nusenu 01 Feb '26

01 Feb '26

Hi, I'm working on a new contactinfo information sharing specification version. Current version (2): https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ Some likely changes will be: * add happy family proof https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/407/diffs * add signal username field https://support.signal.org/hc/en-us/articles/6712070553754-Phone-Number-Pri… * maybe add keyoxide field as suggested by boldsuck: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/iss… Feel free to send me your suggestions and opinions before 2025-06-30 by creating github issues or by replying to this thread. kind regards, nusenu -- https://nusenu.github.io

3 5

abuse report from relays in family 7EAAC49A7840D33B62FA276429F3B03C92AA9327
by Dimitris T. 29 Dec '25

29 Dec '25

Hey all, got an abuse report today from Hetzner concerning one middle relay we're running there. allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA27… (just from family relays in 96.9.98.0/24 range, all using ORPort 443) anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp? thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans... best, d.

14 29

Add CGNAT 100.64.0.0/10 to Default Exit Relay Reject Policy
by admin＠likogan.dev 03 Dec '25

03 Dec '25

Hello, I've noticed that the non-publicly routable CGNAT subnet of 100.64.0.0/10 is not in the default exit policy reject list like 192.168/16 and 10/8 are. This range is not publicly routed, and should never need to be accessed from a Tor exit. Tailscale and other ISPs use this block. How many exit relays connected to a Tailscale network are unknowingly exposing all of their other Tailscale devices to the Tor network? ISPs may be less willing to allow exit relays if there are bots using Tor to toy with the ISPs 100.64/10 range. Maybe there is something I am missing for it to not be included? Thanks, Likogan.Dev

3 2

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

Being banned?
by Brian Henderson 25 Oct '25

25 Oct '25

Hi, first time using this group so I hope I am not braking any rules. I wanted to ask others if they have noticed themselves getting blocked from certain sites (such as banks) because they are running a tor relay? I have checked my ip on various lists and it seems two rarely used lists have a ban on a group of numbers from my isp, but not my number specifically. I have been using my bank for years from this connection, now i seem to be blocked and it coincides with starting to run a tor and i2p relays. I have tried to access the site from different software but it just hangs. The bank claim they are not blocking me. Anyone else had this type of problem? Brian.

6 5

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 25 Oct '25

25 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > IPv6 is locally resolved by each relay. If this fails, probably > because some DNS servers are IPv4-only, the relays shall forward > their queries to 1-2 central DNS resolver with IPv4 addresses. That would probably be doable, but it would negate the privacy and the security benefit of running a local DNSSEC-validating recursive DNS resolver. When I run my own, I can be sure that it's using a local copy of the root zone, that it's using QNAME minimization and aggressive- NSEC, that it's up-to-date and is aggressively caching negative answers (which are very common over Tor), etc. Perhaps I could have the resolver prefer IPv6 and if the nameserver doesn't support that, it could fall back to the exit's IPv4. If the nameserver blocks Tor, *then* it could be sent up to some privacy- friendly upstream resolver. I don't know if Unbound can be configured to do that natively. It might take a small patch. > The overlap of DNS servers that are IPv4-only and block Tor relays > might be small enough to tolerate the issue or just use a friendly > public resolver for them as fallback. I don't think it would be enough to tolerate the issue. Failures to get answers from big nameservers doesn't just break a few websites. It can break an entire zone. You may find that all .hu domains that lack IPv6 will become unreachable. Using a friendly public resolver as fallback, or even falling back to a high-latency resolver on one of my other nodes, is probably preferable. > In any way, I hope you enable IPv6 on your relays (start with DNS). > Because the IPv4 shortage only gets worse over time, and enabling > IPv6 is a (partial) way out, even already today. I have IPv6 enabled on all my exits that support it. Some of them do not support IPv6, but that is the fault of budget basement datacenters running in Romania, and not my own network config. ;) Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj84v8ACgkQBh18rEKN 1gseMRAAi/g6rB/Bj84IepqIB2y+BVW4klxae7IYrSFK4YNezlpNjCp4BWZIZTlS lNL3jD6w7iJmJyxKXFmpwn+bEmv5sdin15j2LHn8486L+F72XyVmogHH5rQ7Bxn8 yITnjr8EBsfEWrLZQRmmPjfqgSXXUo2r8JDN42KdivASzFh4skrQY/N8f79/fKtL qJp5FohU+Z4BFRCkgdR4wNIpQeysp6cxm3cyOVUay/ZnWNB2yQDaoT3JKsV8JlDD nzIwLqYBiNZp/qALoVWEqdy0Ohzq1Sj6WtHZHbvlQNvOH2G2nAYwRFzcHYlrdrjz TRY91oqeFgEv0TeeXbc+rcSbPwz34mQTXy80VxhuMhNmihrwI7h6kDHWQ9FNTu6I joOZIOJWTxRNaAWLEauk2j+xSOxB3wHfuyjLtXfZjyGzHiicVzi126DKf8nqWaJX hmOnlM0pdeZwgYojG9j777pLN+K01QEK8JVvtrKvHXxVx4k0jbQ/9EcdhHG5PnNd skeCiex+8x7vnSH8/nr4l3x291gKr8vFJqIK64Whq2niAkK8xw6YrIYlvVUSD/4/ HESlYMZW7STS6f3VdnzW9fvYFU+voiQ4wCLCn5wwq/VoI1CxDYRX8QdnT+ra2ogF HgEBplSu3MNQpDAhbYRJy2FVYh9BlcdgXmYrd0yoyK14x2mrzvA= =2u/4 -----END PGP SIGNATURE-----

2 1

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 25 Oct '25

25 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > You should definitely try setting up IPv6. Essentially, your problem > is rooted in the limited number of IPv4 addresses. With IPv6, you > most certainly can have more than one IPv6 address on every VPS for > free. Using IPv6 wherever possible tackles the root issue. This would only work if all nameservers support IPv6, no? I would still need to use IPv4 for the nameservers that don't, which means continuing to pay for the extra IPv4. What I'm thinking of doing is choosing a single reliable exit in each geographic location that I run, and using it as the upstream DNS resolver for all the other relays in the region. Thus I can use one relay in the USA to serve my relay in Canada, and one relay in Moldova to serve other relays in Europe. I would only need to pay for an extra IPv4 for each geographic region, and wouldn't have to suffer from the nasty >200ms latency incurred through transoceanic cables. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj7ch4ACgkQBh18rEKN 1gu6jBAArMfWI6mXe6Ce+9UUQ8FQPgxDYjiySBij3QqN3NmM2N0TGxU/+wjldLrP wE/1zFjuTTQfZsOXJcLd13kmiqpt4jFRVAe+d0vpdfMkIppbDRmYRlcGrn7k1YwI Sdac1Dd3bUxRU3XLF/tVKeDjAsU55qu7el7qkd7RdhPjQ1IYV6GIzJPANcaREzv1 m6DBkkTAgkqvBVAQTFbOWLkLYL8KGXYTSjp14ZxB0SH8wrDKaZ/Hb0ASHlDYO7J8 lgjgR1fjfj13IlyjyRLlSeZiXmvHgi1W3NBLwp6nR2V1uwQ+VB7IIkjg+TJ3EN3x wMt1xCmqX9wqsfUgjR5wHJMFNu1maAgdMRUTSWDj0g1P4A4Dvvq1zQJUPtRViZsM 7NzgyrEqWd9gXHAxbP/82eM8QYbzflXEwtz5YFLDhFnXx1sQfE911pE3fklYMnEX SnyslYhK76Xg+E59Q6sGgKYnWyJSPIr88/KouTYKdqbywmg3duEM8a0tp/lLte6o nuA/HI83+sGrSnxGF8cZy8GOY6+MepzUEwX8uQlYSE9RNu/owqF3pCRpyJ6E6udz QvlSzQy6a8d8CewUQ6G8cQETAoSadaEsPdZzaEAj/6jgThTcZKnMnUFx3G/6VM2c ykHHoe6dBLlmesiqirXOiT99Hel09yvlI07H82kmT2JmRcqgUak= =M4IK -----END PGP SIGNATURE-----

3 4

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 22 Oct '25

22 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Don't forget to enable DNS over TLS! Of course. :) For my local resolvers, it's not possible of course, but it is DNSSEC- validating. If I use any kind of centralized upstream resolver, whether I operate it or not, I'll only use DoT/DoH/DoQ. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj41AcACgkQBh18rEKN 1gtybw/8CPyLiyhSzl5Bdze4kcO6/EvZlrZAh7oJTdkHALYdzItPs9qGN/OGTHzh mUD2TOqQ4sAIPeuq+n5Xs47zGefVjPt2aVpzJ7yKfzsrS6CQA8VtJrtAsuZIdGxg qjAgis87rLCH2t2x+xfArx65txfp6HhWkzLIUWhbwEDM6PLFTNSi5WVm0BCNwXOt 8pNYfzqlil1HhGjghlnA/B47VAvSnGlozUUFF6yVEoCVglKrRgFCdx24auj2p/Hf /87hIfeZ+UeMSKoRcwQ8JoZeFuDDs7WxdbJh3qFc9T+2hdb77CXciYaVO3+bJR3G IfkZPqKKCNdm982TU2wzy+wDghcfrs6VObk5m4GJoWbltOxSmyX3+Ld5ycDMtRQR EBiSdGM7+QCO82b/zNcCWIOD73ZiDkpe3d3poRAJd0/Bv8EvKsXv2hEhPGE+0eRe NnDwYGLJhwo/sWYeHC5Yr/iHFWr8aq87HnvxaF4GNsrpNlcs+Dnx9UFmLa+Jn41A E8OSZMB9WXmnVQvptrVUg1yx9mo1KloQSq+EhbF5nD7VbFEmJSz+MIg7p4xbMl0L pDg2qt2i9Xl9wp8DQVo+KjO1u05jMzmny93xSkaS2tyDndv0O2eaNzjnf4+GLjsA Pnum5/VRD2EOw1YdIlQ58ENhQDLSlbQXdU4/HwDziutmFlWtuK0= =ct/a -----END PGP SIGNATURE-----

1 0

Relay Search page is showing extremely low BW speed
by am 22 Oct '25

22 Oct '25

Hey there, My VPS is dedicated to running a Tor relay server, so the performance should be good. However, your Relay Search page (metrics.torproject.org) now says the speed is only just "XXX KiB/s"! (X is a number) This should not be true. I ran the `speedtest --secure --server XYZ` on the server in question, and it returns: Using server A Download: 98.34 Mbit/s Upload: 120.44 Mbit/s Using server B Download: 88.81 Mbit/s Upload: 104.86 Mbit/s Using server C Download: 94.34 Mbit/s Upload: 103.05 Mbit/s I also checked the firewall configuration, and it did not limit anything. Are you sure your network measurement server is not overloaded? How about teaming up with speedtest servers to measure real network value? So the questions are: Q1. Where are you measuring this from? Q2. If the Advertised BW is just this low, doesn't my Tor relay won't be used at all?

2 1