Disable client-side DNS cacheing by default

Proposal 205 discusses a proposal for making per-circuit DNS caches, but closes by suggesting that instead, client-side DNS cacheing simply be disabled.

This is necessary for avoiding some nasty linkability enabled by IPv6, and is probably a good idea for IPv4 users too.

Rather than just turn it off, I've written a branch to make it a set of per-client-port options, in case there's some really important reason it's needed.

changed milestone to %Tor: 0.2.4.x-final

added component::core tor/tor dns milestone::Tor: 0.2.4.x-final priority::high prop205 resolution::implemented status::closed tor-client type::enhancement labels

Please review branch prop205-simplified in my public repository.

Trac:
Status: new to needs_review

Updated based on comment by arma on tor-dev:we shouldn't use the addressmap cache to change the address of a connection that's failed because of END_REASON_EXITPOLICY.

#7571 (moved) now lacks the new commit on this branch; we must be sure to merge both branches, not just the branch listed in #7571 (moved).

This code all looks fine to me; go ahead and merge if you want. I'm not sure I entirely understand why this linkability problem becomes worse with IPv6, though, so for my own enlightenment it'd be nice to hear about it at some point.

Two tiny nitpicks:

• make check-spaces says 'UnnecNL:src/or/relay.c:760'

• The sentence "It's potentially risky to use cached DNS answers at the client can be risky for linkability, since doing so can indicate to one exit what answers we've gotten for DNS lookups in the past." in the changes file in commit 765606406b26d573242e1a1d759511751b279b21 should be taken out, shot and replaced with something that conforms with English grammar, or at least the Newspeak Dictionary, 9th Edition. :)

Replying to andrea:

This code all looks fine to me; go ahead and merge if you want. I'm not sure I entirely understand why this linkability problem becomes worse with IPv6, though, so for my own enlightenment it'd be nice to hear about it at some point.

The issue was that with IPv4, it takes effort and resources to mount the "give everyone a different answer" attack: if you want to transparently divide (say) www.zombo.com users into N classes, you'd need N IPs, and you'd need to make every one of them give a reasonable facsimile of www.zombo.com when accessed from a wide variety of exit nodes. Big ISPs and MIT dorm residents and others who can grab ridiculous numbers of IP addresses could do this without too much trouble (until they get caught), but for other folks, you'd need to pay botnet rates for your addresses and/or find a clever algorithm to minimize the number of classes you're dividing users into.

But with IPv6, everybody basically gets as many addresses as they want, and it's easy to have them all route to the same interface. The "give everybody a different answer" attack is no longer (somewhat) costly: it's basically free to get a /64 or a /80 and have it all route to you.

Two tiny nitpicks:

• make check-spaces says 'UnnecNL:src/or/relay.c:760'

fixed in branch

• The sentence "It's potentially risky to use cached DNS answers at the client can be risky for linkability, since doing so can indicate to one exit what answers we've gotten for DNS lookups in the past." in the changes file in commit 765606406b26d573242e1a1d759511751b279b21 should be taken out, shot and replaced with something that conforms with English grammar, or at least the Newspeak Dictionary, 9th Edition. :)

nickm nickm sad nickm english sad kitten banana!

(fixed in branch)

There's now a combined "ticket7570_7571" branch that has a squashed and rebased version of this code plus the code in #7571 (moved). I'm going to merge that if there are no objections.

Merged into master.

Trac:
Status: needs_review to closed
Resolution: N/A to implemented

closed

mentioned in issue #7571 (moved)

mentioned in issue #8596 (moved)

mentioned in issue #24050 (moved)

moved to tpo/core/tor#7570 (closed)

mentioned in issue tpo/core/tor#8596 (closed)

mentioned in issue tpo/core/tor#24050 (closed)