On Sun, Nov 25, 2012 at 7:54 PM, Nick Mathewson <span dir="ltr"><<a href="mailto:nickm@freehaven.net" target="_blank">nickm@freehaven.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[tl;dr: We should make client-side DNS cacheing off by default.]<br></blockquote><div><br></div><div>Nitpickery: s/cacheing/caching/g</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Applications that care about speed should be doing a one-round-trip<br>
connect mechanism: either a SOCKS request with a hostname in it, or a<br>
TransPort request to an automapped address.  If client-side DNS<br>
cacheing is disabled, these behaviors result in Tor sending the exit<br>
node a RELAY_BEGIN cell with a hostname in it.  If the exit node is<br>
has received a request for that hostname recently, it will have the<br>
answer in its DNS cache, and the use of the hostname won't slow the<br>
request down.  If the exit node has _not_ received a request for that<br>
hostname recently, there will be no answer in its cache... but neither<br>
would there be any answer in a per-circuit DNS cache for a circuit to<br>
that exit.<br>
<br>
Applications that do a two-step "resolve then connect" approach will<br>
be a little slowed down in cases where Tor would have kept the answer<br>
in the client cache.  But they would already be slowed down somewhat<br>
by proposal 205, which can't be avoided if we want proposal 205's<br>
improved security.  See note on automapping below for a workaround.<br>
<br>
(And if you're asking, "Why would I even want to disable client-side<br>
DNS cacheing?", see proposal 205, linked above.)<br></blockquote><div><br></div><div>FWIW this makes sense to me from a DNS point of view, and I agree that the one-trip case should be no worse under this proposal than it was previously.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Incidentally, elsewhere in the proposal I said,<br>
<br>
>   If the application is doing its own DNS caching, they won't get<br>
>  much security benefit from here.<br>
<br>
It looks like a bunch of applications *do* DNS cacheing.  For them, in<br>
0.2.4, I'd suggest maybe running Tor in a configuration where every<br>
name lookup gets automapped to a random IPv6 address.  That kind of<br>
automapping should be possible in Tor 0.2.4 , if the changes in ticket<br>
#7571 are right and get merged.<br></blockquote><div><br></div><div>Alas, yes, and browsers (I'm looking at you, Firefox) are some of the worst offenders (though hopefully not in the "normal" Tor case of SOCKS).  I have issued many curses towards applications doing their own caching (often ignoring TTLs too, of course).  The automapping in question seems sane to me.</div>
<div><br></div><div>Tim</div></div>
</div>