[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers



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

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays