September 2013 - tor-relays - lists.torproject.org

Re: [tor-relays] Getting max bandwidth out of a relay
by Jesse Victors 12 Sep '13

12 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > As I am trying to avoid using too many IPs (IPv4 is constrainted, IPv6 > is not, but the latter won't get much traffic), I'll try if I can get my > tcp-balancer idea setup in the run of next week (low on spare cycles at > the moment) and then forcing each Tor instance to use a specific core. Right, you can only get two Tor instances per IP, at least on IPv4. The third won't get any significant bandwidth. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSMcSWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA0psH/35+GsdqKtZxG1bC9pjaFeGr mySy8AQ4DTj/FPhQhCtSwlh35ZFrTnagTuK49XChLcepMV830qFon56A29aL3QI/ 9Je5PX5sILxNlMN4ubR5578PfZLTtkWm2j7l58VALFFTkozMVMbkmVsQp63+3AQN MLt6VKb7p1Oob/PGaZsk+9c9gqxDl4LnT6awzcn1caRyUcchsP98BUURtNNdiIqg 7Yb03t3toVDZnkESyqo5n10dxG5OE7EN+ldrJ5jYrZoWmcHlHG6Ln/5pdLL6u/93 4yAxO6DYijzBIXbzzG2TU1Z1t+8s5WGa5ov0s6EdssxqszfK23KgZmBWIESnP9A= =ctNz -----END PGP SIGNATURE-----

1 0

Getting max bandwidth out of a relay
by Jeroen Massar 12 Sep '13

12 Sep '13

TLDR: what do people to do get the max throughput through their boxes? Hi, This might be more tor-dev related (due to the Tor internals, eg why it does not use multiple CPU cores effectively etc), but is likely a bit more appropriate here as there are people who are able to get a lot of performance out of their boxes. I've been playing a bit with setting up a few relays and letting them push as much traffic as possible following amongst others the items at: https://www.torservers.net/wiki/setup/server Thus making sure it is using AES-NI (which turned off and then on made a bit of a difference but primarily in CPU load), and doing some TCP stack and other kernel tweaks. I am running the current-git Tor on them, thus self-compiled and except for the install path no special configure options (any tips there?). The boxes are 2-cpu 6-core E5645 @ 2.40Ghz, with HT thus 24 cores visible. Tor is using about 170% CPU (thus effectively 2 cores) on average along with 3G of mem, the box has 70G of mem thus that is not a problem. A little snapshot from 'arm' from one of the boxes: Bandwidth (limit: 3.9 Gb/s, burst: 3.9 Gb/s, measured: 353.9 Kb/s) Download (45.7 Mb/sec - avg: 27.2 Mb/sec, total: 302.2 GB) Upload (52.5 Mb/sec - avg: 27.9 Mb/sec, total: 308.4 GB): Down/Up varies upto 70mbit, the box has full GE and between them can push easily a single-stream 900mbit flow (tested with iperf/wgets/scp) next to the running Tor process. Thus there seem to be some significant issue in the Tor portion of things (though tuning might affect it as there are more flows etc). There is no connection tracking on the box, as that would just slow things down See also the munged torrc below, in case there are options to be set there. What else is there to tune except for maybe running multiple Tor nodes on the same box? Which would require it to use multiple IPs right as one can only run 2 nodes on the same IP I understand. Would there maybe be a way to run multiple Tor processes with the same key/identity but with a TCP load-balancer in front of it which distributes the incoming connections to the processes? The only thing then is that only one of them should report their details to the authorities and the others should not publish; would that be possible or would it mess up for instance performance stats? Greets, Jeroen -- torrc used: ----- NickName <nick> ContactInfo <contact> MyFamily $<othernode> ControlPort 9051 HashedControlPassword 16:<pass> CookieAuthentication 1 DirPort <ip>:<port> DirPortFrontPage /usr/local/tor/etc/tor/tordirport.html ORPort <ip>:<port> RelayBandwidthRate 600 MB RelayBandwidthBurst 606 MB SocksListenAddress 127.0.0.1 SocksPort 1080 ExitPolicy reject *:* #Log debug file /usr/local/tor/var/log/tor/debug.log Log notice file /usr/local/tor/var/log/tor/notices.log DataDirectory /usr/local/tor/var/lib/tor RunAsDaemon 1 DisableDebuggerAttachment 0 CellStatistics 1 DirReqStatistics 1 EntryStatistics 1 ExitPortStatistics 1 ExtraInfoStatistics 1 ----- /etc/sysctl.d/tor.conf net.ipv4.tcp_syncookies=1 net.ipv4.tcp_synack_retries=2 net.ipv4.tcp_syn_retries=2 net.core.rmem_max=33554432 net.core.wmem_max=33554432 net.ipv4.tcp_rmem=4096 87380 33554432 net.ipv4.tcp_wmem=4096 65536 33554432 net.core.netdev_max_backlog=262144 net.ipv4.tcp_no_metrics_save=1 net.ipv4.tcp_moderate_rcvbuf=1 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_max_orphans=262144 net.ipv4.tcp_max_syn_backlog=262144 net.ipv4.tcp_fin_timeout=4 vm.min_free_kbytes=65536 net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=10 net.ipv4.tcp_keepalive_probes=3 net.ipv4.ip_local_port_range=1025 65530 net.core.somaxconn=20480 net.ipv4.tcp_max_tw_buckets=2000000 net.ipv4.tcp_timestamps=0

4 5

A bit more evidence on circuit creation storms
by Dan Staples 12 Sep '13

12 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Just to add my experiences to the mix: I started running a RPi relay back in January. It ran fine for several months, until I started to get these circuit creation storms periodically. It would come at random times, maybe once a week, and would sometimes last for enough hours that it would knock down the Pi and I'd have to reboot it. While it was clearly CPU bound during the storms (90%+ shown by top), my bandwidth was also completely saturated. I was seeing 3 Mb/s traffic, as shown by ntop (great for monitoring bandwidth over time). Shutting down Tor during the storms would reduce the traffic to < 100kb/s...so clearly the circuit storms eat bandwidth too. Gordon, perhaps you had an upstream router that was preventing the traffic flood during the circuit storms? I asked Roger Dingledine about it at PETS a couple months ago, and he suggested it might be a case where there is a nearby popular hidden service that picked my relay as a guard node, and all of a sudden I get flooded by requests for the hidden service. No idea how to test the accuracy of this hypothesis. Finally, I noticed that bandwidth-related config options had no effect on the 3 Mb/s traffic flood during the circuit creation storms. I had: RelayBandwidthRate 200 KB RelayBandwidthBurst 200 KB MaxAdvertisedBandwidth 200KB ...yet, still 3 Mb/s traffic floods. Even MaxOnionsPending 250, NumCPU 1, and AvoidDiskWrites 1 made no difference in my RPi's ability to weather the storms. I eventually had to use QoS on my DD-WRT router to set limits on the traffic it would pass to the Pi. I will try your builds of 0.2.4 to see if that makes a difference. cheers, Dan > Since I originally started keeping an eye on these on my Raspberry > Pi relay (read: slow, resource-limited), I've got to wonder if the > circuit creation storms I was seeing months ago weren't normal > network phenomena but some kind of test run. > > We are talking going from 50-250 circuits to thousands of requests > per *second* out of nowhere, and then if the machine survived it, > the storm disappearing as suddenly as it came. This was happening > months ago, but less frequently and only on lower-end hardware. > Now it's happening everywhere. > > Even if the previous case *were* "normal" Tor network operation, > I'd say it's a bug, but I'm suspicious that it was whatever is > going on now in its test phase. > > tor at t-3.net: >> Also see a repeat of the odd log message with the 154.x net >> address someone else described with the huge hexidecimal string >> (40 hex chars, + sign, 40 more, on and on). > > Here as well. I believe this is the sign of an overloaded Tor > directory server. > >>> Over roughly the same time frame I received an incredibly high >>> number of spam e-mails in one e-mail account that normally >>> gets 20 or so a day on quiet days. Perhaps this is another >>> example of mal-ware in action. > > Funny, one of the dropped connections during my storm last night > was to port 993... :P > > Best, - -Gordon M. - -- http://disman.tl OpenPGP key: http://disman.tl/pgp.asc Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKInBAAoJEPZwdO29hkOpDZ4QAIjZqi9kXrcubZUg6v0nH6mP V9LT4j2Md0MqE74JcyEIgIBYKMWbun+n417LMMkb9uLu2mld6Lf/YIU9iO57JqQJ 8dM1uX0LJb51MbOj6ZTZEwMgHI8pX/ZeLj4zQscAz2C2oBwapnOpxqKTbg76CM1G DrP39iai9TpN+YfUY0FkxwdYTM46ADUvk/hbu/34CLXklOvrqWkK/Ta/nZ9zTebt HkB/KJn1P0I5L87x2VmIhIH5JKK6lszDlZg+k96PRC8oK9a1icECCGsnFJpqwVrv UyIsutezQHjT7HT4zJCNBxacHuK8VKbwayX6P/MSPpAGaobqEzSvWJmHdYRrIv2h glM5qIIzB3RmJxvHW8hCF47T8n9B6fo+J5PZly3xtwLGzCATjehnnhGTzigIw8ro WkQwMQr/3F5yQ0YS2YKh+KsQDhe2d1fYbrGtSPAG/z1RMuk2i5tmgyhAFJ8HvIfw GozzAaxcy1dCdEvQIyv/j1LCtUUpCrPVGd51grDI+GB9b5HuIEsPoQCvisshVEpu 1vLKyP7VLv+fOnvVb7MCwiWnU1Q5uw3yC3kdig9tTuAWGiMgbGoWpkGiy5MNVVQA Z2Q7uLnd7j6scTbpWgaa0Fx0HQ2euAXMwC+zS8g0PQXOEslGnnPs2Kqz5YTimtuh LWLcZ3WMZvlShurfNLse =mqNB -----END PGP SIGNATURE-----

2 1

Upgrade your relay to 0.2.4.17-rc?
by Roger Dingledine 12 Sep '13

12 Sep '13

Hi folks, I just released 0.2.4.17-rc. Hopefully there will be debs of it soon. It comes with a new feature: - Relays now process the new "NTor" circuit-level handshake requests with higher priority than the old "TAP" circuit-level handshake requests. We still process some TAP requests to not totally starve 0.2.3 clients when NTor becomes popular. A new consensus parameter "NumNTorsPerTAP" lets us tune the balance later if we need to. Implements ticket 9574. So the more relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be for 0.2.4 users, despite the huge circuit overload that the network is seeing. Please consider upgrading. If you do, though, please also keep an eye on it -- it's possible we introduced some new bugs and the network will start dissolving once more relays move to the new version. In my spare time I'm also working on a blog post to explain what's going on and what measures we're taking to keep things afloat. Aren't distributed systems fun, --Roger

13 24

Why is my fast relay so slow to gain popularity?
by Jesse Victors 11 Sep '13

11 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone, newcomer here. I'm behind very fast connection (11.5 MB/sec down, 7.5 MB/sec up) and I thought that the Tor network could benefit from my connection, especially since it's apparently been under high load recently. Per the latest blog posts, I downloaded the beta TBB and configured it as a relay under Linux. It's been up for almost two days now, yet it's still being utilized at a very, very small fraction of it's potential. In the network map, I see that my relay has an advertised speed which is again much slower than it actually can be. To my knowledge, a web server can be put under full load right away, and distributing computing projects use the most of your computer right off the bat. Why doesn't Tor run computational and/or bandwidth tests and advertise my relay at a much more actual speed? I don't see why a fast relay has to start at the very bottom of the barrel to begin with. I can see the logic in slowly ramping up connections in testing for stability and scalability, but the progress is slow because it's continually fighting against that existing average. I can set my requested average and burst bandwidth, but AFAIK I can't affect my advertised bandwidth. Why are things this way, and is there anything I can do to speed up the utilization growth? Thanks in advance for any help you can provide, Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSMJg3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAAekH/i2rHzwbGZMiL4g31d2JEkQR ZjOaDCe6aNkK/ORf5MhxW7B6L772BczjPkjuO0H1Oe41bSkglO78gCbLC+YQ1r68 0nc45dcztNDkQPhZVrkj7RconNrmfLXFozFLKY1Nr2mLy6RTg0a1yQ/WhpFa/qah cUmVnGtvIoDnDAhuCPIEu7SuGba0I4TkBph1atKAC/gQYyOSp9CpCqxy0J3Qaa3Y pcCkGC7oWW2I9g8UJOx0UKg1auiYMZ1QrwpJ6HdHhvhFSWnhWeggkvaOCDewC2pZ dQg7Odk/ISfkpdeCgd8hg2IQBh3kpI1kRVUvX0sJgbYCbizT45bwKCLf/XzMQHE= =gfnB -----END PGP SIGNATURE-----

4 4

Exit flag given to nodes with nearly-all-reject?
by Jeroen Massar 11 Sep '13

11 Sep '13

Hi, Is the 'exit' flag given to a Tor node which only allows exit to a certain prefix? If yes, what kind of effect does that have on path selection, will it only be chosen for exit'ing to that prefix and not be used as a relay? Greets, Jeroen

2 1

Tor crashes frequently on fast relay
by Random Tor Node Operator 11 Sep '13

11 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, since this botnet started flooding Tor, my Tor relay Bazinga ($196832C61F30E9D6D179393C9AED4E47FD29796B) has been experiencing some issues. Previously, it was relaying 100 Mbit/s for a few months without problem. When the botnet came along, at first the throughput dropped to about 30 Mbit/s and Tor kept spamming "Your CPU is too slow" and crashed every hour or so. I set RelayBandwidthRate to 20 Mbit/s which reduced the crash frequency. Then, 0.2.4.17-rc was released and I lifted RelayBandwidthRate back to 100 Mbit/s. At first it was running fine, but then the crashes came back. This is from yesterday and the day before: $ sudo grep -i interrupt /var/log/tor/log.1 Sep 10 08:59:40.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 10:01:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 11:04:50.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 12:49:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 13:51:01.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 15:22:18.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 16:07:27.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 18:56:03.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. $ sudo zcat /var/log/tor/log.2.gz|grep -i interrupt Sep 09 06:51:20.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 07:54:30.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 08:48:36.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 09:51:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 10:20:01.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 10:49:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:03:26.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:26:40.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:50:47.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:02:54.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:26:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:42:11.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:52:17.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:08:31.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:21:37.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:31:27.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:44:32.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:53:38.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:02:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:08:50.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:16:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:24:04.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:34:10.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:48:20.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:55:25.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 17:02:30.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 17:21:39.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 17:35:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 18:51:51.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 19:14:02.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 19:30:10.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 19:50:16.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 20:06:23.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 20:49:52.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 21:13:00.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 21:51:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 22:54:22.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. It is a VPS on a Xen hypervisor with 3x Intel(R) Xeon(R) CPU L5630 @ 2.13GHz and 2 GB RAM According to htop, tor currently uses about 105% CPU and 350 MB RAM. It was around the same CPU and RAM consumption while it was happily relaying 100 Mbit/s. At first I was suspecting the hoster to have reduced CPU resources or so, but they said they didn't change anything, including no virtualization parameters. Any help would be appreciated. - --RTNO -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMCRbAAoJEJe61A/xrcOQmfcP/Rq2XmtQk8e4orMWe1rPHnKX 6CMMmrI5TIAW/XQ+Qulr2ElEKh0M85XSagF8ZeziQVL348z3FoI36HwUMbzLnkI3 uELx8kq1xTGlLOmtSEdyD9xH2dwCxarlogexVb3uHUVEUQM99GMQd/A4bSzLPgTW 6fnwvDWNNZ4x1PKXxElejGhoHiq2oW5f5JoSijw4LUWJBI2SrXx4aWFHm4SofVti Cncaf+UVM2f4loBn9gUh5LWmbeWviDXsk9p5DeNAAaJ8BwK8dp4MyAoH731dcbpw svJ2b1R0TtmgyO6g/WLJcJX3s9u6iKq2QzQgLavynsAaazn6Rr4nRqPD02TFM7rw nyP9H6r08P/7gumOF3G4JSXe3Px6GMipdcGNl0fBjr6R67sB7ZeMwT00O53m0f5l InUbCCghG/ukcEtbly0CZfu7qOISlz9cxUFShmYWOLv3EpMboh9lyMNC3DbyAYH2 3kMfffyVLS21HgNA57l0N+aZl++jz+EIwFK8r+L9xZEOUBQKcXrfm0jXneV6j8uA J9NuXYyKHWltxU+EO2ccyN2Zco/3KA044dwSnTo1BXCHnt95DjyylLcQj5+7+KYW QIsviYsONp4FSz0aQUFOnLk5KAhZtieQ28Iav1S4Gb3QiL4pY2rR9r27dBZ/E1wg +C9uvwcJz4ei14ZR9A19 =BoPn -----END PGP SIGNATURE-----

3 6

Re: [tor-relays] Running Bind locally
by tor＠t-3.net 11 Sep '13

11 Sep '13

For linux bind named.conf: Within "options {" put: allow-query { any; }; allow-recursion { trusted; }; allow-query-cache { trusted; }; Then, add this new section somewhere after the options closing bracket: acl "trusted" { localhost; localnets; //netblocks/IPs you want, examples below: 123.23.23.23/24; 12.123.123.123; }; On Tuesday 10/09/2013 at 4:23 am, Eugen Leitl wrote: > On Tue, Sep 10, 2013 at 12:45:03AM -0700, Bry8 Star wrote: >> >> If you run your own BIND/named as Authoritative DNS-Server, for some >> domain-name that you own, and if it is also configured to function >> as a Recursive DNS-Server for local software (in that computer), and >> if you have enabled DNSSEC (for recursive side), then that would be >> better, imho. > > Speaking about recursive DNS for BIND, does anyone have > a working set of options which limit recursive DNS queries > to just the local subnet, and another couple IPs, maybe? > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 1

The lifecycle of a new Tor relay
by Roger Dingledine 11 Sep '13

11 Sep '13

Many people set up new fast relays and then wonder why their bandwidth is not fully loaded instantly. In this post I'll walk you through the lifecycle of a new fast non-exit relay, since Tor's bandwidth estimation and load balancing has gotten much more complicated in recent years. https://blog.torproject.org/blog/lifecycle-of-a-new-relay --Roger

1 0

Is this suspicious?
by I 10 Sep '13

10 Sep '13

1 0