[tl;dr: We should make client-side DNS cacheing off by default.]
On Fri, Jul 20, 2012 at 6:27 PM, Nick Mathewson nickm@freehaven.net wrote:
Filename: 205-local-dnscache.txt Title: Remove global client-side DNS caching Author: Nick Mathewson Created: 20 July 2012 Status: Open
[...] For the original proposal, see https://lists.torproject.org/pipermail/tor-dev/2012-July/003817.html
3.1. Why keep client-side DNS caching at all?
A fine question! I am not sure it actually buys us anything any longer, since exits also have DNS caching. Shall we discuss that? It would sure simplify matters.
On consideration, I'm actually reasonably sure that eliminating client-side DNS cacheing (or at least, turning it off by default) is a much better answer than making DNS caches per-circuit. I've got an implementation of my new approach on ticket #7570 (https://trac.torproject.org/projects/tor/ticket/7570).
So, why is it okay to disable client-side DNS cacheing entirely?
Applications that care about speed should be doing a one-round-trip connect mechanism: either a SOCKS request with a hostname in it, or a TransPort request to an automapped address. If client-side DNS cacheing is disabled, these behaviors result in Tor sending the exit node a RELAY_BEGIN cell with a hostname in it. If the exit node is has received a request for that hostname recently, it will have the answer in its DNS cache, and the use of the hostname won't slow the request down. If the exit node has _not_ received a request for that hostname recently, there will be no answer in its cache... but neither would there be any answer in a per-circuit DNS cache for a circuit to that exit.
Applications that do a two-step "resolve then connect" approach will be a little slowed down in cases where Tor would have kept the answer in the client cache. But they would already be slowed down somewhat by proposal 205, which can't be avoided if we want proposal 205's improved security. See note on automapping below for a workaround.
(And if you're asking, "Why would I even want to disable client-side DNS cacheing?", see proposal 205, linked above.)
Incidentally, elsewhere in the proposal I said,
If the application is doing its own DNS caching, they won't get much security benefit from here.
It looks like a bunch of applications *do* DNS cacheing. For them, in 0.2.4, I'd suggest maybe running Tor in a configuration where every name lookup gets automapped to a random IPv6 address. That kind of automapping should be possible in Tor 0.2.4 , if the changes in ticket #7571 are right and get merged.
Another note that I had forgotten: Applications that do their own DNS cacheing won't get affected by proposal 205, or by disabling client-side DNS cacheing, unless they use Tor's DNSPort or Tor's "SOCKS RESOLVE" extension to do name lookups. That's because (I think!) our SOCKS replies don't include IP addresses; If I'm reading this code right, they just set the address to 0.0.0.0, which applications should interpret as "Tor isn't going to tell you what the IP is".
yrs,