prevent tor accepting dns requests on dnsport initiated by itself

[Nick Mathewson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070627/232bb2d2/attachment.pgp>