techstdout/ TorDns

TorDns

  1. Introduction
  2. Forwarding nameservers
    1. Tor DNS forwarder
    2. Various DNS forwarders
  3. Transparency
    1. Firestarter
    2. UFW
    3. Testing
  4. Usability
    1. Caching
  5. Integration
    1. Without resolvconf
    2. With resolvconf

Table of contents :

Introduction

As explained in the Tor FAQ, it is quite hard to guarantee that a particular piece of software, configured to use Tor, will not leak information about the domain names it connects to.

How usable are the solutions to (possibly forcibly) forward any outgoing DNS request through Tor ?

NB : most of the following has been tested on Debian testing/lenny (2008 04).

Forwarding nameservers

In our usecase, a forwarding nameserver (also called DNS proxy or DNS forwarder) can be setup as the default DNS server (either for a given box or for the whole local network). Its purpose is to forward through Tor the outgoing DNS requests.

Tor DNS forwarder

Tor 0.2.x series provide a built-in DNS forwarder, but it is still not released as a stable version, and is thus packaged for Debian in experimental ; nevertheless, the Tor project folks provide up-to-date Debian packages for etch, lenny and sid, as well as a bunch of Ubuntu versions.

Example configuration settings for /etc/tor/torrc :

DNSPort 9053
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

Test it is basically working : dig @localhost -p 9053 debian.org

FIXME (0.2.23-rc) :

  • this DNS forwarder only seems able to resolve DNS queries for A-records ; neither MX nor NS queries are ever answered

Various DNS forwarders

Solutions also exist for users of Tor 0.1.x, ; the SupportPrograms page on the Tor wiki lists various forwarding nameservers, designed to be setup as a local DNS server, whose purpose is to proxy DNS requests through Tor :

Transparency

There might be DNS leaks due to incorrect socks proxy configuration, or some pieces of software attempting to do their own DNS resolution without using the default nameserver.

You might therefore want to force any outgoing DNS query to be proxied via Tor ; there are low-level instructions to implement such a solution, on the firewall / gateway level on the TransparentProxy page on the Tor wiki.

Bellow are instructions to implement this using (non-tech-savvy-)user-friendly firewall tools.

Firestarter

Add the following snipplet of code to /etc/firestarter/user-pre :

TOR_DNS=enabled
TOR_USER='debian-tor'
TOR_UID="`getent passwd $TOR_USER | awk -F: '{print $3}'`"

if [ "$TOR_DNS" = enabled -a -n "$TOR_UID" ]; then
        # Let the Tor-generated packets go
        $IPT -t nat -A OUTPUT -o $IF -m owner --uid-owner $TOR_UID -j RETURN
        # Let the packets to non-routables (i.e. local) networks go
        while read block garbage
        do
                $IPT -t nat -A OUTPUT -o $IF -d $block -j RETURN
        done < /etc/firestarter/non-routables
        # Redirect to the local (torified) nameserver any DNS connection left
        $IPT -t nat -A OUTPUT -o $IF -p tcp --dport 53 -j REDIRECT --to-ports 53
        $IPT -t nat -A OUTPUT -o $IF -p udp --dport 53 -j REDIRECT --to-ports 53
else
        echo Warning: DNS forwarding through Tor is disabled.
fi

Then run sudo /etc/init.d/firestarter restart.

UFW

The Ubuntu Firewall is part of the default Ubuntu install, starting with the hardy release. See the related pages on the Ubuntu wiki and on Launchpad.

FIXME

Testing

To test if it works as expected, you can try to query a remote nameserver for DNS information that is not supported by the Tor DNS forwarder ; for example :

dig no-log.org MX @karl.globenet.org

  • If such a query gets no answer, then the so-called "transparent" redirect is working :)
  • If it gets an answer, maybe the redirect does not work as expected, maybe you're running a newer Tor version that now supports a greater subset of the DNS queries, maybe [...], in any case, you have to investigate

Usability

Torifying every DNS request may have an annoying impact on your Internet activity, adding latency in places you are not used to experience it. There are solutions known to help a lot.

Caching

NB : Tor 0.2.x DNS forwarder seems to implement some kind of caching on its own, which helps a lot.

Else :

  1. Setup one of the above listed forwarding nameservers and configure it to forward through Tor the DNS queries it receives.
  2. Setup a local caching nameserver, and configure it to forward the DNS queries it receives to the forwarding nameserver previously installed.
  3. Setup this caching nameserver as the default nameserver, either for a given box, or for the whole local network.

For example, the Incognito live CD uses pdnsd to provide caching, and dns-proxy-tor as a forwarding nameserver. Its developpers have documented their configuration ; see also their pdnsd.conf file.

DJB's dnscache is another valuable solution ; it defaults to do the full (recursive) name resolution itself, but it can also be setup as a simple forwarding cache, following these instructions. dnscache makes it really easy to use different nameservers for different domains, which provides us with a way to fine-tune which DNS queries should be torrified, and which ones should not.

Integration

Without resolvconf

Goal : static /etc/resolv.conf

The first step is to replace everything in /etc/resolv.conf with nameserver 127.0.0.1, and run on UDP port 53 any kind of Tor DNS forwarder (e.g. with DNSPort 53).

But the next time you'll plug in your network cable, dhclient will probably want to update /etc/resolv.conf with information provided by the DHCP servers.

To prevent this, if /etc lives on an ext3 FS, one could think of setting the immutable attribute on /etc/resolv.conf : chattr +i /etc/resolv.conf ; this is a bit ugly, and triggers errors on dhclient startup...

There are nicer ways to prevent dhclient to modify our beloved resolv.conf file, by editing its /etc/dhcp3/dhclient.conf configuration file :

  • Either remove domain-name, domain-name-servers, and domain-search from the request directive : dhclient will thus simply not ask the DHCP server for such information.
  • Or leave the request directive as it is, and add :
    • supersede domain-name-servers 127.0.0.1;
    • supersede domain-name "localdomain";

With resolvconf

Resolvconf uses hooks scripts in /etc/network/if-{up,down}.d/ to update its dns information. If you are using dhcp, simply remove domain-name, domain-name-servers, and domain-search from the request directive in /etc/dhcp3/dhclient.conf should take care that resolvconf don't modify your /etc/resolv.conf information.

Another way would be to use the /etc/resolvconf/interface-order, which is used to control the order in which resolvconf nameserver information records are processed by those resolvconf update scripts that consult this file. Putting loopback first in this file should tell resolvconf to use your torified dns cache in first place before any other. see man interface-order for more informations.

TESTME