- tor-relays - lists.torproject.org

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

Re: tor-relays Digest, Vol 177, Issue 6
by Isaac Grover, Aileron I.T. 15 Oct '25

15 Oct '25

Good morning Brian, The bank may not be using these miseducated blocklist services, but their banking platform certainly might be. There's nothing you can do if the blocklist is blocking your IP address or even an IP block from your ISP. Best you can do is request a new IP address from your ISP, either by contacting their support or powering down your modem and hope it grabs a new IP address when it comes back online. On the other hand, if your specific IP address was being targeted, then if your ISP offers IP address blocks, then get a block and separate your relay from your main network using IP routing on your firewall. Make your day great, Isaac -----Original Message----- From: Brian Henderson <bhenderson001(a)yahoo.co.uk> 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.

1 0

relayor v25.1.0 is released
by nusenu 14 Oct '25

14 Oct '25

Hi, relayor v25.1.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v25.1.0 relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes: * Debian 13 is supported (please upgrade your Debian 12 relays because we plan to remove support for Debian 12 / Debian oldstable) * FreeBSD 14.3 is supported * increase minimal required ansible version from 2.16.14 to 2.18.1 **Note on upgrading from previous relayor versions** when managing Debian/Ubuntu relays A manual step is required when upgrading from previous versions on Debian/Ubuntu relays. To avoid conflicting apt sources make sure to move this file on your Debian/Ubuntu relays directly before running ansible-relayor v25.1.0 for the first time. You can use this command to move the file into your home: sudo mv -i /etc/apt/sources.list.d/deb_torproject_org_torproject_org.list ~ Make sure you did not edit the content of this file before. kind regards, nusenu -- https://nusenu.github.io

1 0

[Proposal] Tor exit lifecycle
by gus 14 Oct '25

14 Oct '25

Dear relay operators, We've drafted a new proposal for the relay operator community. The proposal introduces a lifecycle for Tor exit relays, inspired by the existing lifecycle used for Guard and HSDir flags. The main goal is to make it harder for attackers to quickly deploy malicious exit relays. Your feedback is welcome! You can read and comment on it here: https://gitlab.torproject.org/tpo/community/policies/-/issues/32. Alternatively, you can read the full text below. Gus ``` Filename: 102-tor-exit-lifecycle.md Title: Tor Exit lifecycle Author: Gus - gus at torproject.org, GeKo - gk at torproject.org, Hiro - hiro at torproject.org Created: 2025-10-14 Status: Draft ``` ## Overview Tor exit relays are maintained by volunteers and used to leave the Tor network and access websites and other online services. This proposal introduces a lifecycle for Tor exit relays, inspired by the lifecycle already used for non-exit relays to acquire particular flags, such as the Guard[1] and HSDir[2] flags. The main goal of this proposal is to make it harder for attackers to quickly deploy malicious exit relays and exploit Tor users. The proposed lifecycle adds a staging phase for new relays configured as exit relays. This is a period during which those relays are only functioning as non-exit relays. Afterwards, they become eligible for the Exit flag and can then be used as exit relays as intended. This exit relay lifecycle should raise the operational costs for malicious actors, enable earlier detection of bad relays[3], and provide more protection against Sybil attacks. ## Motivation Currently, because Tor is an open and public network, any relay operator can set up a new exit relay and, after a brief warm-up period, begin handling real user traffic. Malicious actors have exploited this openness to launch man-in-the-middle (MITM)[4][5] attacks, leading to a continuous "whack-a-mole" situation for the Network Health Team and the Directory Authorities: while attackers can often be blocked before causing major harm, significant human resources are required to keep up with them. As a small non-profit, it is essential for the Tor Project to focus its limited resources on mission-critical tasks. By implementing mitigations that force adversaries to invest more time and effort or make their attacks faster and easier to detect, we create a more favorable scenario for the Tor Project and its users. To help with that, a staged lifecycle for exit relays will: - Slow down the deployment speed of malicious exit relays as they will need to go through a staging phase. - Give time for analysis and automatic or proactive scanning before an exit relay sees and can exploit any outgoing user traffic. ## Proposal New relays configured as exit relays must complete a staging phase of 4 days (configurable) before becoming eligible for the Exit flag. The staging phase should be long enough to deter opportunistic abuse, but short enough not to discourage legitimate relay operators. ### Security implications The proposed change does not harm user anonymity or security. By reducing the number of new, untrusted exit relays on the Tor network, it improves safety for Tor users and disincentivizes short-lived "throwaway" malicious exit relays. ## Implementation considerations The exit relay lifecycle could be implemented with the help of Tor configuration options or consensus parameters, so that Directory Authorities can tune the staging length without a tor release, or disable the feature temporarily in unusual capacity situations. The exact code and format details will be specified in a follow-up torspec proposal (and then implemented in tor/arti). Note that the technical implementation may have slight changes to this proposal. ### Participation and Communication Once the exit lifecycle is implemented in a torspec proposal, a communication strategy will take place to inform and support relay operators. This strategy may include, but is not limited to, the following actions: - Update the [Tor Relay Operator documentation](https://community.torproject.org/relay) to include an explanation of the new exit relay lifecycle. - Display a banner on Tor Metrics Relay Search for new exit relays, directing users to the exit lifecycle proposal or relevant documentation. - Inform the relay operator community on their communication channels such as the tor-relays mailing list, blog post, and the Tor Forum. - Document new behavior resulted of the exit lifecycle, for example, if an exit relay drops of the consensus for a period, they will lose their exit flag and will need to restart the lifecycle described on this document. For the implementation discussion, see: https://gitlab.torproject.org/tpo/network-health/team/-/issues/220. ## Notes [1] Tor Guard specification: https://spec.torproject.org/guard-spec/index.html \ [2] HSDIR https://spec.torproject.org/tor-spec/subprotocol-versioning.html?highlight=… \ [3] Criteria for bad relays: https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-… \ [4] Also known as a monster-in-the-middle, machine-in-the-middle, meddler-in-the-middle, manipulator-in-the-middle, person-in-the-middle (PITM), or adversary-in-the-middle (AITM) attack. \ [5] https://blog.torproject.org/bad-exit-relays-may-june-2020/ -- The Tor Project Community Team Lead

1 0

Bug: conflux_util.h:24
by abir 13 Oct '25

13 Oct '25

Oct 12 21:24:47.000 [warn] tor_bug_occurred_: Bug: conflux_util.h:24: CIRCUIT_IS_CONFLUX: Non-fatal assertion circ->purpose == CIRCUIT_PURPOSE_CONFLUX_UNLINKED failed. (on Tor 0.4.9.3-alpha 1ee22f8f9a98719d) Oct 12 21:24:47.000 [warn] Bug: Tor 0.4.9.3-alpha (git-1ee22f8f9a98719d): Non-fatal assertion circ->purpose == CIRCUIT_PURPOSE_CONFLUX_UNLINKED failed in CIRCUIT_IS_CONFLUX at conflux_util.h:24. (Stack trace not available) (on Tor 0.4.9.3-alpha 1ee22f8f9a98719d)

2 1

shutting down a relay with less interruption for maintenance
by Marco Moock 13 Oct '25

13 Oct '25

Hello! I would like to ask what the preferred way is to shut down a relay gracefully in case of maintenance downtime to avoid interrupted connections. The shutdown process might take a while. -- Gruß Marco Send unsolicited bulk mail to 1760260473muell(a)stinkedores.dorfdsl.de

2 1

Relay not ramping up as expected
by tor＠busybear.se 12 Oct '25

12 Oct '25

Hello. My exit 7BE9E2EF2BB41BB662D9A3CD68289B9E3DBF8A08 WYSWYG has kinda frozen at the current status, although formerly being both guard, stable and advertising towards 60 MB output on a 1Gb fibre. My provider, Bahnhof, has no problem with Tor, even though my exit been investigated by the police as involved in the biggest leak in Sweden without consequences for me. Uptime should be enough by now for at least a stable flag. Speedtest on my IP says upwards 950 Mb up\down. My torrc is simple: ORPort 65532 DirPort 65533 #ClientPreferIPv6ORPort Nickname WYSWYG Contactinfo <tor AT busybear DOT se> ExitRelay 1 Log notice file /home/*/torlog SafeLogging 1 ProtocolWarnings 1 RunAsDaemon 1 ControlPort 9051 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /home/*/control_auth_cookie #GeoIPFile /home/*/TorBrowser/Data/Tor/geoip IPv6Exit 0 ConnDirectionStatistics 1 ExtraInfoStatistics 1 Any suggestions? Logs provided on request. \Bamse

1 0