Opened 7 years ago

Closed 7 years ago

#7570 closed enhancement (implemented)

Disable client-side DNS cacheing by default

Reported by: nickm Owned by:
Priority: High Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client dns prop205
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (6)

comment:1 Changed 7 years ago by nickm

Status: newneeds_review

Please review branch prop205-simplified in my public repository.

comment:2 Changed 7 years ago by nickm

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 now lacks the new commit on this branch; we must be sure to merge both branches, not just the branch listed in #7571.

comment:3 Changed 7 years ago by 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.

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. :)

comment:4 in reply to:  3 Changed 7 years ago by nickm

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)

comment:5 Changed 7 years ago by nickm

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

comment:6 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged into master.

Note: See TracTickets for help on using tickets.