Re: [tor-dev] Proposal 205: Remove global client-side DNS caching

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

[tl;dr: We should make client-side DNS cacheing off by default.]


On Fri, Jul 20, 2012 at 6:27 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> 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,
-- 
Nick Mathewson
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev