[tor-relays] Is there any problems for users of my exit node if I have DNS lookups go out on a different interface?

[teor]

> On 29 Apr 2017, at 01:43, Anders Andersson <pipatron at gmail.com> wrote:
> 
> I plan to set up a Tor exit node (again), and the server has two
> external interfaces each with a dedicated IP. I'm going to use one of
> these exclusively for Tor.
> 
> I also run a validating Unbound on the same machine, and all DNS
> lookups that are not cached will go out on the *other* interface by
> default.
> 
> internet <--> IP 1 <--> unbound
> internet <--> IP 2 <--> tor, talking locally to unbound
> 
> IP 1 and 2 should have the same routing path otherwise, because it's
> on the same network.
> 
> I can't imagine how this could be problematic, but there has been so
> much talk about DNS lookups over the years, so I thought I'd better
> check with people who know more about this.

I have a similar setup on my Exit, and it works well.
(There's also no reason why it shouldn't work.)

Just checking that you're using 127.0.0.1 or ::1 for tor to talk to
unbound? It might not be a good idea to allow others to use your
resolver, because they can check which sites are being looked up from
the response time.

Also, you might want to read the tor man page entries for these
options:

The IP addresses your relay will advertise
(tell others to connect on):
Address (IPv4)
ORPort (IPv6)

The IP addresses your relay will listen on:
ORPort
DirPort

The IP addresses your relay will make outbound connections on:
OutboundBindAddressOR
OutboundBindAddressExit

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20170501/6c3d93d8/attachment.sig>