[tor-dev] Dealing with DNS requests by Tor unaware programs

teor teor2345 at gmail.com
Sun Jun 24 23:36:03 UTC 2018

> On 25 Jun 2018, at 02:41, procmem <procmem at riseup.net> wrote:
> Hello. We are trying to safely deal with programs that don't support Tor
> DNS stream isolation so they don't pollute TransPort.

We don't recommend TransPort for this reason. (See below.)

> I've read the manual but it's not clear if you enable
> IsolateClientProtocol by default. Is that the case?

No, but you're probably looking for *Port isolation instead,
which is documented as on by default under SessionGroup:

By default, streams received on different SocksPorts,
TransPorts, etc are always isolated from one another.
This option overrides that behavior.

The other default isolation flags are documented in the man
IsolateClientAddr and IsolateSOCKSAuth
There are also some internal flags that are always on:

All the isolation flags that aren't named as defaults are not defaults.

> Also if the former is enabled, do you have IsolateDest enabled for
> DnsPort or not? If no then what is the rationale for this decision?

I don't think IsolateDest makes sense for DNSPort. Building a
separate circuit for each DNS request is slow (for clients) and
expensive (for the network).

And regardless of isolation, resolving DNS addresses at a
different exit to the one that connects can cause privacy issues,
and it can result in slower connections.

So we recommend SOCKSPort or HTTPTunnelPort instead, because
they support sending DNS names to exits as part of the connection

Here are a few general reasons for the defaults:
* many applications expect to have a single source IP address
  for all their connections, and
* building a circuit for each destination is expensive, but
* isolating different users is important, so we automatically
  isolate different source IP addresses, and automatically isolate
  applications which have different socks usernames or passwords
  (users or developers should configure each application with a
  random socks username and password)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180625/478697ea/attachment.html>

More information about the tor-dev mailing list