On Sat, Jun 23, 2007 at 01:08:33PM +0100, Robert Hogan wrote: > On Friday 22 June 2007 16:52:48 Nick Mathewson wrote: > > On Thu, Jun 21, 2007 at 10:53:08PM +0100, Robert Hogan wrote: > > > This would also prevent the user resolving a dns request if it > > > coincided exactly with the very same request by tor. I don't know > > > how likely this would be in practice - I certainly haven't been > > > quick enough on the draw. > > > > I think this is actually a dangerous idea. We separate the client DNS > > cache from the server DNS cache for a reason: if you're using a Tor > > instance as both a client and a server, it's a good idea to keep the > > client's behavior more or less uncorrelated by the server's. > > > > Sorry, I don't get it! Ah, I misunderstood the purpose of the patch. I thought it was to save time on DNS resolves, not to check for DNSPort loops. I get it now. :) > I don't think any mixing of the caches takes place here. The patch > prevents a Tor server from resolving DNS requests when a broken > system configuration routes them all back to its own DNSPort. In > this situation the tor server will always be unable to resolve > anything and the server admin will be warned accordingly. > > If the same Tor instance is being used as a client then the only > occasion in which an application's requests (e.g. from firefox) will > fail is if it happens to request the exact same dns resolve at > precisely the same moment the server's same dns request is in > progress. Otherwise its requests, even for the same hostname, will > be successfully routed over the tor network. > > I don't believe a failure of the client request in the above > situation will result in a cache hit (server or client), the request > will just fail and the app will try again or give up. Hmmm. I really _don't_ like the idea of making good client DNS break _ever_, even if it's hard to provoke on your machine. After all, if users see this in practice, it's not likely that they'll even know to report it as a bug, since it would be intermittent and hard to prove. Could it be simpler just to add a function to eventdns.c to make sure none of the nameservers are going to the addr:port of our dnsport? yrs, -- Nick Mathewson
Attachment:
pgprRlV9wWTwN.pgp
Description: PGP signature