[tl;dr: We should make client-side DNS cacheing off by default.]
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.
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev