On Sat, 17 Apr 2010 21:54:16 -0400 Andrew Lewman <and...@torproject.org> wrote: >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 8.8.4.4 and 8.8.8.8, 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 majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/