On Tue, Dec 18, 2012 at 7:34 PM, Mike Perry mikeperry@torproject.org wrote:
Thus spake Nick Mathewson (nickm@freehaven.net):
[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
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?
Nick asked me this in private email:
Every socks response has an IP address in it. So when Firefox asks for "www.mit.edu" in a SOCKS4a or a SOCKS5 request, Tor gives it "18.9.22.169" in the SOCKS response.
Does Firefox cache these values? That is, in the next SOCKS request that Firefox makes for "www.mit.edu", will Firefox ask Tor to connect to "www.mit.edu", or to "18.9.22.169"?
Under normal non-SOCKS operation, Firefox does attempt to cache DNS resolutions for a long period of time (I think on the order of an hour or more). The reason is because of DNS-based subversions of the same-origin policy: https://en.wikipedia.org/wiki/DNS_rebinding http://www.securityfocus.com/columnists/455
Importantly, I was wrong above. Tor does not actually provide DNS results in response to SOCKS connect requests; only in response to deliberate hostname lookups.
Interestingly, the two main vectors discussed there are not as useful against Tor, but perhaps worth having on your radar when considering DNS cache alterations.
Further, the SOCKS behavior for Firefox is quite different than non-proxied use, perhaps because of the limited vectors for rebinding. It tends to make very few actual SOCKS4a resolutions, instead perferring to use direct SOCKS4A hostname connects. Unfortunately, the details of where and why it actually does decide to do a SOCKS4a resolution are unknown to me and would require some digging.
This might be a little confused. There is no such thing as a standard SOCKS resolution: the ability to do a hostname lookup in SOCKS without doing a connection is a Tor extension.