On 9/1/05, ADB <firefox-gen@xxxxxxxxxx> wrote:
If my exit node was still at home and not here behind this university
firewall, then I'd be all over it ;) In leiu of that, I have an
idea/question. As far as I know, Tor doesn't do any kind of DNS name
caching when operating as an exit-node. What do you think of crypted,
in-RAM DNS look-up caching? The utility of this feature would be
twofold. First, there would be slightly better performance. Secondly,
and more importantly, you'd have less DNS look-ups over time, meaning
that it would be just that much harder for an exit-node sniffer to get
ideas about usage patterns. This might also have the added bonus of
relying on the OS's native DNS cache as much, which is assumed to be
insecure cleartext.
Tor has DNS caching built in, which is currently bad because it's over
caching. It's not encrypted either.
1) Encrypting the DNS cache is probably overkill. The only case where
it's of benefit is where you extract cache pages from the swap and
keep the key in non-paged memory. If you can root a running box you
can take the key from memory as easily as getting the DNS cache.
So the solution is to encrypt your swap with a boot-time nonce.
Sniffing at the ISP is an easier way to find out what is exiting at
any given node anyway, will get you more information and Tor shouldn't
depend on knowledge of exit traffic being secret. (although every
little bit of information helps the attacker)
2) The DNS system was designed with full DNS servers sitting very
close to the resolver. That's why the resolvers don't do caching.
Unfortunately there's a habit of configuring DNS servers which are
tens of milliseconds away (e.g. at the ISP) these days. Windows boxes
don't have a local DNS server, which is a bad move by MS, but UNIX
boxes have no excuse[1].
So, in the case of UNIX systems Tor maybe shouldn't be doing caching
at all. In the cases where it does make sense, the resolver doesn't
pass on the time to live of the information so Tor cannot know how
long to cache for. At the moment it's up to 150 minutes[2], which can
be very bad for highly dynamic routing setups like google.com (which
has a TTL of 5 minutes)
Eventdns (my patch) does pass on the TTL of the replies so Tor can do
sensible caching. Unfortunately, the way the data structures are laid
out means that it's difficult to do and I didn't want to drop a whole
new heap implementation into the Tor code on the first patch.
[1] http://cr.yp.to/djbdns/run-cache.html
[2] src/or/or.h:181
AGL