- tor-relays - lists.torproject.org

Regarding DNS reliability testing for relay operators
by relayadmin 02 Dec '25

02 Dec '25

Hey all, I've spent a good part of the fall learning about Tor, and I'm excited to start contributing as a relay operator. DNS seems to be a significant point of confusion. I posted about this a few weeks back (https://forum.torproject.org/t/best-practices-for-dns-local-vs-external-res…) and got a helpful response from NTH, but there still seems to be uncertainty around DNS performance. That inspired me to run some tests that might help current and future operators set up more reliable and private DNS. My plan is to run three separate hosts with identical OS/resources and torrc configs, but with different DNS setups based on the three most commonly recommended configurations: - Node 1: Runs a local Unbound server using itself as the resolver - only contacting recursive resolvers from the node. - Node 2: Runs an Unbound server on an external IP used by the relay as an upstream resolver, ensuring queries aren't made over a Tor IP. - Node 3: Uses the ISP's local DNS configuration (no changes from the “out-of-the-box” setup). Is there another configuration worth testing that I haven't listed here? Have anyone here conducting similar testing? Feel free to email me directly. I still need to get more comfortable with Prometheus and Tor metrics before I feel ready to run the nodes, so in the meantime I'd really appreciate hearing your thoughts on this kind of contribution. Happy December 1st everyone. Riley

2 1

Re: Bridge Operation IPv6 only - possible?
by ProSecureRelays 01 Dec '25

01 Dec '25

Hi there, the Bridge is working right now as expected - i was confused to see the boostrapping not in the CMD but finally found it in the Notice file. Beginners fault, I was literally working the whole time. For testing I added IPv4 Support, but I will remove it now, because I'm afraid people getting busted as tor user, when Relay and Bridge-Obfs-Interface share their addresses - and I think for good reason. The simple torrc option "IPv6Only" should do the trick. Is there any additional site to look up the bridge aroi state? From what I saw was 1aeo only tracks the relay stats (huge thanks for this!) Best regards Joker Von: Jan Scherer via tor-relays [mailto:tor-relays@lists.torproject.org] Gesendet: Sonntag, 23. November 2025 20:35 An: tor-relays(a)lists.torproject.org Betreff: [tor-relays] Bridge Operation IPv6 only - possible? Hi there, I have two questions regarding bridge operations: Is it possible to run an obfs4 Bridge with external-reachable IPv6 only? I've tried to setup a "Node" on a seperate host, but in the same network as my relay. (VLAN-seperated) The idea was to open all external ports required for the tor part (on IPv4 and IPv6) and assign one different IPv6-Address as External obfs Port. I generally thought this could be beneficial, as with every firewall restart I get new IPs and potentially evade blocklists. From what I read there is a higher demand of bridges at the moment due to russian and chinese "ip whitelisting" attempts. Overall, the Networking Scheme would look like this (from Firewall-View) -------- WAN Source Target IP-Ver Port Desc. WAN Tor-Relay IPv4/6 30003 Allow Incoming Relay-Traffic WAN Tor-Bridge IPv4/6 30004 Allow Incoming Bridge-OR Traffic WAN Tor-Bridge IPv6 56120 Allow Incoming Bridge-Obfs4 Traffic -------- DMZ Source Target IP-Ver Port Desc. Tor-Relay "WAN" IPv4/6 * Allow Outgoing Relay-Traffic Tor-Bridge "WAN" IPv4/6 * Allow Outgoing Tor/Bridge Traffic -------- The Bridge is starting but freezes in a state before any major bootstrapping happened. (see Logs attached) I can see outbound and inbound traffic on the tor ports (30004), but not on the bridge ports. I assume the Tor part is "partially" working. In the Log: Is the last line [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:50652 - is that an internal Port or the port that I want to be 56120? Maybe someone could give me hint if this frankenstein construct is even supposed to work (like having a bridge with only public IPv6 Adress) and If there are any security constraints. Second Question: Should I exclude my own relay as Guard? Other thoughts: To improve privacy for the bridge even more, i thought about adding a second Interface to the VM, and work with IPv6 ULA and NAT for the needed Tor Connection. E.g. Pick any GUA from the External Availabe IP-Range and NAT it to ULA "fc55:c737:c747:c757::cafe" and do also Outbound NAT to the GUA again to not confuse the peers. But this is for another time. Last point, maybe it makes you smile about my stupidness.. I took alot of thought into physical security of my server, last Step was to trigger a Bitlocker-Lock, when the Chassis is opened. Unfortunetaly, the Chassis_Intrusion Implemetation of the Board is not great, so I ended up with connecting the Chassis Switch onto the CLR_CMOS Header. "Perfect Solution". When you open up the chassis, the system immediately resets and due to PCR Missmatch, the drive cannot be decrypted. I have removed any "Recovery Options" from bitlocker, so no 40 Digit Number you may enter in this case. If not planned, during a normal boot the TPM + Key-File + Pin would be needed to unseal the drive. I'm using TSME as additional layer of protection, so all of my ram is enrypted and cold boot attacks are not an option anymore. The measured performance impact was only about 6% in my case. It can be enabled in the Bios. To prevent DMA Attacks, I disabled USB-Support, Audio, SATA and there is even no free PCIe Slot or any other interface on the Board. Reason for all of this is that I may want to spread some more relays, and I cannot guard them or ensure that they are 100% safe from physical tampering, so I want them to just go down immediately when someone messes with them. If you have any more thoughts/improvements, let me know. After this long mail, I'm pretty sure you will all sleep well! Best regards and a nice start into the week! Joker

2 1

Getting IP reputation services to use ExoneraTor?
by forest-relay-contact＠cryptolab.net 30 Nov '25

30 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. A discussion with a hosting provider led to them making a suggestion after I showed them https://metrics.torproject.org/exonerator.html, so I thought I'd explain his suggestion and post it here. Nowadays, a huge number of hosts are familiar with Tor and sympathize, but do not allow exits because it severely taints their IPs and makes them difficult to resell afterwards. With the rising costs of IPv4, it is a deal-breaker even if the host would otherwise be fine with exits. Obviously, convincing IP reputation services and blacklists to make an exception for Tor is impossible: It goes against their mission. But has anyone tried advocating to these reputation services that they remove exit IPs from blacklists once they are no longer exiting traffic? This would reduce the number of false positives in their database without increasing that of false negatives (which is all they care about). I imagine hosts would be much more amenable to hosting exits if the subsequently blacklisted IPs revert to being clean as soon as the exit operator leaves. After all, "if I'm your customer, the IP ranges I use will be tainted for a long time and potentially unsellable even after I leave" is not going to inspire as much confidence as "if I'm your customer, the IP ranges will only be dirty while I use them". Is there anything to this? Large exit operators can just register their own ASN and simply not care about blacklists, but most operators are not going to be able to do this, especially if they run just a couple relays anonymously and on a tight budget. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkrjRgACgkQBh18rEKN 1gvHJQ/9FJBMMFJ86hCR1OE4n9ONwAsP7CxB4MBO58mUz+bN40Ngzv/N+Ih0BaQf 8qYEcHeEaYp7IB+/OFJS3hTOZDZYCdXU7nocxZgZ5l4k4e68JnyyNSio/zMu5tHk GUeQd10wZXxQnzBgdfDlj2tyCMUkWlzcvgxTaqk7scHuEk1kwfyixvcfbgMQL7T8 nWqik8BTzKYuS6zimks4MQsl8viE2dpOaWkz4xtm4EPUlQv1kh2N3c7JO0vFyC3s Q1ad/4VmlZQ3lgOO++0B3CSJ/6Fh2hYGYJm8B2Fe1nSdZ/SY1+mLYr0KupM53tEL FKsnXliqyIMVExBW5MlxoGlK4AQ3AkbrafkpUSPvNsvjmu94GHrg2Y1jcefSelFO zd34lfRmDaNE1yoxL1ehxYIEJGbwkMnxU4+FC5tnHxcWM8gtE499kFu4+5JCFiBu i2ldLycdIEaez2mb8VbXHXdwjAQy8dVlFaHVua26riirVoKmTgKEJ+wnVkCbAF8W 8ZUQVVRQIwJyo2dlcNGrwGwZ5BtzXFtYiJfmqE4yesc7MESQsqb02kWlPVEVTCyq UMDzVa+W08xhTr+c9iaFIC8scmZCoI0zOpFiqBUofIR9NWKszccXrJbOdF3vDkNJ ZGquAzEnrwwhB9Zj3QLoz05AUzlmLtWd0u30gqZ8zMMx5KSs9iY= =IVGe -----END PGP SIGNATURE-----

1 0

Exact criteria for receiving a BadExit flag
by forest-relay-contact＠cryptolab.net 27 Nov '25

27 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I contacted an exit operator who had BadExit flags on the same host that I run an exit on and we discussed possible reasons for this. Eventually, we jointly set up a new relay on that host and I configured it exactly as I had configured my own relay, and it still obtained the BadExit flag. So far, these are the exact steps I took to configure it: - Unbound is configured to use a second, clean IPv4 - sysctls are tweaked to ensure conntrack does not drop connections - torrc is configured with safe, sensible exit defaults And it still obtained a BadExit flag. We had discussed whether there was a possibility that his family was "tainted" and somehow the BadExit flag was being applied to new exits on his relay family, but starting up a new relay unrelated to his did not help. We tried disabling Unbound and instead using a popular upstream DNS resolver, but that did not prevent a BadExit from being issued either. What other troubleshooting steps are suggested? The provider does not censor or block anything, and I have been successfully running an exit on their infrastructure for more than a month, but when he sets one up, even if he configures it identically to the way I configure mine, it receives a BadExit flag within a matter of days. The criteria for issuing the BadExit flag do not seem very clear. Since it is not a flag intended to be issued to malicious exits, I would like to understand the exact criteria for being issued a BadExit, beyond the vague explanations that I can find on the Gitlab. Note that I am only asking about the automated flag, not about the (potentially sensitive) policies behind determining whether or not a relay is malicious and should be manually excluded from the consensus. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkmGG8ACgkQBh18rEKN 1guZhxAAxUFcZm1SuoCO5OOST915LtPPmZ6mizq+NUfS3tPoJj6zKRd/grZJYIRj TZzw7JqK62ajtMJLQcLLKuMNMHYZmzr0DP8jVo/JAoh/rcGIqXL+jWIupDDxIQG7 Mf25OF6OrhNb23HTwrudJIiM/PFH6Yyoj0hlDBxpSu3IcopP9xxPwPKYXQjgaZEx mJPpbTb86vrs1TmBQ7C7W6pBoq6zOtne2NfqC6SJ1UNpk/dYxQnknuFYLDeaSPdz qNkh/h2Ua0a0ASGswxTRatd2epkDKrJHoVJ5t/WBPnzPOUJdo6D26oLr1bKzSTM1 +nKkd5ws5b2d8Fi+FQk7LbgiLBSdGAIFL3bBL3FD5ERE+1LkOTaOs9wR0dlIFNRV 4draROjsgfYIw0LavO+O8EEbS5R5xyf5RNIueNMpqbV/IGhoYLYUUfdqITB1swHr jFaEUoNIFAvBS1qp+9ApjmQJ/J2CiPZJ7Su73v6vA9Qq6Amv3ruMK+w5sqO1BpFB V9L/pr/ZB3619SyqMVN2e+M58xDumwwMTHK1AVIGHZLlff5VYR4rBtqXR1T0qPKl AdliLh39C+oBFD0q+12tbucjjJjg8LiiZfo7KReZDpN78zJWxtR+Z57/XfXYDqJd 9FDJdYAm4qLa9wEzAUslEdrfGnokYJQQcI07eNqPFgnl4B80V4I= =N2Ia -----END PGP SIGNATURE-----

2 2

Could you post an i386 build for Trixie?
by Dawn Flood 27 Nov '25

27 Nov '25

Good Day, I am going to upgrade eventually to Debian Trixie 64-bit, but it would be so very wonderful if a i386 build with the most recent stable changes could be posted here with the appropriate updates to the 'Release' file (to include the i386 architecture): https://deb.torproject.org/torproject.org/dists/trixie/ Thanks so very much!! Dawn

3 5

OrNetStart AROI
by Michele Branchini 27 Nov '25

27 Nov '25

Hi there ! i was able to verify 19 out of 20 relays i operate on the OrNetStats website. sadly, the 20th has not passed the verification because i wrongly copy-pasted (tbh, that requestes some talent...) the fingerprint of that relay in the DNS. Now it is fixed, i have waited 24h, but still i can see the relay not verifying correctly... https://nusenu.github.io/OrNetStats/w/family/67ea5c7dbbbdc7c79990999b903c90… <-- family https://nusenu.github.io/OrNetStats/w/relay/91D66445EBE11BB058E9ED1ED92C7FE… <-- the relay itself I have also checked the relay family with https://aroivalidator.1aeo.com and there's all 20 seems verified correctly. ----------------------- "nickname": "TheShadowRoute19", "fingerprint": "91D66445EBE11BB058E9ED1ED92C7FED325F62E4", "valid": true, "proof_type": "dns-rsa", "domain": "antr.ax", "validation_steps": [ { "step": "DNS TXT lookup", "success": true, "details": "Found valid proof at 91d66445ebe11bb058e9ed1ed92c7fed325f62e4.antr.ax" } ], "error": null ----------------------- OrNetStats runs at which frequency ? Thanks, M.

2 1

Intentionally obtaining a MiddleOnly flag
by forest-relay-contact＠cryptolab.net 24 Nov '25

24 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Is it possible to run a relay that is not an exit *or* guard? I found a host with an AUP that states that Tor exit, entry, and bridge relays are prohibited. After messaging their customer support, they mention that middle relays are fine as their only concern is to avoid bringing in customers who harm the IP reputation of their services. Of course, their AUP is a little silly and likely stems from a misconception of the Tor network, especially if they allow middles but not guards. I did ask them if they could change the AUP to be more in-line with their intentions. Although I doubt any harm would come from it if I did run just a regular non-exit, it might be a good idea for me to avoid it becoming a guard, just in case they end up prioritize an over-literal interpretation of the letter of their AUP. Is there a way to do this, without intentionally interfering with the relay's stability or performance? Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkjYDIACgkQBh18rEKN 1gtD1w//ZUIYZmpqsuBF1sK56iMomZFBbqaf5L9ZRf+az034SVlVPvxtTGK95P87 wlkTF+VJzmkARPoH3tjsmBTl3VLtjnawUHstB7yrJ0QDfl7v9l2bEWZ5kMM1/aiB zDGrzoX8xN4Rq6VLFOkot0dB2nIy4MoQUkV0WYvKeHy+A0eQBgaObXXXEw86oNeX Vb2nO1fkEKLJZZgYyUsaIw7+duI1VWCAvHMz/sNk7sMXk5lNAFStrYYGdjlnqtZh wwQ0xFrRQhwlc9LS4FWjQRvSYMHxL8kFvzqKs98l/gGx1AZTXszW8BFf+rYWWTDY aICpMuqF72vtZZuLoaiCYuPro+SRcRbaC+zyt6GqkAbTzqok5wrr3D/gIJAV7vnH xpghje2y7+6JdssckMwtWanfQvE7yo3eVHrbxgwlrwL46UfdRphHiH5T1kaNE+hu Xxl9SSZj61iyk/k7P2rgihTFdhRFxgRPzviDrhd8neaE7dKp33mmWPr1mgM6vrK8 tb2a3Z6tWoPhxZcRAe6hFJDpqmZjOFO6JeTr6FngkG7R2ZlfGz/auB80dY7KETW4 cYEBwgbZ5qukDFfA3LwnLhKDNmQXpgHZET+vY40Cyl8uKtFt4hnlhllbvnP4NwVQ IYLYlKrRttEAempYGbvwTfyH7vqDCK6sin1i+IiXCuY/cP+r1II= =c7AV -----END PGP SIGNATURE-----

1 1

Sybil Attack on 2025-11-20 - please setup your AROIs :)
by nusenu 24 Nov '25

24 Nov '25

Hi, as some of you might have noticed, yesterday 2025-11-20 someone added ~900 new tor relays to the tor network. They used nickname schemes from other operators: * NTH * prsv * Quetzalcoatl * for-privacy.net * relayon * DFRI * bauruine ... For this reason I wanted to encourage every operator, especially the large once to setup their AROI. Here is a howto: https://nusenu.github.io/OrNetStats/aroi-setup Why? You get nice timeseries graphs of your relays. example: https://nusenu.github.io/OrNetStats/artikel10.org.html And it helps to **automatically** tell false-friends apart especially since families have become so large that we can no longer use that as a good signal because family must be splitted if they become too large for the descriptor limit. A good example is nothingtohide.nl, all of their relays have a proper AROI configuration and they verify properly: https://nusenu.github.io/OrNetStats/w/contact/aa738469b86e5ea8838d95eb2b8e6… Here are 3 examples of large relay operators where AROI verification fails (partially): If you are one of them or if you know them please ping them if you can: * quetzalcoatl-relays.org https://nusenu.github.io/OrNetStats/w/contact/b32573fcfbc780a4b9ef03425f676… * emeraldonion https://nusenu.github.io/OrNetStats/w/family/34933fa4f34ef248c8484749587002… * prsv.ch https://nusenu.github.io/OrNetStats/w/contact/65a4a24bfc53c4c6c0d312ce29ab7… kind regards, nusenu -- https://nusenu.github.io

7 8

Bridge Operation IPv6 only - possible?
by Jan Scherer 24 Nov '25

24 Nov '25

Hi there, I have two questions regarding bridge operations: Is it possible to run an obfs4 Bridge with external-reachable IPv6 only? I've tried to setup a "Node" on a seperate host, but in the same network as my relay. (VLAN-seperated) The idea was to open all external ports required for the tor part (on IPv4 and IPv6) and assign one different IPv6-Address as External obfs Port. I generally thought this could be beneficial, as with every firewall restart I get new IPs and potentially evade blocklists. From what I read there is a higher demand of bridges at the moment due to russian and chinese "ip whitelisting" attempts. Overall, the Networking Scheme would look like this (from Firewall-View) -------- WAN Source Target IP-Ver Port Desc. WAN Tor-Relay IPv4/6 30003 Allow Incoming Relay-Traffic WAN Tor-Bridge IPv4/6 30004 Allow Incoming Bridge-OR Traffic WAN Tor-Bridge IPv6 56120 Allow Incoming Bridge-Obfs4 Traffic -------- DMZ Source Target IP-Ver Port Desc. Tor-Relay "WAN" IPv4/6 * Allow Outgoing Relay-Traffic Tor-Bridge "WAN" IPv4/6 * Allow Outgoing Tor/Bridge Traffic -------- The Bridge is starting but freezes in a state before any major bootstrapping happened. (see Logs attached) I can see outbound and inbound traffic on the tor ports (30004), but not on the bridge ports. I assume the Tor part is "partially" working. In the Log: Is the last line [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:50652 - is that an internal Port or the port that I want to be 56120? Maybe someone could give me hint if this frankenstein construct is even supposed to work (like having a bridge with only public IPv6 Adress) and If there are any security constraints. Second Question: Should I exclude my own relay as Guard? Other thoughts: To improve privacy for the bridge even more, i thought about adding a second Interface to the VM, and work with IPv6 ULA and NAT for the needed Tor Connection. E.g. Pick any GUA from the External Availabe IP-Range and NAT it to ULA "fc55:c737:c747:c757::cafe" and do also Outbound NAT to the GUA again to not confuse the peers. But this is for another time. Last point, maybe it makes you smile about my stupidness.. I took alot of thought into physical security of my server, last Step was to trigger a Bitlocker-Lock, when the Chassis is opened. Unfortunetaly, the Chassis_Intrusion Implemetation of the Board is not great, so I ended up with connecting the Chassis Switch onto the CLR_CMOS Header. "Perfect Solution". When you open up the chassis, the system immediately resets and due to PCR Missmatch, the drive cannot be decrypted. I have removed any "Recovery Options" from bitlocker, so no 40 Digit Number you may enter in this case. If not planned, during a normal boot the TPM + Key-File + Pin would be needed to unseal the drive. I'm using TSME as additional layer of protection, so all of my ram is enrypted and cold boot attacks are not an option anymore. The measured performance impact was only about 6% in my case. It can be enabled in the Bios. To prevent DMA Attacks, I disabled USB-Support, Audio, SATA and there is even no free PCIe Slot or any other interface on the Board. Reason for all of this is that I may want to spread some more relays, and I cannot guard them or ensure that they are 100% safe from physical tampering, so I want them to just go down immediately when someone messes with them. If you have any more thoughts/improvements, let me know. After this long mail, I'm pretty sure you will all sleep well! Best regards and a nice start into the week! Joker

1 0

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

24 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 22 Nov '25

22 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 20 Nov '25

20 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 18 Nov '25

18 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

Being banned?
by Brian Henderson 26 Oct '25

26 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 26 Oct '25

26 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 26 Oct '25

26 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