January 2016 - tor-relays - lists.torproject.org

Please enable IPv6 on your relay!
by Moritz Bartl 28 Jan '17

28 Jan '17

Hi! We still have a depressingly low number of relays that support IPv6 (currently only ~120 of ~1900 relays). If your host supports IPv6, please enable it, especially if you run an exit! This has to be done explicitly. https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto In short, you add: ORPort [IPv6::address]:port IPv6Exit 1 ExitPolicy reject6 *:* (or a more open exit policy respectively) Thanks! -- Moritz Bartl https://www.torservers.net/

30 42

Opt-In Trial: Fallback Directory Mirrors
by Nick Mathewson 22 Jun '16

22 Jun '16

TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in! We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities. Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports. For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load. We want relays that expect to be stable for the next 2 years, with: good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity. In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_d… If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.) For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.) all best wishes, & thanks for running Tor!

19 29

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
by hwertiout695＠Safe-mail.net 15 Apr '16

15 Apr '16

Hi. > TL;DR: Stable non-exit relays can help tor clients use the Tor > network. Please opt-in! My relay is on the list and I want to opt in! eriador 6DE61A6F72C1E5418A66BFED80DFB63E4C77668F

2 1

Reminder: exit nodes probably shouldn't be using Google's DNS servers
by Nick Mathewson 25 Feb '16

25 Feb '16

Hi, all! While looking into a bug report, I noticed that an exit node was using one of Google's well-known public DNS servers for its own DNS server. No disrespect to the operators of Google's fine public DNS service, but my sense is that using it for a Tor exit node might not be the greatest idea for users' privacy, having one DNS provider that gets to see so many requests. It's probably a better idea to have your own local cacheing DNS server. Would anybody like to share a guide about how to set one of those up safely and migrate correctly? best wishes, -- Nick

23 38

Relays with misconfigured MyFamily (declared vs. effective)
by nusenu 17 Feb '16

17 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, the following relays have misconfigured MyFamily settings. 'misconfigured' is defined by declared family does not match effective family (as computed by onionoo's new effectiv_family field [1] - thanks Karsten). Maybe we will see future versions of globe or atlas displaying a diff of the two family sets to make such misconfigurations more visible. Please let me know if you find any errors (I did not fact check the output). +------------------------------------------+----------+ | Contact (truncated) | Fingerpr | +------------------------------------------+----------+ | +1 303-265-9283, rdump@OFTC | 09683D5D | | 0x3AEE83BB539036CA <bb AT symvaro DOT co | 6FDF2D3B | | 0x6F6D60C1 Security Dept <hello@brasshor | 445F1C85 | | 0x6F6D60C1 Security Dept <hello@brasshor | 6BC82EBA | | 0x6F6D60C1 Security Dept <hello@brasshor | 254EB51B | | 0x6F6D60C1 Security Dept <hello@brasshor | B3515F16 | | 0xDE731050 Gareth Llewellyn <gareth@netw | 5CAECF26 | | 0xFD78BCE1 Fruity Oaty Tor Exit <torexit | 1ECD73B9 | | 1024D/1DFBA164 Bernhard M. Wiedemann <to | 172DC95F | | 1024D/39B9820C admin at perfect minus pr | B897826E | | 1024D/39B9820C admin at perfect minus pr | 5FCC8306 | | 1024D/39B9820C admin at perfect minus pr | 2421E10D | | 1024D/39B9820C admin at perfect minus pr | AC7AE98C | | 1024D/39B9820C admin at perfect minus pr | E8B7D19C | | 1024D/39B9820C admin at perfect minus pr | ED9F582E | | 1024D/39B9820C admin at perfect minus pr | B1843B40 | | 1MTUwHFknUyUgRYqpNDYiA2j7sXTYoCe2P | E799227D | | 4096R/8BA2371C Fabian Keil <fk@fabiankei | 34A5FBA4 | | 8192R/0xB431B67770E4AA38 Mikal Villa <me | FE305F8E | | <hneal AT imalazybastard dot com> | CF9E4605 | | <hneal AT imalazybastard dot com> | D12F66D6 | | <periplanetaamericanus AT gmail dot com> | 5B5213C4 | | <periplanetaamericanus AT gmail dot com> | 47D04EC4 | | <periplanetaamericnaus AT gmail dot com> | F19106D7 | | <support at gkware dot com> | E754AA99 | | <support at gkware dot com> | 868A253C | | <support AT gkware dot com> | 48674035 | | <tech AT dana dot io> - 1AgYtavutLAMxUYM | 752DA4A4 | | <tor .AT. jgjtech .DOT. com> BTC: 1QHXLy | 0DA71D95 | | <tor .AT. jgjtech .DOT. com> BTC: 1QHXLy | 31A40828 | | <tor AT 1d4 dot us> - 1N7sBLKvekRD4EUL2b | F1107CB0 | | Abuse Department <abuse AT hartvoorinter | 81B75D53 | | Abuse Department <abuse AT hartvoorinter | 89E3170B | | abuse<__aT>icetor{_DoT===}is - 1GDerBXAJ | 1D9D1C1D | | anders.io | 91361C96 | | anders.io | D56AA4A1 | | anders.io | 3A2192F5 | | Bauruine <torcontact aatt tuxli.ch> - 1C | 63C1904F | | Bauruine <torcontact aatt tuxli.ch> - 1C | 52F7C67B | | BFC62AD3 johannes <tor (@) kontrollappar | 750941D5 | | Big Jim Slade <sysop AT bigjimslade dot | 9AFA555B | | Big Jim Slade <sysop AT bigjimslade dot | ACDC9C49 | | DFRI <tor AT dfri dot se> | A10C4F66 | | DFRI <tor AT dfri dot se> | DD8BD730 | | DFRI <tor AT dfri dot se> | EC84E232 | | DFRI <tor AT dfri dot se> | A478E421 | | Fabian Keil <fk(a)fabiankeil.de> 8BA2371C | 5CE3AD8A | | General Zod <zod(a)kdf.mil> | 556D59FA | | General Zod <zod(a)kdf.mil> | CBABC09D | | GetReal <x50 AT riseup dot net> | 51529D02 | | http://www.onion.network/ <info at onion | F89A5238 | | http://www.privacyfoundation.ch/abuse/ | DC41244B | | http://www.privacyfoundation.ch/abuse/ | 0111BA9B | | http://www.privacyfoundation.ch/abuse/ | DE7DE889 | | http://www.privacyfoundation.ch/abuse/ | 487092BA | | http://www.privacyfoundation.ch/abuse/ | AD86CD1A | | http://www.privacyfoundation.ch/abuse/ | 95DA61AE | | http://www.privacyfoundation.ch/abuse/ | B060482C | | http://www.privacyfoundation.ch/abuse/ | 88487BDD | | https://www.torservers.net/donate.html < | 4E021F36 | | https://www.torservers.net/donate.html < | F657ACB3 | | https://www.torservers.net/donate.html < | 64D500C4 | | iggs <tor.20.iggs AT spamgourmet dot com | 2F557D48 | | jvictors at jessevictors com, PGP 0xC20B | C6DC982A | | jvictors at jessevictors com, PGP 0xC20B | 4B8C39A5 | | jvictors at jessevictors com, PGP 0xC20B | BFA0E9F3 | | jvictors at jessevictors com, PGP 0xC20B | 40DF7E2E | | Kevin <tor AT kberanek dot com> - 14BTbA | 92EA887F | | Kevin <tor AT kberanek dot com> - 14BTbA | A1E02458 | | kingbiskit(a)gmail.com - 18gEJokSQ3uwo3QTM | C921704A | | kingbiskit(a)gmail.com - 1CoXRRwDt6YVTZmJ3 | 3246AF7B | | M.K. Nitrox <mk DOT reg AT t-online DOT | BD912646 | | montanisemperliberi <a> safe-mail.net | E8B6E46B | | Nicholas Merrill <nick AT calyx dot com> | 51BFE90C | | Nicholas Merrill <nick AT calyx dot com> | 0B5E5E70 | | Nicholas Merrill <nick AT calyx dot com> | 84D361B7 | | Nicholas Merrill <nick AT calyx dot com> | E4D1F25D | | Pascal666 at Users dot SourceForge dot N | C9437269 | | Pascal666 at Users dot SourceForge dot N | 5B7AEB14 | | Peter Palfrader | 847B1F85 | | R P <edschlonz AT yahoo dot de> | FF06E7A0 | | Samuel Whited 0x54083AE104EA7AD3 <sam AT | CA54C9F2 | | Sebastian <tor(a)sebastianhahn.net> - 12Nb | EBE718E1 | | snIP3r <sniper(a)restricted-area.de> | 3EE8D536 | | tor TA fejk tod se | 2AFE9201 | | torelay [ANTISPAM at] ruggedinbox [ANTIS | 0559A3D3 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | BAACCB29 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 0B454C7E | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 5A551BF2 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 4436A57F | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 6D3A3ED5 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 75C4495F | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 6A29FD8C | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 0C77421C | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 8073670F | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | B35C5739 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | E6E18151 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 6A37488D | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | E11B6AE1 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 70C55A11 | | Torservers.net <support .AT. torservers | 488239E0 | | Torservers.net <support .AT. torservers | 6B1E0019 | | Torservers.net <support .AT. torservers | C46524E5 | | Torservers.net <support .AT. torservers | 770BE0CD | | Torservers.net <support .AT. torservers | 5C84C359 | | Torservers.net <support .AT. torservers | 20B0038D | | Torservers.net <support .AT. torservers | 5714542D | | Torservers.net <support .AT. torservers | B4F883DB | | Torservers.net <support .AT. torservers | 78213EC8 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 4E918B21 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | A494237E | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 35FEEA5F | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 2576BFB0 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | A1025D32 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | C8D44E91 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | B7EC0C02 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | FFD6C2CE | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 4C6F66B1 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 43D0AB1B | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | A57B43E1 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 9030DCF4 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 3A5F08D0 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 5C1E076A | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 482A381B | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 2D671A4A | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 66CFF345 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 55F5CF9D | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | FEF59210 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | B4A553CB | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 92506510 | +------------------------------------------+----------+ ..based on onionoo.thecthulhu.com's data from 2015-07-15 18:00 [1] https://trac.torproject.org/projects/tor/ticket/16276 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVprfXAAoJEFv7XvVCELh0/FcP/28/dhefuPNQaBNSY59NTZTs snwb9vRlAzhDDm0XmWEMIaawFlNjV8shJD8dWvzSvynWHYQySfrStmDdfkpe5CSC lu9ceE6qhhZe+RkyDPM3PdxLhz29XVK+KvQcDcCeWp6nIHzXIOJL+Xk7v7FoU75S Vx8GjhVQd/aiHJQg96zlpdzkAsU000jG2E3Z2EH+gd4Uypl94wgqd0482LSSehiQ LVbhPt6C8NlX32kZ4yAD3W5cHRoyhg30x076X8XHZ16H6F2l801hhON5X32VmXdv vd/kJ7R9JKo4Uig1Y9hq3qpsRsO8aJaN2JOXMsGw2A+6eNFA2OPFLg3/sNKLgiLV N/CPqDlMVsotMDcXX4iBYSHW0Y+J7vyc5ezxE/rKWzBCBZSnK9Sb5UzcrDnOfJRO ABFv+ZtGxSQYVPcnICVdMr+3Kuk0FnKMm7z2ufYriRxDK573LQgNJQnjZ3Tc3JG+ PIVZun0IN/+1gZmQif57xIjW1OFDbDYbhMtYFYbK9zRd7PidIr5NHcYCkEY4whfP 2vhN4jbtYQZZY/hDAMLZVBKDJ42tOYG/8EaWZeMJ8y/pd+F8EvT7ceWzXwuhYm77 WiK4VsgFU7PR7ETi/DJL+ajmFEjpRJ8QOy3J5E/dq/eumkkzL/eBTPL7ydnTmD/u 9271J4DjQYPfjzVtVqdl =ecVW -----END PGP SIGNATURE-----

2 3

How to prevent netscan usage?
by Roland 'ValiDOM' Jungnickel 07 Feb '16

07 Feb '16

hi, I'm operating a tor exit with a relatively high bandwith rate for more than 3 years. My ISP receives more and more abuse tickets about my server regarding netscans. These netscans are executed with dest. port 80 so I'm not able to block them easily. Any idea how to prevent netscans using my exit node? Below you find an extract of such an abuse mail. Thanks a lot! ValiDOM Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 41518 => 46.20.92.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 41545 => 46.20.92.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 41575 => 46.20.92.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 45219 => 59.192.63.xx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 45218 => 59.192.63.xx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 45217 => 59.192.63.xx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 42460 => 59.203.179.x 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 42517 => 59.203.179.x 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 42569 => 59.203.179.x 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 57564 => 59.211.15.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 57596 => 59.211.15.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 57631 => 59.211.15.xxx 80 Wed Nov 18 12:55:27 2015 TCP 88.198.14xxx 58022 => 59.228.86.xxx 80 Wed Nov 18 12:55:27 2015 TCP 88.198.14xxx 58046 => 59.228.86.xxx 80 Wed Nov 18 12:55:27 2015 TCP 88.198.14xxx 58081 => 59.228.86.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 37123 => 64.238.74.xx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 37178 => 64.238.74.xx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 41003 => 65.20.53.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 45785 => 65.186.130.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 45850 => 65.186.130.xxx 80 Wed Nov 18 12:55:26 2015 TCP 88.198.14xxx 45907 => 65.186.130.xxx 80 Wed Nov 18 12:55:12 2015 TCP 88.198.14xxx 60607 => 66.87.185.xxx 80 Wed Nov 18 12:55:12 2015 TCP 88.198.14xxx 60611 => 66.87.185.xxx 80 Wed Nov 18 12:55:12 2015 TCP 88.198.14xxx 60613 => 66.87.185.xxx 80 Wed Nov 18 12:55:14 2015 TCP 88.198.14xxx 52693 => 69.191.200.xxx 80 Wed Nov 18 12:55:14 2015 TCP 88.198.14xxx 52740 => 69.191.200.xxx 80 Wed Nov 18 12:55:14 2015 TCP 88.198.14xxx 52783 => 69.191.200.xxx 80 Wed Nov 18 12:55:27 2015 TCP 88.198.14xxx 35453 => 71.54.215.xx 80 Wed Nov 18 12:55:27 2015 TCP 88.198.14xxx 35464 => 71.54.215.xx 80 Wed Nov 18 12:55:12 2015 TCP 88.198.14xxx 39263 => 101.249.145.xxx 80

6 9

Should Onionoo consider relays with the same ip# to be part of the same family?
by Virgil Griffith 05 Feb '16

05 Feb '16

For example, these two pairs of relays that came online yesterday: * https://atlas.torproject.org/#details/0ED2D734F295427E5A3719FA7B9985C335839… * https://atlas.torproject.org/#details/667C297D3EC6E1281D68F7F4C8C9BE8324D13… and * https://atlas.torproject.org/#details/667C297D3EC6E1281D68F7F4C8C9BE8324D13… * https://atlas.torproject.org/#details/2FF21F475C2E668C23DB7625A9D45B52591B3… (Hat-tip to Sean Saito for pointing these out.) No wrong answer---just wondering what is the community's vibe on this issue. I can go either way. -V

6 9

"Relay unresponsive (last heartbeat:...)" every hour or so?
by Deep Lodokus 03 Feb '16

03 Feb '16

Hi All! Running a TOR relay on a Raspberry Pi B+, not overclocked, over WiFi, running Raspbian. TOR is capped at RelayBandwidthRate 1000 KBytes and RelayBandwidthBurst 1500 KBytes While my /var/log/tor/log suggests that all is fine, my tor-arm logs suggest otherwise. See some copy/paste from logs below. Is something wrong with my setup? If there's indeed a loss of connectivity every hour or so, should I refrain from running this relay altogether? I haven't tried to connect the Raspberry Pi directly with a network cable, I could try that. Thanks! Snippet from /var/log/tor/log: *Jan 28 19:30:51.000 [notice] Circuit handshake stats since last time: 576/576 TAP, 1281/1281 NTor.Jan 29 01:30:51.000 [notice] Heartbeat: Tor's uptime is 1 day 12:00 hours, with 23 circuits open. I've sent 565.53 MB and received 604.21 MB.Jan 29 01:30:51.000 [notice] Average packaged cell fullness: 98.805%* Snippet from tor-arm logs: * │ 21:26:44 [ARM_NOTICE] Relay resumed │ 21:26:17 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 21:26:07 2016) │ 20:04:22 [ARM_NOTICE] Relay resumed │ 20:03:56 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 20:03:42 2016) │ 19:30:51 [NOTICE] Circuit handshake stats since last time: 639/639 TAP, 1104/1104 NTor. │ 19:30:51 [NOTICE] TLS write overhead: 3% │ 19:30:51 [NOTICE] Average packaged cell fullness: 98.954% │ 19:30:51 [NOTICE] Heartbeat: Tor's uptime is 2 days 6:00 hours, with 40 circuits open. I've sent 1.72 GB and received 1.76 GB. │ 19:18:33 [ARM_NOTICE] Relay resumed │ 19:18:12 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 19:17:57 2016) 21:26:07 2016) │ 18:21:37 [ARM_NOTICE] Relay resumed │ 18:21:15 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 18:21:00 2016) │ 17:22:44 [ARM_NOTICE] Relay resumed │ 17:22:16 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 17:22:02 2016) │ 16:14:26 [ARM_NOTICE] Relay resumed │ 16:14:10 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 16:13:55 2016) │ 15:19:40 [ARM_NOTICE] Relay resumed │ 15:19:13 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 15:19:02 2016) │ 14:04:23 [ARM_NOTICE] Relay resumed │ 14:04:01 [ARM_NOTICE] Relay unresponsive (last heartbeat: Fri Jan 29 14:03:48 2016) │ 13:30:51 [NOTICE] Circuit handshake stats since last time: 593/593 TAP, 895/895 NTor.*

2 3

tor middle node question
by Markus Koch 03 Feb '16

03 Feb '16

hi, as a good TOR support peon I got a dedicated server and set up TOR 3-4 weeks ago. Everything went great, I got my Guard, Fast and Stable etc. Flag and my little server was busy & happy. After restarting the TOR daemon I lost all my flags and even after 12 hours I only got Running and Valid back. What went wrong? My server is: https://torstatus.blutmagie.de/router_detail.php?FP=caf1eea0e8e8919dfc480a8… Markus

8 10

Nameservers fail and come back at the same time?
by SuperSluether 02 Feb '16

02 Feb '16

My exit node's consensus weight just jumped from 20 to 1750 overnight. When I checked to see how things were going, my log file is full of nameserver problems, happening every couple of minutes: Jan 31 14:12:40.000 [warn] eventdns: All nameservers have failed Jan 31 14:12:40.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up Jan 31 14:18:35.000 [warn] eventdns: All nameservers have failed Jan 31 14:18:35.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up Jan 31 14:20:53.000 [warn] eventdns: All nameservers have failed Jan 31 14:20:53.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up Jan 31 14:20:59.000 [warn] eventdns: All nameservers have failed Jan 31 14:20:59.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up But the "All nameservers have failed" and "Nameserver xxx is back up" messages happen in pairs /at the exact same time./ What's going on here, and is there a way to fix this? My VPS has 2 nameservers listed for it, should I be using those? At any rate, my exit node is still getting enough traffic to hit the bandwidth limit, so I'm assuming it's still functioning at some capacity. Here's the Atlas link if anyone wants to check out the details: https://atlas.torproject.org/#details/D632232DDC823D00ACB4F99668B58B2D5BCFF…

4 8