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

[Richard Johnson]

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