Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Ralph Seichter <m16+tor@xxxxxxxxxxxxxxx>]

On 08.10.17 18:34, Igor Mitrofanov wrote:

> Unless configured otherwise, Dnsmasq chooses a server from the list
> randomly, so the more servers the operator specifies in dnsmasq.conf,
> the less traffic each server gets.

The "proper" way, meaning the way resulting in the smallest surface for
behavioural analysis of the node outside the ISP hosting the node, is to
not manually configure any upstream servers at all for the caching
resolver running on the Tor node. That way, only upstream servers that
are actually required to resolve individual queries are contacted.

If the ISP hosting the Tor node has resolvers for their customers, these
can be used as well, since the ISP sees all outgoing traffic anyway, but
I can't think of any reason to use third-party resolvers (especially the
infamous Google 8.8.x.x) beyond the hosting ISP.

The historic notion of "don't contact upstream resolvers directly" from
a time where traffic was expensive is no longer valid, especially for a
Tor node where the key goal is to make it harder for third party actors
to analyse what the node is doing.

> I have not seen any research papers that would indicate that the cost
> of running a full DNS server on an Exit relay is worthwhile and that
> it improves anonymity substantially more compared to a lightweight
> cache resolver.

I don't know what you call "a full DNS server"? A caching resolver
should, by its nature, contact all upstream nameservers as required,
including the root zone servers. There is no need for Unbound, BIND or
similar resolver software to delegate queries only to a manually
configured and therefore limited list of nameservers. Just let these
resolvers do their job. From what I see on my nodes, the cost of Unbound
is negligible, compared to what Tor itself requires.

Unless you can produce research papers that show it is *not* worth
letting my resolvers contact upstream nameservers as they consider
necessary, I'll stick to advocating what I wrote above. ;-)

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