- tor-relays - lists.torproject.org

Re: name resolution with libc
by Marco Moock 18 Jan '26

18 Jan '26

Am 18.01.2026 um 14:19:28 Uhr schrieb D.O. Bronk: > One of my exits is on FreeBSD too, I didn't know this yet, so good to > know. But normally a 'reload' instead of a 'restart' will suffice. > This way your tor relay doesn't lose it's uptime etcetera. > > If I'm not mistaken, this should also be done after sysctl fine > tuning. Is that anywhere documented? -- Gruß Marco Send unsolicited bulk mail to 1768742368muell(a)cartoonies.org

1 0

name resolution with libc
by Marco Moock 18 Jan '26

18 Jan '26

Hello! I operate an exit relay on FreeBSD. I changed the values in resolv.conf (that file lists the actual nameservers, not a local resolver), but tor DNS traffic was still sent to the old servers for days until I restarted tor. How is that handled in tor? -- Gruß Marco Send unsolicited bulk mail to 1768731494muell(a)stinkedores.dorfdsl.de

1 0

Tor guard relay memory: what actually reduces RSS on Ubuntu 24.04
by Tor at 1AEO 17 Jan '26

17 Jan '26

Hello, We ran experiments over 10 days on ~100 Tor guard relays (Tor 0.4.8.x) on Ubuntu 24.04 to determine which memory optimizations materially affect long-term, steady-state RSS under sustained load. Results: allocator choice dominates steady-state RSS outcomes. Using mimalloc 2.x and jemalloc 5.x produced large, sustained reductions in resident memory, on the order of 70–80 percent, compared to the default glibc malloc; tcmalloc showed a smaller but measurable improvement. By contrast, the two commonly cited configuration parameters, MaxMemInQueues and MaxConsensusAgeForDiffs, showed little to no impact on steady-state RSS when adjusted in isolation. Operationally, these reductions allow higher relay density per host, with guard relay memory footprints decreasing from roughly 5–6 GB to approximately 1–2 GB per relay under sustained load. Attached are the summary chart and table. Full methodology, comparisons, and data are here, with links to scripts on GitHub to reproduce: https://www.1aeo.com/blog/tor-memory-optizations-what-actually-works.html Tor at 1AEO Approach Result Viable? mimalloc 2.1.2 1.16 GB (80% reduction) Yes jemalloc 5.3.0 1.59 GB (72% reduction) Yes tcmalloc 2.15 3.79 GB (33% reduction) Partial mimalloc 3.0.1 4.39 GB (23% reduction) Partial DirCache 0 0.29 GB (94% reduction) No (loses Guard) MaxMemInQueues ~5.0 GB (no change) No MaxConsensusAgeForDiffs ~5.7 GB (no change) No Periodic restarts 5.0–5.3 GB (minimal) Workaround only glibc 2.39 (control) 5.68 GB Baseline

3 5

forest08 dropped out of the consensus; all authorities think it is down
by forest-relay-contact＠cryptolab.net 16 Jan '26

16 Jan '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. My relay with fingerprint BDB0F71C8EB2572080D38F036E3EB33494500E9E is no longer being recognized by the consensus. I can confirm that the entire subnet it is on is able to reach the directory authority's ORPorts, but, according to the consensus health page, not a single DA reports it as running. This has lasted for 11 hours so far. How do I get it back in the consensus? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaWjfzAAKCRAw+TRLM+X4 xsIVAP9E6Ijjzt1yt7AtFTUy6TSoTnVjGMgP2A09bZr0TWNseQD/SqWS27zFl2zq wdEZyZfQHArlgB4YHyS7j06gij2GzAo= =XdXh -----END PGP SIGNATURE-----

2 2

Tor exit relay lifecycle - update
by Georg Koppen 14 Jan '26

14 Jan '26

Hello! We have been working on a proposal to introduce an exit relay lifecycle (similar to the one we have for non-exit relays)[1]. That proposal got recently accepted and merged[2] and now we need to get it implemented. Folks interested can follow the implementation part by tracking the respective ticket in core/tor[3]. For more context see the discussion in the original exit lifecycle ticket[4] as well. Thanks, Georg [1] https://gitlab.torproject.org/tpo/community/policies/-/issues/32 [2] https://gitlab.torproject.org/tpo/community/policies/-/blob/main/docs/relay… [3] https://gitlab.torproject.org/tpo/core/tor/-/issues/41196 [4] https://gitlab.torproject.org/tpo/network-health/team/-/issues/220

1 0

Turkmenistan Censorship
by Dan 13 Jan '26

13 Jan '26

Hello, I have been emailing with a user of my bridge who is located in Turkmenistan. They contacted me to say that their ISP has blocked my bridge(s) and to request I rotate either the domain name, IP address, or both. Has anyone else found a solution seems to work in this scenario? I'm happy to request a new public IP from my VPS provider but I'd like to avoid purchasing new domain names every few months. Maybe the best option is to buy a cheap domain and setup a "private" bridge that isn't distributed except manually? This bridge is using Webtunnel which the user says is usually harder for their ISP to detect. Should I switch to Lyrebird? Thanks

4 7

upcoming CIISS update
by nusenu 09 Jan '26

09 Jan '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

2 3

Tor Relay Operator Meetup at 39c3
by Alexander Hansen Færøy 06 Jan '26

06 Jan '26

Hello folks, Leibi has managed to get a spot for a Tor Relay Operator Meetup here at #39c3. Folks can join us on day 3 at 00:00. For more information, check out: https://events.ccc.de/congress/2025/hub/en/event/detail/tor-relay-operators… Cheers, Alex -- Alexander Hansen Færøy

2 2

Relay forest18 is still not on the consensus
by forest-relay-contact＠cryptolab.net 06 Jan '26

06 Jan '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. One of my new relays is simply not showing up on the consensus. It's been a few days already. I ended up wiping /var/lib/tor and restarting in order to get a new fingerprint, but it has been a while and it is still not showing up on the consensus. I have 21 relays, and this one, the 18th, is the only one having this problem. Even the 21st has shown up on the consensus already. The new fingerprint is 6435C5172690160DA25681BEBA1EA5EAC6F2BE70. Is it possible that it has been incorrectly blacklisted due to being mistaken for one of the relays involved in the recent sybil attack? The IP address is 160.250.225.3. What confuses me is that, even after changing fingerprints, it still is not showing up. It is connected to the network and is reachable from the outside. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmk1NxEACgkQBh18rEKN 1gtojw/9Hoix29gE4oevhlRJvGLftgbJHv5caZ7iGNZ7KdN7R/8HQ//0InfyG5d4 8Mb49D2jzNfLK+89svlMyNso5ZqR3sMcy7dpnTNAq+PlxB84AwQE/9Qb/8R3sTDZ A2S8ezzCtViQTEQh9eYx+zmnjJckwVt4sAbjumc6t3kIdN+f7CjOj2SZ+AbT6e4l hBZdaGwKLUQhPzL35SK20RSTjIvVNDHAwMo5rR6BsHCj/+W+3fmAG29pieqCAGp/ lwXR6E4EMII0f53Pb65ZB38FOTuMkBBFL0I3WUB90IqS4z+L3U9oU2u7KY1np1lp ApCSbQjoY+NSgpdJ0yH5b1ZZEvEnr1OhQqY0RMpVTLXOuByj79NG31mjE1v8aUaN a5Lwk6scYXuPr8ryOkxkX80tN5V21pIQWt9hubpXBHtPLvfGmTS51DwwOOEKYoIA yyFnVST75f38uyvm73H48s9c68263I5fKQvFCzUmq8Go0lpbLutjxC8LNML3J0cq 0rIINHWKDw4UjnboKihkuoRdXi+tH2ERW3ZAoKVUXTi1VHomwfDvBHJSYxb3SipI 54Qjrnd6IFr8LaHcTfFacrD/OH4WAYnGCE3lC4Ly3xX0P8Cb9KDkop8nXPuBJAup Jq7GgDP8vsmWW6hp4q/Sh+ajHkeZm/luNWA3DZqsp4q0grHi/IM= =Zdqz -----END PGP SIGNATURE-----

7 28

Hetzner Netscan False Positives
by tor_appliedprivacy.net 04 Jan '26

04 Jan '26

Hi, we just wanted to let you know that we got a Hetzner network contact yesterday here at 39C3 to try to get this issue solved at the root. We can not promise anything at this point but we will likely update this thread in a few weeks (January) about the status with Hetzner on this topic. best regards, tor(a)appliedprivacy.net

6 7