Opened 12 years ago

Last modified 6 years ago

#364 closed defect (Implemented)

DNS lookup problems

Reported by: keybounce Owned by: nickm
Priority: Low Milestone: 0.1.2.x-final
Component: Core Tor/Tor Version: 0.1.1.25
Severity: Keywords:
Cc: keybounce Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I am still, even with 1.1.25, getting DNS resolutions like:

stbmac:/Library/Tor Michael$ tor-resolve en.wikipedia.org
127.0.0.1

There doesn't seem to be any way to find out which host is supplying these
bad references (so that they can be added to ExcludeHosts), nor does there
seem to be any sort of double checking on DNS data returned.

Normal DNS relies on being able to trust the roots, and then eventually being
able to trust the systems that they claim are reliable, to track down
authoritative answers. Tor's resolution seems to ignore that -- anyone's
answer is accepted.

To make matters worse, even after turning off tor, Firefox (1.8) still
caches the output page from Privoxy that claims that the address cannot
be resolved, and trying to reload returns the same page. (I know, that
one's not your department.)

Current configuration:
All requests go through privoxy.
Privoxy's config has lines:

# Tor:
##
## forward-socks4a / localhost:9050 .
forward-socks4a .onion localhost:9050 .

# Do not torrify these (high volume/speed concerns):
forward .vidalia-project.net .
forward 127.0.0.1 .

That first line (with the "## ") is toggled to turn tor on/off. When turned on,
I still get complaints about 127.0.0.1 and the "reloading server list /
determining server location" function of vidalia still takes forever and
occasionally logs in the console.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (4)

comment:1 Changed 12 years ago by nickm

The 0.1.2.x series has a feature for exit nodes to notice that their DNS is damaged,
and for authorities to tell clients that some nodes are not useful exits. I don't
think we have a feature yet to refuse to run as an exit if we can't resolve _any_ names
successfully, though. I should add one of those.

comment:2 Changed 12 years ago by nickm

00:19 < nickm> bug 364: does this sound like a reasonable solution:
00:20 < nickm> use some process (HANDWAVE HANDWAVE) to tell whether your dns is
giving you real distinct answers for some things.
00:20 < nickm> if not, set your exit policy to reject *:* and warn
00:22 < armadev> sure.
00:23 < nickm> okay, what's the process?
00:24 < nickm> we could launch a few tests to not-likely-to-go-away addresses li
ke www.google.com and www.mit.edu and www.eff.org , and make sure they are diffe
rent from one another
00:25 < armadev> true.
00:26 < armadev> so yes, that seems a fine addition to our resolve-lots-of-thing
s-at-bootup step

comment:3 Changed 12 years ago by nickm

flyspray2trac: bug closed.
Idea discussed in comment implemented in r9199. Will appear in 0.1.2.5-alpha.

comment:4 Changed 6 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.