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
On Thu, 08 Jan 2015, Nick Mathewson wrote:
Would anybody like to share a guide about how to set one of those up safely and migrate correctly?
o apt-get install unbound o remove all nameserver entries in /etc/resolv.conf and add one for the local recursor. Either manually or use (untested): sed -i -e 's/^nameserver /#&/; $a nameserver 127.0.0.1' /etc/resolv.conf o prevent anything else from modifying that file ever again: chattr +i /etc/resolv.conf
voila.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Why not use a private DNS server from opennicproject.org
Am 08. Jänner 2015 15:11:09 WEZ, schrieb Peter Palfrader weasel@torproject.org:
On Thu, 08 Jan 2015, Nick Mathewson wrote:
Would anybody like to share a guide about how to set one of those up safely and migrate correctly?
o apt-get install unbound o remove all nameserver entries in /etc/resolv.conf and add one for the local recursor. Either manually or use (untested): sed -i -e 's/^nameserver /#&/; $a nameserver 127.0.0.1' /etc/resolv.conf o prevent anything else from modifying that file ever again: chattr +i /etc/resolv.conf
voila.
-- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net
Encrypted messages are welcome. 0x84DF1F7E6AE03644
- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux)
mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL - -----END PGP PUBLIC KEY BLOCK-----
On 01/08/2015 10:11 AM, Peter Palfrader wrote:
... o remove all nameserver entries in /etc/resolv.conf and add one for the local recursor. Either manually or use (untested): sed -i -e 's/^nameserver /#&/; $a nameserver 127.0.0.1' /etc/resolv.conf o prevent anything else from modifying that file ever again: chattr +i /etc/resolv.conf ...
For what it's worth, most *nix OSs have files that are prepended and/or appended to /etc/resolv.conf, which are the intended way of doing this. They often come with corresponding man pages, too. OpenBSD has /etc/resolv.conf.tail, and Ubuntu has base, head, and tail in the /etc/resolvconf/resolv.conf.d directory.
On 01/08/2015 10:04 AM, Nick Mathewson wrote:
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 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I actually just switched to unbound, which is included in the OpenBSD base system as of the most recent release.
Aside from starting it, all you have to do is add the following to your /etc/rc.conf.local so that it starts up on boot:
unbound_flags=""
And add 'nameserver 127.0.0.1' as the first line of your /etc/resolv.conf.tail (and, for the time being, /etc/resolv.conf - see the man pages for details). I still have an OpenDNS server and a Google server listed below it in case something goes wrong with the local one.
Here's Michael Lucas's guide, which includes information on how to test your DNS server, how to restrict access (although that seems to be default now), and how to set up DNSSEC in a minute or two:
http://blather.michaelwlucas.com/archives/580
Ignore his installation instructions. They were written before it was included in the base system.
On 01/08/2015 05:07 PM, Libertas wrote:
And add 'nameserver 127.0.0.1' as the first line of your /etc/resolv.conf.tail
Why not /etc/resolv.conf.head ??
On 01/08/2015 11:21 AM, Toralf Förster wrote:
On 01/08/2015 05:07 PM, Libertas wrote:
And add 'nameserver 127.0.0.1' as the first line of your /etc/resolv.conf.tail
Why not /etc/resolv.conf.head ??
I was actually just looking into this, and it strangely seems that OpenBSD doesn't have one. You're right, too - as far as I know, if you're using DHCP (which is indeed an 'if' in the context of servers), the dynamic nameserver settings will override resolv.conf.tail's.
That said, you can find dhclient.conf one-liners to set a permanent primary DNS server on IRC or your search engine of choice. I haven't tested any (and I don't need any, having a static IP), so I won't copy-and-paste any here.
I also can't find any mention of resolv.conf.head in the OpenBSD source code, or any reason online for why it doesn't exist, so I may write a patch.
On Thu, Jan 08, 2015 at 10:04:35AM -0500, Nick Mathewson wrote:
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?
I know people have already started to make specific suggestions and I don't intend to comment on those. But I wanted to say that in general there is another consideration: AS and other network level vulnerabilities. Obviously recursive resolution may send queries wherever, but using a local resolver should limit the network adversaries seeing exit DNS traffic. The flip side is that, against such an adversary, using a DNS server that supports encryption of queries and responses is probably more important than it being local. (At least until Tor starts choosing exits to minimize exposure to network adversaries on the destination link ;>)
-Paul
On Thu, 08 Jan 2015 08:38:35 -0800, Paul Syverson paul.syverson@nrl.navy.mil wrote:
The flip side is that, against such an adversary, using a DNS server that supports encryption of queries and responses is probably more important than it being local.
I like to chain unbound up to dnscrypt-proxy in order to encrypt DNS traffic for this very reason.
dnscrypt-proxy frequently is unable to keep up however, so I currently have unbound configured to make queries directly if dnscrypt-proxy is not responding.
That was my bug report, thanks for the quick turnaround on that one :3
My problem was that my infrastructure, including that tor exit node, is puppetized. But a problem with that resulted in dhcp blitzing /etc/resolv.conf and I kept putting in google dns out of sheer muscle memory and I simply forgot to put it back.
It is pretty easy. This is the relevant configuration snippet from my puppet manifest:
# setup internal DNS cache / resolver
include bind bind::server::conf { '/etc/bind/named.conf': directory => '/etc/bind', listen_on_addr => [ 'any' ], listen_on_v6_addr => [ 'any' ], forwarders => [ '2001:4860:4860::8844', '2001:1608:10:25::1c04:b12f', '2600::1' ], allow_query => [ 'any' ], statistics_file => '/etc/bind/named.stats', recursion => 'yes', extra_options => { 'forward' => 'only', 'auth-nxdomain' => 'no', } }
+ some other symlinks to account for the fact this isn't a RHEL box like the module implicitly assumes.
I even have DNSSEC query validation setup, as the forwarders seem to support it.
Now I have named caching again. For those who are unclear, it helps a LOT. From rndc stats:
++ Cache Statistics ++ [View: default] 53446329 cache hits 5246190 cache misses 15049168 cache hits (from query) 3044495 cache misses (from query)
The exit node in question sits between 10 and 20mb/s continuously, and goes through a crazy amount of traffic. Something like 50T last month.
I even threw on a squid proxy on regular http and that's caching something like 5-10% of all requests and overall http bandwidth.
Where it gets interesting is now that I've moved all of my DNS traffic into a native ipv6 stack (outside of v4 local queries), I can say that all the udp traffic I get is not legitimate/requested.
Which is looking to be a lot of traffic.
I got dinged with a nice udp DDoS the other day, and now its' even more clear about what traffic is bad on tcpdump.
On Thu, Jan 8, 2015 at 9:04 AM, Nick Mathewson nickm@freehaven.net wrote:
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 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Thu, 08 Jan 2015 18:20:42 +0000, eric gisse wrote: ...
forwarders => [ '2001:4860:4860::8844','2001:1608:10:25::1c04:b12f', '2600::1' ],
What are these addresses? (Did I miss that upthread?)
Esp. the 2600::1 looks nice, and suitable for a certain magazine. :-)
(And the ::8844 is eerily similar to Google's 8.8.4.4.)
Andreas
Various public ipv6 dns servers, and yes that one is Google's.
Resolver traffic is split across all the forwarders and I'm caching everything so I'm OK with it.
On Fri, Jan 9, 2015 at 8:07 AM, Andreas Krey a.krey@gmx.de wrote:
On Thu, 08 Jan 2015 18:20:42 +0000, eric gisse wrote: ...
forwarders => [ '2001:4860:4860::8844','2001:1608:10:25::1c04:b12f', '2600::1' ],
What are these addresses? (Did I miss that upthread?)
Esp. the 2600::1 looks nice, and suitable for a certain magazine. :-)
(And the ::8844 is eerily similar to Google's 8.8.4.4.)
Andreas
-- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
hi,
eric gisse:
I even threw on a squid proxy on regular http and that's caching something like 5-10% of all requests and overall http bandwidth.
Are you saying you are routing exit traffic through a transparent squid http proxy?
If that is the case, please do not interfere with exit traffic in any way.
Why? People say 'DO NOT MESS WITH TRAFFIC' but in the same breath they say 'BUT USE A CACHING DNS RESOLVER'.
This is an internally inconsistent attitude, and is not consistent with how large scale operations function either. Tools like varnish, CDN's, memcache, dns caching, etc are all common - and best - practices.
If there's a practical consideration I am missing, that's different.
On Fri, Jan 9, 2015 at 6:29 PM, Nusenu BM-2D8wMEVgGvY76je1WXNPfo8SrpZt5yGHES@bitmessage.ch wrote:
hi,
eric gisse:
I even threw on a squid proxy on regular http and that's caching something like 5-10% of all requests and overall http bandwidth.
Are you saying you are routing exit traffic through a transparent squid http proxy?
If that is the case, please do not interfere with exit traffic in any way.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
eric gisse wrote:
Why? People say 'DO NOT MESS WITH TRAFFIC' but in the same breath they say 'BUT USE A CACHING DNS RESOLVER'.
Because the interface level at which exit traffic proper occurs is TCP, and the interface contract for the client is that the TCP stream will be direct to the intended destination. The interface level at which Tor-traversing DNS requests occur is DNS, and the interface contract for the client is that the DNS request will be resolved in some way that reflects the consensus public DNS on the Internet. Using a DNS cache is consistent with being expected to terminate DNS. Using an HTTP cache is not consistent with being expected to terminate TCP. Reblocking at the TCP level presumably happens, for instance, and is not considered "messing with traffic" because it's not specified that Tor passes arbitrary IP packets, only TCP (and I'm not sure it even requires _full_ TCP other than the bidirectional octet streams; I forget whether the urgent marker is passed through, for instance).
So it's not inconsistent to hear those for exit operators WRT Tor's design. If you think the design is flawed, that's a separate matter.
---> Drake Wilson
This isn't exactly a convincing argument.
The HTTP specification explicitly supports caching. On a protocol level, this is quite acceptable and standard. The method I am using is precisely what ISP's do in scenarios where they want to maximize their bandwidth.
On Fri, Jan 9, 2015 at 8:12 PM, Drake Wilson drake@dasyatidae.net wrote:
eric gisse wrote:
Why? People say 'DO NOT MESS WITH TRAFFIC' but in the same breath they say 'BUT USE A CACHING DNS RESOLVER'.
Because the interface level at which exit traffic proper occurs is TCP, and the interface contract for the client is that the TCP stream will be direct to the intended destination. The interface level at which Tor-traversing DNS requests occur is DNS, and the interface contract for the client is that the DNS request will be resolved in some way that reflects the consensus public DNS on the Internet. Using a DNS cache is consistent with being expected to terminate DNS. Using an HTTP cache is not consistent with being expected to terminate TCP. Reblocking at the TCP level presumably happens, for instance, and is not considered "messing with traffic" because it's not specified that Tor passes arbitrary IP packets, only TCP (and I'm not sure it even requires _full_ TCP other than the bidirectional octet streams; I forget whether the urgent marker is passed through, for instance).
So it's not inconsistent to hear those for exit operators WRT Tor's design. If you think the design is flawed, that's a separate matter.
---> Drake Wilson
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
eric gisse wrote:
This isn't exactly a convincing argument.
The HTTP specification explicitly supports caching.
But the TCP specification doesn't. Nor is the Tor client signaling to you that they want an HTTP connection and not a raw TCP connection. Whether they happen to be passing octets over it that correspond to an HTTP stream is irrelevant.
---> Drake Wilson
Drake Wilson wrote:
But the TCP specification doesn't. Nor is the Tor client signaling to you that they want an HTTP connection and not a raw TCP connection. Whether they happen to be passing octets over it that correspond to an HTTP stream is irrelevant.
Or alternatively, let me put the distinction this way:
"Opera-tor." "Could you please find me the number for Pythagoras' Pizza Palace?" "Sure, let me get out the copy of the phone book at my desk. It's 555-6283." "Thanks."
...
"Opera-tor." "Could you please connect me to 555-6283?" "Sure." *beep beep* "Pythagoras' Pizza Palace? I'd like six Scalene Specials delivered for J. Random User-Agent." "No problem, we'll get that to you in 30 minutes."
...
"Opera-tor." "Could you please connect me to 555-6283?" "Sure." *beep beep* "Pythagoras' Pizza Palace? My client just called me from jail! You _do_ remember what 'six Scalene Specials' was supposed to be code for, right?" "Oh, this is actually the operator. I had the right kind of spare, fresh pizza lying around already, so I figured..." "What?!" "Don't worry! I didn't do anything funny to it! It's all good!" "!!!"
---> Drake Wilson
If you're caching exit traffic and a very naughty person uses your exit, you've potentially cached "evidence" (to be seized). Also likely has interesting legal questions, eg. 'if you're actually storing the content, then do you "possess" it?' ymmv with jurisdiction and ianal.
eric gisse:
Why? People say 'DO NOT MESS WITH TRAFFIC' but in the same breath they say 'BUT USE A CACHING DNS RESOLVER'.
This is an internally inconsistent attitude, and is not consistent with how large scale operations function either. Tools like varnish, CDN's, memcache, dns caching, etc are all common - and best - practices.
If there's a practical consideration I am missing, that's different.
On Fri, Jan 9, 2015 at 6:29 PM, Nusenu BM-2D8wMEVgGvY76je1WXNPfo8SrpZt5yGHES@bitmessage.ch wrote:
hi,
eric gisse:
I even threw on a squid proxy on regular http and that's caching something like 5-10% of all requests and overall http bandwidth.
Are you saying you are routing exit traffic through a transparent squid http proxy?
If that is the case, please do not interfere with exit traffic in any way.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Fri, Jan 9, 2015 at 9:18 PM, cacahuatl cacahuatl@autistici.org wrote:
If you're caching exit traffic and a very naughty person uses your exit, you've potentially cached "evidence" (to be seized).
That logic applies equally to DNS; indeed, it is why the CMU Tor exit *doesn't* run a DNS cache.
(It talks to CMU's DNS servers, which do cache, but for the entire network.)
(If you can't trust your network provider's DNS resolver, the tradeoff may be different.)
zw
That's my point. The logic applies to either both or none.
Plus the logic starts to get warped when you wonder "So do you BadExit every node that runs on an ISP that caches traffic?"
What about ISP's (and openDNS) that NXDOMAIN trap to insert advertising?
Regarding 'cached evidence', logs are short term for diagnostic purposes and shredded. Nothing identifiable is logged, which would be annoying to get to due to LUKS encryption of the entire filesystem.
The exit node burns through about 20mb/s continuously. Fundamentals of tor design and sheer volume of noise make this a toughie.
On Fri, Jan 9, 2015 at 8:35 PM, Zack Weinberg zackw@cmu.edu wrote:
On Fri, Jan 9, 2015 at 9:18 PM, cacahuatl cacahuatl@autistici.org wrote:
If you're caching exit traffic and a very naughty person uses your exit, you've potentially cached "evidence" (to be seized).
That logic applies equally to DNS; indeed, it is why the CMU Tor exit *doesn't* run a DNS cache.
(It talks to CMU's DNS servers, which do cache, but for the entire network.)
(If you can't trust your network provider's DNS resolver, the tradeoff may be different.)
zw _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
eric gisse wrote:
Plus the logic starts to get warped when you wonder "So do you BadExit every node that runs on an ISP that caches traffic?"
What about ISP's (and openDNS) that NXDOMAIN trap to insert advertising?
These, I think, are more general points that have not adequately been resolved anywhere, though I think the vague consensus has been that the latter merits a BadExit at the moment. Indeed the basic idea of "exits should behave transparently and not manipulate traffic" relies on "there exists a relevant public Internet which is more or less consistent in its behavior as far as not manipulating traffic". To the extent that that becomes less true, the notion of behaving exits becomes more detached from the practical situation.
---> Drake Wilson
On Fri, Jan 9, 2015 at 10:26 PM, Drake Wilson drake@dasyatidae.net wrote:
eric gisse wrote:
Plus the logic starts to get warped when you wonder "So do you BadExit every node that runs on an ISP that caches traffic?"
What about ISP's (and openDNS) that NXDOMAIN trap to insert advertising?
These, I think, are more general points that have not adequately been resolved anywhere, though I think the vague consensus has been that the latter merits a BadExit at the moment. Indeed the basic idea of "exits
An external NX ad trap is a bit tertiary since the exit is truly representing its view of the net.
As far as http caching, it would be relatively fine IF the cache truly did good practice, and IF the site truly did good design for the cache to follow. However those two necessary truths are often false, whether by AND or XOR context. So to be true, a cache shouldn't be deployed, but in the interest of bandwidth they are, more commonly at small end-tier user access ISPs (including exits) for that purpose.
I'd suggest best practice is for - users to use https to bypass - caches to insert their tagline in http headers so users can bitch to the owner. - Tor exits? Well, they're volunteer paid diversity, so which is more valuable to you? The IF's above, or TCP truth at potential cost to diversity?
I prefer TCP truth, but if I was a constrained operator I'd do my best research into setting up a quality cache. Provided caching images of ill repute on disk were not an overriding concern.
Last, the badexit projects should probably try to assess the current state of caching quality in order to further suggest practices for operators.
On 2015-01-09 19:21, eric gisse wrote:
What about ISP's (and openDNS) that NXDOMAIN trap to insert advertising?
Just a quick point, OpenDNS doesn't do that anymore.
https://www.opendns.com/no-more-ads/
(Others do, and it's still a terrible idea there, but OpenDNS has seen the light and/or found a business model that doesn't involve selling their users as product)
On Fri, Jan 9, 2015 at 6:29 PM, Nusenu
Are you saying you are routing exit traffic through a transparent squid http proxy?
If that is the case, please do not interfere with exit traffic in any way.
eric gisse:
Why?
Is your exit breaking non-HTTP protocolls on destination port 80?
Yes :(
1) Blanket caching on port 80 is mostly fine, but not completely due to squid dropping/erroring on non-http traffic. Not acceptable. 2) I've been unable to find a way to pass non-http traffic in a reliable way. 3) netfilter inspection to determine protocol ends with the layer7 filter project which appears to dead. I might be able to nudge the inspection capabilities up to current 3.x kernels but that's iffy, but either way it isn't currently functional or even functional-adjacent. 4) A *gobsmackingly large* (40k+) amount of CLOSE_WAIT connections to squid gets setup over a period few hours, and I'm at a bit of a loss as to why.
I've never had this problem before with previous personal or professional usage of squid...
This breaks the fuck out of everything anyway after a few hours.
I am unmoved by the philosophical considerations. But there are serious practical ones that I didn't fully think through. So, the puppet manifest for squid gets put away again and the iptables rule is removed until I can solve the above problems.
I'm keeping DNS caching though. DNS gets to be pretty slow, as seen from this segment of the bind statistics output:
283152 queries with RTT < 10ms 1724419 queries with RTT 10-100ms 1006967 queries with RTT 100-500ms 60675 queries with RTT 500-800ms 48536 queries with RTT 800-1600ms 2961 queries with RTT > 1600ms
I assume everyone's ok with that, right? :p
On Sat, Jan 10, 2015 at 4:11 AM, Nusenu BM-2D8wMEVgGvY76je1WXNPfo8SrpZt5yGHES@bitmessage.ch wrote:
On Fri, Jan 9, 2015 at 6:29 PM, Nusenu
Are you saying you are routing exit traffic through a transparent squid http proxy?
If that is the case, please do not interfere with exit traffic in any way.
eric gisse:
Why?
Is your exit breaking non-HTTP protocolls on destination port 80?
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2015-01-08 08:04, Nick Mathewson wrote:
It's probably a better idea to have your own local cacheing DNS server.
It is especially a good idea to have your own local DNS resolver if you run Tor exits at an institution that's required to otherwise log DNS queries.
Tor needs a separate (and non-logging) DNS resolution system to prevent the institution from being presumed aware of Tor users' lookups.
That this also protects Tor users from having their DNS queries logged is good as well, but that isn't necessarily the driver for the institution. ;)
Would anybody like to share a guide about how to set one of those up safely and migrate correctly?
As others have suggested, using unbound is probably the best option.
It's the default resolver, replacing bind, in OpenBSD 5.6+ (see unbound(8) [1] and unbound.conf(5) [2]).
Otherwise running "${package_manager_install_command} unbound" will typically get it installed.
To make unbound a private resolver for Tor, configure it to listen only to your family's Tor exits.
In [/var/unbound]/etc/unbound.conf: -------8<------- server: num-threads: 2 interface: 127.0.0.1 interface: ::1 interface: aaa.bbb.ccc.ppp # outgoing-interface: aaa.bbb.ccc.rrr access-control: 127.0.0.0/8 allow access-control: tor.ex.it.one/32 allow access-control: tor.ex.it.two/32 allow ... hide-identity: yes hide-version: yes -------8<-------
On OpenBSD, I've had unbound run out of file descriptors while doing Tor exit traffic lookups. The result is unbound logs 'too many open files' and quits/fails to restart.
The fix I chose was to boost unbound's resource limits while leaving other daemons at the defaults. Here's how.
The unbound user "_unbound" is by default in the login class "daemon" (see login.conf(5) [3]). I moved the _unbound user into login class "unbound" (i.e., used vipw, changed _unbound user's class entry from daemon to unbound). I then defined the unbound class' openfiles limits somewhat higher than the default for daemon class.
The openfiles-cur for daemon class is 512, while the openfiles-max for daemon class is left at default of 1024. I chose 5120 and 8192 for the unbound class out of an excess of caution, and not because I have yet tested limits between 512 / 1024 and those higher numbers. The failure mode suggested that unbound was hitting 512 and not attempting to raise the limit.
In /etc/login.conf: -------8<------- # Override resource limits for certain daemons that will be started by the # system but which we load heavily # change _unbound user from 'daemon' class to 'unbound' class in # master.passwd to pick up this setting unbound:\ :openfiles-cur=5120:\ :openfiles-max=8192:\ :tc=daemon: -------8<-------
In the end, Tor exits are much more effective if the DNS resolver works. The problem of unbound quitting after logging 'too many open files' hasn't reoccurred for about 2 weeks running under the new limits. I'll give it another week and declare victory.
Richard
------- [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/unbound.8
[2] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/unbound.conf.5
[3] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/login.conf.5
On Sat, Jan 10, 2015 at 10:58 PM, Richard Johnson rdump@river.com wrote:
It is especially a good idea to have your own local DNS resolver if you run Tor exits at an institution that's required to otherwise log DNS queries.
Tor needs a separate (and non-logging) DNS resolution system to prevent the institution from being presumed aware of Tor users' lookups.
That this also protects Tor users from having their DNS queries logged is good as well, but that isn't necessarily the driver for the institution. ;)
Do not presume that pointing dns locally prevents passive monitors anywhere along your network graph of clearnet hops from seeing your dns queries there. And ultimately, exit IP can be observed and correlated from the roots down with increasing difficulty. That said, yes, local is still better, and often more performant, than pointing to a privacy joke like google.
I guess another reminder doesn't hurt since Google is still the most prevalent DNS server on the tor network, accounting for ~25% of tor exit bw.
https://nymity.ch/dns-traffic-correlation/img/top-exit-resolvers.png
https://lists.torproject.org/pipermail/metrics-team/2016-February/000078.htm...
That link almost makes it seem like we shouldn't use any public DNS servers. Can you reliably run an exit server on just a local resolver? I have Unbound, OpenDNS, and Google DNS on my exit relay, and I still get "all nameservers failed."
Also, does this apply to Orbot? Because the latest update changed Orbot's VPN mode from OpenDNS to Google. On Feb 23, 2016 5:58 PM, "nusenu" nusenu@openmailbox.org wrote:
I guess another reminder doesn't hurt since Google is still the most prevalent DNS server on the tor network, accounting for ~25% of tor exit bw.
https://nymity.ch/dns-traffic-correlation/img/top-exit-resolvers.png
https://lists.torproject.org/pipermail/metrics-team/2016-February/000078.htm...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Try https://www.opennicproject.org/
On Dienstag, 23. Februar 2016, 19:16:30 Tristan wrote:
That link almost makes it seem like we shouldn't use any public DNS servers. Can you reliably run an exit server on just a local resolver? I have Unbound, OpenDNS, and Google DNS on my exit relay, and I still get "all nameservers failed."
Also, does this apply to Orbot? Because the latest update changed Orbot's VPN mode from OpenDNS to Google. On Feb 23, 2016 5:58 PM, "nusenu" nusenu@openmailbox.org wrote:
I guess another reminder doesn't hurt since Google is still the most prevalent DNS server on the tor network, accounting for ~25% of tor exit bw.
https://nymity.ch/dns-traffic-correlation/img/top-exit-resolvers.png
https://lists.torproject.org/pipermail/metrics-team/2016-February/000078.htm...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
seems kinda dumb to use those dns servers really
On Tue, Feb 23, 2016 at 6:57 PM, nusenu nusenu@openmailbox.org wrote:
I guess another reminder doesn't hurt since Google is still the most prevalent DNS server on the tor network, accounting for ~25% of tor exit bw.
https://nymity.ch/dns-traffic-correlation/img/top-exit-resolvers.png
https://lists.torproject.org/pipermail/metrics-team/2016-February/000078.htm...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
They are default for Pulse Servers.
Anyway, thanks elrippo for that link to the Open NIC Project! I've added their DNS servers to my exit relay, and I no longer see any log errors about failing nameservers! On Feb 24, 2016 9:14 PM, "Steven Jones" pressmangoss@gmail.com wrote:
seems kinda dumb to use those dns servers really
On Tue, Feb 23, 2016 at 6:57 PM, nusenu nusenu@openmailbox.org wrote:
I guess another reminder doesn't hurt since Google is still the most prevalent DNS server on the tor network, accounting for ~25% of tor exit bw.
https://nymity.ch/dns-traffic-correlation/img/top-exit-resolvers.png
https://lists.torproject.org/pipermail/metrics-team/2016-February/000078.htm...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
The OpenNIC servers may not be appropriate for use by a high-speed Tor exit relay.
I run an OpenNIC DNS server, and my VPS vendor insisted that I rate-limit the server to avoid it being used as a DDOS vector. I'm guessing that this is not an uncommon position to take for public DNS servers.
The OpenNIC servers you select for use may be perfectly fine for your level of use but don't assume it is automatically true.
On 02/24/2016 10:49 PM, Tristan wrote:
They are default for Pulse Servers.
Anyway, thanks elrippo for that link to the Open NIC Project! I've added their DNS servers to my exit relay, and I no longer see any log errors about failing nameservers!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Are you caching the DNS queries?
Am 25. Februar 2016 13:47:04 MEZ, schrieb Steve Snyder swsnyder@snydernet.net:
The OpenNIC servers may not be appropriate for use by a high-speed Tor exit relay.
I run an OpenNIC DNS server, and my VPS vendor insisted that I rate-limit the server to avoid it being used as a DDOS vector. I'm guessing that this is not an uncommon position to take for public DNS servers.
The OpenNIC servers you select for use may be perfectly fine for your level of use but don't assume it is automatically true.
On 02/24/2016 10:49 PM, Tristan wrote:
They are default for Pulse Servers.
Anyway, thanks elrippo for that link to the Open NIC Project! I've
added
their DNS servers to my exit relay, and I no longer see any log
errors
about failing nameservers!
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net
Encrypted messages are welcome. 0x84DF1F7E6AE03644
- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux)
mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL - -----END PGP PUBLIC KEY BLOCK-----
I assume you mean the name resolutions. Yes, the resolutions are cached.
The history of queries is tracked implicitly by the resolver. I've set mine to no more than 10 queries per second, so the 11th query from the same IP address to the same TLD would be rejected.
On Thursday, February 25, 2016 11:09am, "Elrippo" elrippo@elrippoisland.net said:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Are you caching the DNS queries?
Am 25. Februar 2016 13:47:04 MEZ, schrieb Steve Snyder swsnyder@snydernet.net:
The OpenNIC servers may not be appropriate for use by a high-speed Tor exit relay.
I run an OpenNIC DNS server, and my VPS vendor insisted that I rate-limit the server to avoid it being used as a DDOS vector. I'm guessing that this is not an uncommon position to take for public DNS servers.
The OpenNIC servers you select for use may be perfectly fine for your level of use but don't assume it is automatically true.
On 02/24/2016 10:49 PM, Tristan wrote:
They are default for Pulse Servers.
Anyway, thanks elrippo for that link to the Open NIC Project! I've
added
their DNS servers to my exit relay, and I no longer see any log
errors
about failing nameservers!
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net
Encrypted messages are welcome. 0x84DF1F7E6AE03644
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)
mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE----- Version: APG v1.1.1
iQJcBAEBCgBGBQJWzyc/PxxlbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0 ZWQpIDxlbHJpcHBvQGVscmlwcG9pc2xhbmQubmV0PgAKCRAkQ93r2VDR61NwEAC2 bVIngcpTcwVBXfZCLmRh0yixDBWOWmA0HLE3U0ow3s2KqPM+QhWr4qtHFcYCTvOR yWBrNXXFD6T5SwKGJdUr9NvBzz4Vw+jCC+pTHdzOaXZJ3cVp0JUudjV+jHykSptO ZAbM60mMTXrT/2fuf6i57j3mMyWiBvPmcqqlcTs+HWLz5pjSXh3FBL+3bYZbNSkf LNqYqE6Z0EpdksyCHR+k3JjtcwZqX6cdDQs+YEQdoeMhxQvadr48WAquwyLTr5RF ybzKLYeUwwknehwvZHJl5GalyYqLWZcEkqRfvH//bqjJH4cYcHEKg+HLFBevurQE tT+BMXx0neTr7HpzeHgrEpBw5REdcEwLBtQMZ5+DlJ+cflz9JiFk9/bc6SqvB1JX phxvysQtVSYoANG19tlT+k9q0uJLXZaS7JSBgtxxyuxhSQnQZHRnEkw6jUeHEWkS Y8+3o+D152L2K3U+NeDxKc2+dZsSY8vbYvIJLfHp48+F50+XbpI7kwQf6c/bGbMt PngJaHEgX4rdas2DyD0SK0gfPBe2X63J7dmE+Rq8X3+9wqx5af0Nk35YuYcGUzkF LInjxW2b3zWAnX2PeyNKxiyHP2Z32h8mAP6CRQLYDtc0HsZzqFGus2y4R+JalQXO 5DOAv36NfZ1qq1mJF5IjUNzHilaC2iYl1fpcqRQd2g== =pcgO -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
You are welcome :D
Am 25. Februar 2016 04:49:48 MEZ, schrieb Tristan supersluether@gmail.com:
They are default for Pulse Servers.
Anyway, thanks elrippo for that link to the Open NIC Project! I've added their DNS servers to my exit relay, and I no longer see any log errors about failing nameservers! On Feb 24, 2016 9:14 PM, "Steven Jones" pressmangoss@gmail.com wrote:
seems kinda dumb to use those dns servers really
On Tue, Feb 23, 2016 at 6:57 PM, nusenu nusenu@openmailbox.org
wrote:
I guess another reminder doesn't hurt since Google is still the most prevalent DNS server on the tor network, accounting for ~25% of tor exit bw.
https://nymity.ch/dns-traffic-correlation/img/top-exit-resolvers.png
https://lists.torproject.org/pipermail/metrics-team/2016-February/000078.htm...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net
Encrypted messages are welcome. 0x84DF1F7E6AE03644
- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux)
mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL - -----END PGP PUBLIC KEY BLOCK-----
Hi there to all! Some time ago, in some meetings with our "collective" folks, we started to implement OpenNIC based local DNS resolvers to be used by every TOR / CJDNS host we manage!
Not a good "policy" to use DNS services from "PRISM cousins"... Props to all the TOR Community!
undertuga InfoSec R&D / Consultant
-------- Original Message -------- Subject: Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers Local Time: February 25, 2016 3:14 am UTC Time: February 25, 2016 3:14 AM From: pressmangoss@gmail.com To: tor-relays@lists.torproject.org
seems kinda dumb to use those dns servers really
On Tue, Feb 23, 2016 at 6:57 PM, nusenu nusenu@openmailbox.org wrote:
I guess another reminder doesn't hurt since Google is still the most prevalent DNS server on the tor network, accounting for ~25% of tor exit bw.
https://nymity.ch/dns-traffic-correlation/img/top-exit-resolvers.png
https://lists.torproject.org/pipermail/metrics-team/2016-February/000078.htm...
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Andreas Krey -
cacahuatl -
Dave Warren -
Drake Wilson -
elrippo -
Elrippo
-
eric gisse -
grarpamp -
Larry Brandt -
Libertas -
Nick Mathewson -
Nusenu -
nusenu -
Paul Syverson -
Peter Palfrader -
Richard Johnson -
Seth -
Steve Snyder -
Steven Jones -
Teófilo Couto -
Toralf Förster -
Tristan -
Zack Weinberg