[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Is this a Tor exit node connecting to me?

On Sun, Mar 25, 2007 at 06:00:18PM -0700, Joseph B. Kowalski wrote:
> On Sun, 25 Mar 2007 12:22:12 -0700 Matt Ghali <matt@xxxxxxxxx> 
> > Please consider returning a different A record for the first
> > query type to allow differentiation between exit nodes and
> > middlemen. Returning for exit nodes and
> > for middleman nodes will allow sendmail dnsbl configurations
> > to easily do the 'right' thing.
> Differentiation between exit nodes and middlemen is exactly what
> the first query type is NOT designed to do, and exactly what the
> second query type IS designed to do since, as the Tor volunteer
> page I quoted in my original post states "...being an exit server
> is not a boolean..."

Hi Joe,

Great stuff. Thanks for setting it up!

I am beginning to wonder if the first query type should be there at
all though. After all, part of the motivation for running a "better"
dnsbl is that we had problems with sites setting up lists of Tor servers,
glossing over the details of what is an exit server and what that means,
and then encouraging everybody to use their list for whatever purpose they
like. Services have been trained to look for "a list of IP addresses", not
"a list of IP addresses relative to my service". I predict a lot of people
will use your list in the same way as they've used every other dnsbl --
and even more so once we point at it and say "that's the official dnsbl
you should use."

If a user wants to see whether a given IP address happens to be running
a Tor server, and doesn't care about exit policy, then I am fine sending
him to a web page to look it up manually. Making it easy to automate is
just encouraging the wrong assumptions.

> As a matter of fact, there really is not much reason to have the
> first query type at all, I mainly just did it cause I thought it
> would be a neat feature.


Matt, can you let us know if setting up sendmail with the
relative-to-your-IP-address approach is just as easy? Are there common
situations where it would make things harder?

And while I'm asking, we could imagine setting up a dnsbl that looks
at what IP address is asking the question, and answers relative to that
address. Thus people in Matt's situation could just plug it in, and it
would internally do what we all mean. I can see some downsides though --
if the client querying the dnsbl is on a very different address than
the service, or if proxying dns queries (or passing recursive queries)
is commonplace. I suspect a few 'no, that wouldn't work' responses should
be sufficient to discard this paragraph. :)