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

[Nick Mathewson]

On Tue, Dec 18, 2012 at 7:34 PM, Mike Perry <mikeperry at torproject.org> wrote:
> Thus spake Nick Mathewson (nickm at 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 at 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.

-- 
Nick