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

Re: BadExit flag still needed for PrivacyNow...

     On Sat, 17 Apr 2010 21:54:16 -0400 Andrew Lewman <andrew@xxxxxxxxxxxxxx>
>On 04/16/2010 12:59 AM, Scott Bennett wrote:
>>      My weather satellite images got blocked again, due to the PrivacyNow
>> exit using OpenDNS with a misconfigured account and the fact that
>> ExcludeExitNodes still doesn't work reliably.  Will the the authority
>> operators *please* stick a BadExit flag onto that router's entry in the
>> consensus?  Thanks!
>I think it's time for a baddns attribute, rather than solely bad exit.
>The nxdomain test is fairly binary, either your local nameserver is
>lying to you or not.

     No objection occurs to me on first reading.  Give it shot, and see
whether it stops this recurrent problem, which has been griped about on
this list by people encountering many instances of it at different exits.
Of course, there is the inertial resistance to changes to the directory
and consensus specifications, but I doubt most of us have much influence
on the development in such cases.
     In the meantime, however, WE *STILL* NEED A BadExit FLAG FOR PrivacyNow.
*PLEASE* *DO* *IT*, and stop stalling!  Unless your point in not doing so
is that you don't want us to report bad exit behavior so that it can be
prevented from messing up the validity of clients' circuit route selections.
It is a very high throughput exit node, so it gets to censor *many* streams.
>I may be misunderstanding the "using opendns with a misconfigured
>account" statement.
     Probably not.  The OpenDNS servers, AFAIK, require a free account 
be established before they will answer queries about domains other than
OpenDNS's own domain(s).  That can be accomplished via their web site,
which also allows the account holder to select various options, one of
which determines whether the account holder wishes to have queries about
certain domains be hijacked by OpenDNS in accordance with some list
OpenDNS maintains.  OpenDNS defaults to the censorship option, so an
account holder has to make the effort of turning the censorship off.
(Apparently, A RR queries for the ghcc.msfc.nasa.gov. domain are hijacked
in that way.)  The account holder can turn off all hijacking, supposedly,
to get the same response they would get from a fully honest name server.
tor exit operators are obligated to use name servers that give true
answers, so an exit that is querying an OpenDNS name server and that has
the highjacking "feature"--again, a Micro$lop usage of the word--enabled
is therefore a BadExit.
     Even though I no longer run an exit, I had been truly fed up with
Comcast's hijacking name servers for a long time, so when Google started
offering free and open access to honest, though logging, name servers
at and, I switched to them immediately.  I'm not too
worried about the logging, because very few name server queries leave
my machine anyway, mainly thanks to tor.  And if I were running an exit,
it still wouldn't bother me much because nearly all queries leaving my
machine would have nothing to do with anything I was doing at the time.
     I've procrastinated so far about setting up a small name server here,
basically for cacheing, and I've gotten away with it, I suspect, largely
because I discovered nscd(8) on my system and configured it for use.
nscd can be configured to cache results in caches for hosts, passwd,
group, services, protocols, and RPCs.  Additional, system-particular
caches can also be defined if one has the need to do so.

                                  Scott Bennett, Comm. ASMELG, CFIAG
* Internet:       bennett at cs.niu.edu                              *
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/