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