commit 610f21f2f6c4efda748d95c37234c63344b3037f Author: Nick Mathewson nickm@torproject.org Date: Fri Jul 20 16:26:56 2012 -0400
Add proposal 205: Remove global client-side DNS caching --- proposals/205-local-dnscache.txt | 146 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/proposals/205-local-dnscache.txt b/proposals/205-local-dnscache.txt new file mode 100644 index 0000000..c0e19e5 --- /dev/null +++ b/proposals/205-local-dnscache.txt @@ -0,0 +1,146 @@ +Filename: 205-local-dnscache.txt +Title: Remove global client-side DNS caching +Author: Nick Mathewson +Created: 20 July 2012 +Status: Open + + +0. Overview + + This proposal suggests that, for reasons of security, we move + client-side DNS caching from a global cache to a set of per-circuit + caches. + + This will break some things that used to work. I'll explain how to + fix them. + +1. Background and Motivation + + Since the earliest Tor releases, we've kept a client-side DNS + cache. This lets us implement exit policies and exit enclaves -- + if we remember that www.mit.edu is 18.9.22.169 the first time we + see it, then we can avoid making future requests for www.mit.edu + via any node that blocks net 18. Also, if there happened to be a + Tor node at 18.9.22.169, we could use that node as an exit enclave. + + But there are security issues with DNS caches. A malicious exit + node or DNS server can lie. And unlike other traffic, where the + effect of a lie is confined to the request in question, a malicious + exit node can affect the behavior of future circuits when it gives + a false DNS reply. This false reply could be used to keep a client + connecting to an MITM'd target, or to make a client use a chosen + node as an exit enclave for that node, or so on. + + With IPv6, tracking attacks will become even more possible: A + hostile exit node can give every client a different IPv6 address + for every hostname they want to resolve, such that every one of + those addresses is under the attacker's control. + + And even if the exit node is honest, having a cached DNS result can + cause Tor clients to build their future circuits distinguishably: + the exit on any subsequent circuit can tell whether the client knew + the IP for the address yet or not. + + So client-side DNS caching needs to go away. + +2. Design + +2.1. The basic idea + + I propose that clients should cache DNS results in per-circuit DNS + caches, not in the global address map. + +2.2. What about exit policies? + + Microdescriptor-based clients have already dropped the ability to + track which nodes declare which exit policies, without much ill + effect. As we go forward, I think that remembering the IP address + of each request so that we can match it to exit policies will even + less effective, especially if proposals to allow AS-based exit + policies can succeed. + +2.3. What about exit enclaves? + + Exit enclaves are already borken. They need to move towards a + cross-certification solution where a node advertises that it can + exit to a hostname or domain X.Y.Z, and a signed record at X.Y.Z + advertises that . That's out-of-scope for this proposal, except to + note that nothing proposed here keeps that design from working. + +2.4. What about address mapping? + + Our current address map algorithm is, more or less: + + N = 0 + while N < MAX_MAPPING && exists map[address]: + address = map[address] + N = N + 1 + if N == MAX_MAPPING: + Give up, it's a loop. + + Where 'map' is the union of all mapping entries derived from the + controller, the configuration file, trackhostexits maps, + virtual-address mps, DNS replies, and so on. + + With this design, the DNS cache will not be part of the address + map. That means that entries in the address map which relied on + happening after the DNS cache entries can no longer work so well. + These would include: + + A) Mappings from an IP address to a particular exit, either + manually declared or inserted by TrackHostExits. + B) Mappings from IP addresses to other IP addresses. + C) Mappings from IP addresses to hostnames. + + We can try to solve these by introducing an extra step of address + mapping after the DNS cache is applied. In other words, we should + apply the address map, then see if we can attach to a circuit. If + we can, we try to apply that circuit's dns cache, then apply the + address map again. + + +2.5. What about the performance impact? + + That all depends on application behavior. + + If the application continues to make all of its requests with the + hostname, there shouldn't be much trouble. Exit-side DNS caches and + exit-side DNS will avoid any additional round trips across the Tor + network; compared to that, the time to do a DNS resolution at the + exit node *should* be small. + + That said, this will hurt performance a little in the case where + the exit node and its resolver don't have the answer cached, and it + takes a long time to resolve the hostname. + + + If the application is doing "resolve, then connect to an IP", see + 2.6 below. + +2.6. What about DNSPort? + + If the application is doing its own DNS caching, they won't get + much security benefit from here. + + If the application is doing a resolve before each connect, there + will be a performance hit when the resolver is using a circuit that + hadn't previously resolved the address. + + Also, DNSPort users: AutomapHostsOnResolve is your friend. + +3. Alternate designs and future directions + +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. + +3.2. The impact of DNSSec + + Once we get DNSSec support, clients will be able to verify whether + an exit's answers are correctly signed or not. When that happens, + we could get most of the benefits of global DNS caching back, + without most of the security issues, if we restrict it to + DNSSec-signed answers. +